Re: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge <jeremy@goop.org>]

Sam Ravnborg wrote:
>>> This seems outright silly.
>>> Either we should revert the notes changes or someone caring about it 
>>> should sweep all archs and make sure it does not hurt there.
>>>       
>> Hm, sounds like yet another binutils bug; unfortunately common when ELF
>> notes are about.  Was there any further effort to isolate what was
>> causing the problem?
>>     
>
> Lennart posted this:
> An ARM vmlinux kernel image built with pre-build-id binutils has:
>
>         Program Header:
>             LOAD off    0x00008000 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
>                  filesz 0x002e503c memsz 0x003032c0 flags rwx
>         private flags = 4000002: [Version4 EABI] [has entry point]
>
>
> Whereas a build-id binutils-built vmlinux kernel image ends up with:
>
>         Program Header:
>             LOAD off    0x00008000 vaddr 0x00000000 paddr 0x00000000 align 2**15
>                  filesz 0x00000024 memsz 0x00000024 flags r--
>             LOAD off    0x00010000 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
>                  filesz 0x002e503c memsz 0x003032c0 flags rwx
>             NOTE off    0x00008000 vaddr 0x00000000 paddr 0x00000000 align 2**2
>                  filesz 0x00000024 memsz 0x00000024 flags r--
>         private flags = 4000002: [Version4 EABI] [has entry point]
>
>
> The .note.gnu.build-id section causes objcopy to produce a 3G+
> Image file, breaking the build.
>   

Hm, these phdrs seem OK though; I don't see any ~3Gish numbers here, so
it looks like objcopy is just going off into the weeds. 

I don't know how ARM images are built, but I would guess that something
is trying to make the file large enough to accomodate a 3Gish kernel
virtual address address which hasn't being appropriately phys-ized.  It
may be more a linker script bug than an inherent problem with either
notes or build-id themselves.

> Samuel Ortiz posted following patch:
>   
>> With build-id binutils (e.g. the latest bintuils 2.18), objcopy produces
>> a 3.1 Gbytes Image file. Adding a note section fixes the problem.
>>
>> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
>> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
>> Cc: Sam Ravnborg <sam@ravnborg.org>
>>
>> ---
>>  arch/arm/kernel/vmlinux.lds.S |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> Index: linux-2.6.22/arch/arm/kernel/vmlinux.lds.S
>> ===================================================================
>> --- linux-2.6.22.orig/arch/arm/kernel/vmlinux.lds.S   2007-09-11 18:32:29.000000000 +0200
>> +++ linux-2.6.22/arch/arm/kernel/vmlinux.lds.S        2007-09-11 18:33:42.000000000 +0200
>> @@ -94,6 +94,7 @@
>>                       TEXT_TEXT
>>                       SCHED_TEXT
>>                       LOCK_TEXT
>> +                     *(.note.*)
>>  #ifdef CONFIG_MMU
>>                       *(.fixup)
>>  #endif
>>     
>
>
> I cannot see why this should fix it since the patch does
> not discard the section. Maybe the inclusion of the section in
> some oter section does some good.
>   

Yes, binutils can be pretty fragile with notes about.  In this case it
seems to be a specific problem with build-id; I'm not really sure what
build-id actually does.

Though if my theory above is true, it may end up properly assigning a
value to a symbol
by putting it into the right section.  Or something.
> Anyway the original submitter of the build-id should have identified such
> issues and fixed all archs.
>
> And I still do not get exactly what problem the note section solves when
> included in vmlinux....

The Note section is supposed to be a general extensible way of adding
metadata to an object file, either for a linker or a loader.  There's no
inherent connection between notes and build-id (other than build-id is
one of the users of notes, I suppose).

    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/