Linker Issues in base-hw for an Armv8 Implementation - users

18 Jul 2018


      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.
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.
Thanks,
Bob Stewart