Re: objcopy making a mess of converting kernels to a.out format

[Richard Earnshaw <rearnsha%buzzard.freeserve.co.uk@localhost>]

> I seem to get different output, also concerning about yours is that the
> .data isn't starting on the same addresses, the headers I got were:
> 
> > /extra/tools/current/cats/bin/arm--netbsdelf-objdump -h netbsd
> 
> netbsd:     file format elf32-littlearm
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00426c9f  f0000020  f0000020  00008020  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 link_set_malloc_types 0000014c  f0426cc0  f0426cc0  0042ecc0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 link_set_sysctl_funcs 000000b8  f0426e0c  f0426e0c  0042ee0c  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 link_set_evcnts 00000004  f0426ec4  f0426ec4  0042eec4  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .data         00010554  f0427000  f0427000  0042f000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   5 .bss          00044864  f0437554  f0437554  0043f554  2**2
>                   ALLOC
>   6 .arm.atpcs    00000000  00000000  00000000  0043f554  2**0
>                   CONTENTS, READONLY
>   7 .comment      00008a9d  00000000  00000000  0043f554  2**0
>                   CONTENTS, READONLY
>   8 .ident        0000a29e  00000000  00000000  00447ff1  2**0
>                   CONTENTS, READONLY
> > /extra/tools/current/cats/bin/arm--netbsdelf-objdump -h netbsd.aout
> 
> netbsd.aout:     file format a.out-arm-netbsd
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00426fe0  f0000020  f0000020  00000020  2**2
>                   CONTENTS, ALLOC, LOAD, CODE
>   1 .data         00011000  f0427000  f0427000  00427000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          00043db8  f0438000  f0438000  00000000  2**2
>                   ALLOC
> 
> Note this is GENERIC cats -current kernel.  Which kernel are you trying
> to build?  And how uptodate are your tools?

Saturday morning.

Note: this does *not* happen every time.   It seems to be a property of 
some builds and not others -- you sometimes end up with a kernel that just 
won't boot -- when it won't then you tend to find these problems.  It's 
not the first time I've had a dead kernel, and that too seemed to have a 
suspect .data size.

As I mentioned previously, I suspect that the link_... sections are 
somehow not being fully taken into account -- I suspect that the problem 
only occurs if something like the following is true

        (0x20 + sizeof(.text)) & ~0xfff
         < (0x20 + sizeof(.text) + sizeof(link_*)) & ~0xfff

In the particular case in question it was a custom kernel for my cats 
which booted fine until I made an unrelated change (to build a kernel with 
WD_DUMP_NOT_TRUSTED defined) -- the resulting kernel crashes immediately 
on boot before it can even print out the NetBSD banner.

R.