[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Kirkwood hang on boot; possibly uninitialised bss
On 22 May 2012 16:39, Nick Hudson <nick.hudson%gmx.co.uk@localhost> wrote:
> As it's
> a .space and not .zero then it's probably getting filled by the linker with
> whatever the linker thinks the fill is for the data output section. You could
> check the kernel directly.
I'm confused by this, too. I'm not sure exactly what I'm looking for.
objdump -D marvell_macdep.o shows me:
0: 00000000 andeq r0, r0, r0
readelf -x .data marvell_macdep.o shows the same:
Hex dump of section '.data':
0x00000000 00000000 00c20100 004b0000 00000000 .........K......
0x00000010 00000000 0000ffff
Just to be clear, I'm reading these as consinit_called.9907 lives in offset 0
relative to .data (and I presume the .9907 is gcc's invented ID, because it
differs from a previous compilation).
So consinit_called in marvell_macdep.o has all bytes initially 0.
That obviously differs from the behaviour I'm seeing at runtime.
How can I inspect netbsd.bin? I'd like to confirm that this object ends up
there with all bytes 0, too.
Other than that, I have absolutely no idea what to investigate next.
Is this a bug in linking? Surely not.
>> Incidentally, gcc is compiling with -fno-zero-initialized-in-bss which
>> I presume is correct, because (I think) the bss initialisation is done
>> by the kernel during load. Is that right?
> bss is initialised after initarm here
Do you mean before initarm?
Main Index |
Thread Index |