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

[Adrian Reber]

On Mon, Jun 27, 2016 at 01:02:59PM +1000, Alexey Kardashevskiy wrote:
> 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?

Yes, the structures defining the romfs header and the romfs code
unfortunately disagree. My tool just tries to cope with the broken code.

The definition is in include/calculatecrc.h and it written in
romfs/tools/create_crc.c. There is also some forth code reading this
field: bdate2human

I discussed this already on IRC with Thomas and it should be easy
fix it. It just means sloffs will never display the correct dates of old
romfs files. Which is probably not that important...

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

I can understand that, but as I was able to cherry-pick all commits
without any fixups, I would prefer to keep the history as it was.

But as you will be the one committing the patches it is your decision
how you want to merge the patches.

		Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20160627/44d3d121/attachment-0001.sig>