Linker Issues in base-hw for an Armv8 Implementation

[Bob Stewart]

Looks like my reply from yesterday got held up for being too long. 
Shorter version:-
There is actually no error message indication why the linker failed. 
Assuming that it was because --build-id was expected later in the linker 
operations, I added the linker option -Wl, --build-id=none to the final 
image linker command in build_core. That resulted in the linker 
completing successfully and sensible image sizes being created as shown 
in the objdump output:

objdump-p ../build/dragonboard/var/run/log.bootstrap|more

../build/dragonboard/var/run/log.bootstrap: file format elf64-little

Program Header:

LOAD off 0x0000000000001000 vaddr0x0000000081000000 
paddr0x0000000081000000 align 2**12

filesz0x000000000003b840 memsz0x000000000003b840 flags r-x

LOAD off 0x000000000003d000 vaddr0x000000008103c000 
paddr0x000000008103c000 align 2**12

filesz0x00000000000041fc memsz0x000000000000d109 flags rw-

LOAD off 0x00000000000411fc vaddr0x0000000000000000 
paddr0x0000000000000000 align 2**12

filesz0x0000000000000000 memsz0x0000000000000000 flags r--

The executable image produced, image.elflooks okwith a quick scan using 
readelf.

Sebastian, do you have any thoughts on why the linker gets upset with 
when the .note.gnu.build <http://note.gnu.build>-idsection is not discarded?

Thanks,

Bob



Get Outlook for Android <https://aka.ms/ghei36>

------------------------------------------------------------------------
*From:* Bob Stewart <robjsstewart at gmail.com>
*Sent:* Wednesday, July 18, 2018 1:55:02 PM
*To:* users at lists.genode.org
*Subject:* Re: Linker Issues in base-hw for an Armv8 Implementation
There is actually no error message indication why the linker failed. 
Assuming that it was because --build-id was expected later in the linker 
operations, I added the linker option -Wl, --build-id=none to the final 
image linker command in build_core. That resulted in the linker 
completing successfully and sensible image sizes being created as shown 
in the objdump output:

objdump -p ../build/dragonboard/var/run/log.bootstrap |more

../build/dragonboard/var/run/log.bootstrap:     file format elf64-little

Program Header:
     LOAD off    0x0000000000001000 vaddr 0x0000000081000000 paddr 
0x0000000081000000 align 2**12
          filesz 0x000000000003b840 memsz 0x000000000003b840 flags r-x
     LOAD off    0x000000000003d000 vaddr 0x000000008103c000 paddr 
0x000000008103c000 align 2**12
          filesz 0x00000000000041fc memsz 0x000000000000d109 flags rw-
     LOAD off    0x00000000000411fc vaddr 0x0000000000000000 paddr 
0x0000000000000000 align 2**12
          filesz 0x0000000000000000 memsz 0x0000000000000000 flags r--

objdump -h ../build/dragonboard/var/run/log.bootstrap |more

../build/dragonboard/var/run/log.bootstrap:     file format elf64-little

Sections:
Idx Name          Size      VMA               LMA File off  Algn
   0 .text         0003b840  0000000081000000  0000000081000000 
00001000  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00000718  000000008103c000  000000008103c000 
0003d000  2**3
                   CONTENTS, ALLOC, LOAD, DATA
   2 .got          000000e0  000000008103c718  000000008103c718 
0003d718  2**3
                   CONTENTS, ALLOC, LOAD, DATA
   3 .got.plt      00000018  000000008103c7f8  000000008103c7f8 
0003d7f8  2**3
                   CONTENTS, ALLOC, LOAD, DATA
   4 .eh_frame     00003084  000000008103c810  000000008103c810 
0003d810  2**3
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   5 .gcc_except_table 00000968  000000008103f894 000000008103f894  
00040894  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   6 .bss          00008f09  0000000081040200  0000000081040200 
000411fc  2**3
                   ALLOC

The executable image produced, image.elf looks ok with a quick scan 
using readelf.

Sebastian, do you have any thoughts on why the linker gets upset with 
when the .note.gnu.build-id section is not discarded?

Thanks,
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180719/0957b88b/attachment.html>