[RTEMS Project] #4944: libdl test dl09 fails on arm and aarch64

[RTEMS trac]

#4944: libdl test dl09 fails on arm and aarch64
-------------------------+---------------------
 Reporter:  Chris Johns  |       Owner:  (none)
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:  6.1
Component:  lib/dl       |     Version:  6
 Severity:  normal       |  Resolution:
 Keywords:               |  Blocked By:
 Blocking:               |
-------------------------+---------------------

Comment (by Chris Johns):

 The `dl091` test allocates large blocks of memory between loading object
 files to move the object's text base address out of the range of any
 relative addressing instructions to symbols in the base image forcing the
 use of trampolines.

 On `aarch64` the failure is the trampoline memory is out of range to the
 text memory so the relocations to the trampoline memory cannot be fixed
 up. The allocated trampoline memory is not colocated to the allocated text
 memory when it should be. The overflow is:

 {{{
 rtl: JUMP26/PC26/CALL: insn=0x4e123208 where=0x4e123208
 target=0xfffffffff1f24898 raddr=0x40047aa0 parsing=0
 }}}

 The `target` value is the relative offset and is `-201367832`. The
 instruction to fix up is located at `0x4e123208`. The trampoline
 allocation is:

 {{{
 rtl: tramp:elf: tramps: 14 count:14 total:14
 rtl: tramp:elf: slots: 14 (224)
 rtl: alloc: new: OBJECT addr=0x421190f0 size=224
 }}}

 If trace is enabled for the test a set of commands are run at the end of
 each pass to report the state of some things such as the heap. The heap
 state is returned by the `malloc_info()` call and that call causes the
 test to pass (see #4946). Something happens in the heap to bring the
 allocated memory closer together.

 The intent of the original design was to have a trampoline table appended
 to one end of the text area of the object file's memory. This means the
 maximum size of code that can be loaded is half the relative instruction
 offset size. A review of the code shows the trampoline memory is being
 heap allocated as a separate block. I cannot remember why it is implement
 this way. Effort was spent determining how to handle the allocation
 because the relocation records need to be parsed to determine the amount
 of memory to append to the text area and this means the relocation records
 are processed twice slowing loading down. The double processing of the
 relocation records was considered a suitable compromise to solve the
 problem. Parsing was added however the number of relocations is not being
 used when allocating the text area of memory.

 I think the text area needs to be extended to hold the trampoline memory.
 I am not sure if the text size reported should be the object file's text
 size or the size with the trampoline memory. I suppose it is text type
 memory so it should be included. It will make the change simpler.

--
Ticket URL: <http://devel.rtems.org/ticket/4944#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project