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
- 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.
- 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