Linker Issues in base-hw for an Armv8 Implementation
Bob Stewart
robjsstewart at gmail.com
Wed Jul 18 03:00:29 CEST 2018
Thanks Sebastian for the rapid reply!
The program header dump shows the problem as being with first file load:
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 0x0000000000000000 paddr 0x0000000000000000 align 2**12
filesz 0x000000008103b840 memsz 0x000000008103b840 flags r-x
LOAD off 0x000000008103d000 vaddr 0x000000008103c000 paddr 0x000000008103c000 align 2**12
filesz 0x00000000000041fc memsz 0x000000000000d109 flags rw-
LOAD off 0x0000000081042000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12
filesz 0x0000000000000024 memsz 0x0000000000000024 flags r--
When I add *(note.gnu.build<http://note.gnu.build>-id) to the linker scripts /DISCARD/ I get a build error that I don't understand ... I'll work on it tomorrow!:
...
Program lib/ld/hw/ld-hw
make[1]: Leaving directory '/Work/Genode/genode-18.02/build/dragonboard'
genode build completed
using 'ld-hw.lib.so<http://ld-hw.lib.so>' as 'ld.lib.so<http://ld.lib.so>'
core link address is 0x85000000
/NFS/usr/local/bin/linaro_6.4.1/bin/../lib/gcc/aarch64-elf/6.4.1/../../../../aarch64-elf/bin/ld: warning: .note.gnu.build<http://note.gnu.build>-id section discarded, --build-id ignored.
while executing
"exec [cross_dev_prefix]g++ {*}$arch -nostdlib {*}[core_ld_opts] -Wl,-z -Wl,max-page-size=0x1000 -Wl,-Ttext=$link_address -Wl,-gc-sections -Wl,-nost..."
(procedure "build_core" line 18)
invoked from within
"build_core debug/$core_obj {} [run_dir].core [core_link_address]"
(procedure "run_boot_dir" line 43)
invoked from within
"run_boot_dir $binaries"
(procedure "build_boot_image" line 27)
invoked from within
"build_boot_image "core ld.lib.so<http://ld.lib.so> init test-log""
(file "/Work/Genode/genode-18.02/repos/base/run/log.run<http://log.run>" line 23)
invoked from within
"source $include_name"
("foreach" body line 6)
invoked from within
"foreach include_name [get_cmd_arg --include ""] {
# first check if the include name is absolute
if {[string first "/" $include_name] == 0} {
puts ..."
(file "/Work/Genode/genode-18.02/tool/run/run" line 959)
make: *** [run/log] Error 1
Makefile:312: recipe for target 'run/log' failed
Bob
Get Outlook for Android<https://aka.ms/ghei36>
From: Sebastian Sumpf <Sebastian.Sumpf at genode-labs.com>
Sent: Tuesday, July 17, 2018 11:21:59 PM
To: users at lists.genode.org
Subject: Re: Linker Issues in base-hw for an Armv8 Implementation
Hello Bob,
On 07/18/2018 12:47 AM, Bob Stewart wrote:
> Hi,
>
> I realize my issues are far from the current mostly-Sculpt roadmap, but
> perhaps someone can throw some light on my problems...at least I'm
> dealing with current hardware devoid of parallel ports :o
>
> I've been carefully creating a build structure in base-hw that will
> support armv8 and at least AArch64 over the past several months. I'm at
> the point where I have made all the architectural additions to support
> armv8 and the arm64 assembler which includes support for the assembler
> instruction changes from armv7, execution modes, and exception levels
> (only EL0 and EL1, initially). Everything builds for a cortex A-53
> platform but fails in the final linking steps in two ways as described
> below. But first, my build tools are a copy of the Linaro toolchain,
> version 6.4.1, which used binutils 2.27, and my CROSS_DEV_PREFIX points
> to its location. I'm building in Genode 18.02
>
> 1. The final linking step fails initially with the "_impure_ptr" global
> not being resolved (see the build output in build_impure.log). Typically
> this global is supplied via libc, but Genode's special libc does not
> contain it. This global is a pointer to a structure that contains
> "errno" from failed C-code execution, along with some concurrency data
> for threading, if remember correctly. The pointer is only used in
> vterminate.cc which comes from the toolchain. In the currently used
> Genode toolchain the library supc++.o contains vterminate.o which is
> stripped, so the linker would not complain about the pointer. Is this by
> design because the process is about to die anyway when vterminate is
> called? To temporarily work around this problem I created a dummy void
> * _impure_ptr global in base/lib/cxx/misc.cc. The linker now continues
> and eventually completes.
I would go with that solution for now.
> 2. The second problem is the size of the executable image files that the
> linker produces, several gigabytes! The actual memory image of the
> executable appears correct based on a dump of the section header but the
> header information shows that the File Offsets to the sections appears
> to be based off the link address. For example, in the creation of the
> boot image, build_core creates the binary log.bootstrap, the dump of
> which is:
>
> 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 .note.gnu.build-id 00000024 0000000000000000 0000000000000000
> 81042000 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 1 .text 0003b840 0000000081000000 0000000081000000 81001000
> 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 2 .data 00000718 000000008103c000 000000008103c000 8103d000
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 3 .got 000000e0 000000008103c718 000000008103c718 8103d718
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 4 .got.plt 00000018 000000008103c7f8 000000008103c7f8 8103d7f8
> 2**3
> CONTENTS, ALLOC, LOAD, DATA
> 5 .eh_frame 00003084 000000008103c810 000000008103c810 8103d810
> 2**3
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .gcc_except_table 00000968 000000008103f894 000000008103f894
> 81040894 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .bss 00008f09 0000000081040200 0000000081040200 810411fc
> 2**3
> ALLOC
>
> It would appear that all the "File off" values are the expected value
> plus the bootstrap_link_address which is 0x81000000. Additionally, there
> is no stack unwind sections present, that is .ARM.exid/extab.
>
> The linker script being used is base/src/ld/genode.ld, as it should be.
>
> I don't have sufficient knowledge about linker functioning to begin to
> understand how the File offset values are determined or how the c++
> stack unwind section is added, or not. Any suggestions would be very
> helpful.
Indeed, the offset should be the cause as well as the VMA/LMA of the
.note.gnu.build-id section. As a first measure you could try to add this
section to the /DISCARD/ sections at the very end of the linker scripts
(e.g., to 'repos/base/src/ld/genode_dyn.ld' for the dynamic binaries and
to genode.ld for static ones). Otherwise the output of the program
headers ('objdump -p <binary>') would also be interesting to inspect.
Regards,
Sebastian
--
Sebastian Sumpf
Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________
Genode users mailing list
users at lists.genode.org
https://lists.genode.org/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180718/701393c5/attachment-0001.html>
More information about the users
mailing list