Run Time linker and relocation of multiple local labels

[Chris Johns]

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 from an archive so the incremental
linking stage is not always needed. What I do not know is what saving
incremental linking gives us. I would be interested to know the percentage
different between the physical size of the stripped incrementally linked object
and the same object files used in the linking in a stripped archive. I think the
incrementally linked object file will be smaller but I am not sure by how much
for a decent sized application. Would you mind having a look for me?

FYI a stripped archive is an archive of object files you run strip on. Strip
will unpack and strip each object file in the archive and repack the archive.

>  At least on ARM I can’t get it to work, it uses the first local address it sees for all occurrences.

OK.

> 
> Example: Label .LC2 is used in two places, once for the “r” in an fopen() and later for a format string.  In both cases the address used is 0x419f14, the address of “r”.

Are the matching local symbols in the same symbol section or a different symbol
section? I wonder if the symbol parsing stage in loading is joining different
symbols into a single local symbol table?

> 
> First is the readelf output, then the disassembly, then debugging output from the RTL.
> 
> FIRST OCCURRENCE OF .LC2 used as “r” in fopen()
> readelf:
> 00000020  0000152f R_ARM_THM_MOVW_ABS_NC  00000008   .LC1
> 00000024  00001530 R_ARM_THM_MOVT_ABS     00000008   .LC1
> 0000002a  0000162f R_ARM_THM_MOVW_ABS_NC  0000002c   .LC2
> 0000002e  00001630 R_ARM_THM_MOVT_ABS     0000002c   .LC2
> 00000034  0000450a R_ARM_THM_CALL         00000000   fopen

I assume these are relocation records. I would need to check the ELF format to
know if the symbol reference has any extra data related to the symbol or if
there are any section references to a symbol section that lets us know where to
find the symbol.

The symbols loading and text loading is not sequential in the object file.
Symbols are loaded before relocation happens.

> 
> Disassemble:
>     if ((fd = fopen(string, "r")) == (0)) {
>   2a:   f240 0100   movw    r1, #0
>   2e:   f2c0 0100   movt    r1, #0
>   32:   6878        ldr r0, [r7, #4]
>   34:   f7ff fffe   bl  0 <fopen>
> 
> RTL:
> rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x341f2c0 @ 0x4196dc in bad
> rtl: rel: sym:.LC2(22)=00419f14 type:47 off:0000002a
> rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x7114f649 @ 0x4196e2 in bad
> rtl: rel: sym:.LC2(22)=00419f14 type:48 off:0000002e
> rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x141f2c0 @ 0x4196e6 in bad
> rtl: rel: sym:fopen(69)=000d33c1 type:10 off:00000034
> 
> SECOND OCCURRENCE of .LC2 used for the printf format string:
> 
> readelf:
> 000007a8  00002c2f R_ARM_THM_MOVW_ABS_NC  0000013c   .LC2
> 000007ac  00002c30 R_ARM_THM_MOVT_ABS     0000013c   .LC2
> 000007b0  0000330a R_ARM_THM_CALL         00000000   printf>
> Disassemble:
>  7a6:   68f9        ldr r1, [r7, #12]
>  7a8:   f240 0000   movw    r0, #0
>  7ac:   f2c0 0000   movt    r0, #0
>  7b0:   f7ff fffe   bl  0 <printf>
> 
> RTL:
> rtl: rel: sym:.LC2(44)=00419f14 type:47 off:000007a8
> rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x7014f649 @ 0x419e60 in /opt/flatland/arch/arm-stubs-vxstubs/bin/sys-bad
> rtl: rel: sym:.LC2(44)=00419f14 type:48 off:000007ac
> rtl: THM_MOVT_ABS/THM_MOVW_ABS_NC 0x41f2c0 @ 0x419e64 in /opt/flatland/arch/arm-stubs-vxstubs/bin/sys-bad
> rtl: rel: sym:printf(51)=000daac9 type:10 off:000007b0
> 

I would need to figure out how this is being handled and what the ELF standard says.

Would it be possible for you to create a small test case that shows the problem?
That would be very helpful.

Chris