Linker Issues in base-hw for an Armv8 Implementation

[Sebastian Sumpf]

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