Re: Kirkwood hang on boot; possibly uninitialised bss

[Kate F <kate%elide.org@localhost>]

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.

Hi Nick,

I'm confused by this, too. I'm not sure exactly what I'm looking for.

objdump -D marvell_macdep.o shows me:

  00000000 <consinit_called.9907>:
     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
>
> http://nxr.netbsd.org/xref/src/sys/arch/arm/arm32/locore.S#67

Do you mean before initarm?

Thanks,

-- 
Kate