[SLOF] sloffs: tool to read and write SLOF images

[Alexey Kardashevskiy]

On 16/06/16 06:06, Adrian Reber wrote:
> On Wed, Jun 15, 2016 at 09:36:13PM +0200, Thomas Huth wrote:
>> On 15.06.2016 10:29, Adrian Reber wrote:
>>> This brings the sloffs code to read, copy and append files to an existing
>>> boot_rom.bin from my repository at https://lisas.de/~adrian/slof/slof.git/ .
>>>
>>> This code was written in 2008 and all patches have been cherry-picked
>>> without modifications. Only the last patch (13/13) updates the code
>>> to work with today's compilers.
>>
>> Cool, thanks for posting it! I also gave it a try, and it works for me 
>> fine with the current boot_rom.bin images, too.
>>
>> However, I still get some compiler warnings here (gcc 4.8.5):
>>
>> sloffs.c: In function ‘sloffs_dump’:
>> sloffs.c:434:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>   if (be64_to_cpu(*(uint64_t *)header->date)) {
>>   ^
>> sloffs.c:435:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>    printf("%04x", be16_to_cpu(*(uint16_t *)(header->date + 2)));
>>    ^
>> sloffs.c:445:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>   if (be64_to_cpu(*(uint64_t *)header->mdate)) {
>>   ^
>> sloffs.c:446:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>>    printf("%04x", be16_to_cpu(*(uint16_t *)(header->mdate + 2)));
>>    ^
> 
> Interesting. With gcc 6.1.1 on Fedora 24 I do not see those warnings.
> 
>> We already changed most Makefiles of SLOF to use -fno-strict-aliasing,
>> so we should maybe use that for tools/Makefile, too - or simply
>> fix the aliasing problems ;-)
> 
> Whatever fits better to the remaining code. The romfs structs are broken
> and the actual dates are stored in the padding fields behind date and
> mdate.

I am a bit confused here.

As I read the code, the dates are stored in both date and padding fields,
it is just shifted by 2 bytes so padding is used. And the tool does not
handle properly written dates at all as romfs is always wrong - where are
these dates are stored? Cannot we fix that spot and then fix the tool not
to have this workaround?

Another question - I prefer merging all these patches into one before
pushing, any objections to this?


-- 
Alexey