Hi,
About issue #3740, I think maybe I found the cause of loading failed.
In file libdl/rtl-elf.c line159-166, it says "STT_NOTYPE the symbol
references a global symbol", But from arm-rtems-readelf information, local
symbol .LC0 ...is STT_NOTYPE. And the of document IHI0044E_aaelf.pdf
On 26/4/19 8:38 am, dufa...@hda.com wrote:
> Here’s a simple example.
I have added this code to the testsuite's dl01 test and it works on the PowerPC
and fails on ARM (Zynq). It is still not clear to me if there is special
handling with ARM or if this is an `ld` bug.
I have opened a ticket to
Here’s a simple example. Note I’m combining two .o files with ld -r into a
relocatable. I want to stick to this approach (which matches what’s done on
vxWorks) until we’ve done some testing between the vxWorks and RTEMS versions.
Lots of scripts, etc. The way the RTEMS RTL loads this both
On 26/4/19 2:04 am, dufa...@hda.com wrote:
> In a given object file for "NOTYPE LOCAL” entries in a data segment with zero
> size that don’t start with ‘$’ could you append text based on the Num field
> for
> the rtems_rtl_obj symbol lookup in cpukit/libdl/rtl-sym.c? Right now it’s a
> linear
On 25/4/19 9:56 pm, Peter Dufault wrote:
> I’m porting a large vxWorks application and I’m trying to download “ld -r”
> files as you can on vxWorks using the run-time loader.
Thank you for the report. We should support incremental linking like this.
As an aside, libdl can perform the linking
In a given object file for "NOTYPE LOCAL” entries in a data segment with zero
size that don’t start with ‘$’ could you append text based on the Num field for
the rtems_rtl_obj symbol lookup in cpukit/libdl/rtl-sym.c? Right now it’s a
linear lookup on e.g. “.LC2” and stops at the first hit. I
I’m porting a large vxWorks application and I’m trying to download “ld -r”
files as you can on vxWorks using the run-time loader. At least on ARM I can’t
get it to work, it uses the first local address it sees for all occurrences.
Example: Label .LC2 is used in two places, once for the “r” in
