Run Time linker and relocation of multiple local labels

dufault at hda.com dufault at hda.com
Thu Apr 25 22:38:59 UTC 2019


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 .LC0 format strings will be “BAR %s\n”.  I’ll read-up on ELF but the “Num” field appears to be what would make those .LC0 easily unique.

Zynq dufault at gen6 fubar]$ cat foo.c
#include <stdio.h>

extern void foo(void);
void foo(void)
{
    printf("FOO %s\n", "Foo 1");
}
Zynq dufault at gen6 fubar]$ cat bar.c
#include <stdio.h>

extern void bar(void);
void bar(void)
{
    printf("BAR %s\n", "Bar 1");
}
Zynq dufault at gen6 fubar]$ arm-rtems5-gcc -march=armv7-a -mthumb -c foo.c
Zynq dufault at gen6 fubar]$ arm-rtems5-gcc -march=armv7-a -mthumb -c bar.c
Zynq dufault at gen6 fubar]$ arm-rtems5-ld -r -o fubar bar.o foo.o
Zynq dufault at gen6 fubar]$ arm-rtems5-readelf -s fubar

Symbol table '.symtab' contains 20 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 SECTION LOCAL  DEFAULT    1 
     2: 00000000     0 SECTION LOCAL  DEFAULT    3 
     3: 00000000     0 SECTION LOCAL  DEFAULT    4 
     4: 00000000     0 SECTION LOCAL  DEFAULT    5 
     5: 00000000     0 SECTION LOCAL  DEFAULT    6 
     6: 00000000     0 SECTION LOCAL  DEFAULT    7 
     7: 00000000     0 FILE    LOCAL  DEFAULT  ABS bar.c
     8: 00000000     0 NOTYPE  LOCAL  DEFAULT    3 $d
     9: 00000000     0 NOTYPE  LOCAL  DEFAULT    3 .LC0
    10: 00000008     0 NOTYPE  LOCAL  DEFAULT    3 .LC1
    11: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 $t
    12: 00000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
    13: 00000010     0 NOTYPE  LOCAL  DEFAULT    3 $d
    14: 00000010     0 NOTYPE  LOCAL  DEFAULT    3 .LC0
    15: 00000018     0 NOTYPE  LOCAL  DEFAULT    3 .LC1
    16: 0000001c     0 NOTYPE  LOCAL  DEFAULT    1 $t
    17: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND printf
    18: 0000001d    28 FUNC    GLOBAL DEFAULT    1 foo
    19: 00000001    28 FUNC    GLOBAL DEFAULT    1 bar
Zynq dufault at gen6 fubar]$ arm-rtems5-objdump --disassemble --source fubar

fubar:     file format elf32-littlearm


Disassembly of section .text:

00000000 <bar>:
   0:	b580      	push	{r7, lr}
   2:	af00      	add	r7, sp, #0
   4:	f240 0100 	movw	r1, #0
   8:	f2c0 0100 	movt	r1, #0
   c:	f240 0000 	movw	r0, #0
  10:	f2c0 0000 	movt	r0, #0
  14:	f7ff fffe 	bl	0 <printf>
  18:	bf00      	nop
  1a:	bd80      	pop	{r7, pc}

0000001c <foo>:
  1c:	b580      	push	{r7, lr}
  1e:	af00      	add	r7, sp, #0
  20:	f240 0100 	movw	r1, #0
  24:	f2c0 0100 	movt	r1, #0
  28:	f240 0000 	movw	r0, #0
  2c:	f2c0 0000 	movt	r0, #0
  30:	f7ff fffe 	bl	0 <printf>
  34:	bf00      	nop
  36:	bd80      	pop	{r7, pc}
Zynq dufault at gen6 fubar]$ 


> On Apr 25, 2019, at 18:02 , Chris Johns <chrisj at rtems.org> wrote:
> 
> On 26/4/19 2:04 am, dufault at 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 lookup on e.g. “.LC2” and stops at the first hit.  I haven’t checked that
>> consumers of the lookup can generate the correct name, that is, always have the
>> “Num” field value.
> 
> I would like to understand at the ELF level what is happening before considering
> solutions. As I indicated in my other email if the symbols are local and in
> different sections it could be something in the handling of the relocation
> records for a section that needs to consider the symbol section used for local
> symbols. If the symbols are in the same section and match then I would question
> why `ld` is doing this.
> 
>> 
>> You’d wind up with mangled lookups such as:
>> 
>>     22: 0000002c     0 NOTYPE  LOCAL  DEFAULT    3 .LC2.Num22
>>     44: 0000013c     0 NOTYPE  LOCAL  DEFAULT    3 .LC2.Num44
>> 
>>  This is from one of my relocatable files grepping for NOTYPE LOCAL.  I’ve
>> verified large files also work.
> 
> This means the local symbol table now has different entries. How do you know
> which one a relocation record is pointing too?
> 
> Chris
> 
>>  Num:    Value  Size Type    Bind   Vis      Ndx Name
>>      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
>>     14: 00000000     0 NOTYPE  LOCAL  DEFAULT    3 $d
>>     15: 00000000     0 NOTYPE  LOCAL  DEFAULT    4 $d
>>     17: 00000000     0 NOTYPE  LOCAL  DEFAULT    6 $d
>>     18: 00000000  2048 NOTYPE  LOCAL  DEFAULT    6 env_entries
>>     20: 00000800     4 NOTYPE  LOCAL  DEFAULT    6 env_initialized
>>     21: 00000008     0 NOTYPE  LOCAL  DEFAULT    3 .LC1
>>     22: 0000002c     0 NOTYPE  LOCAL  DEFAULT    3 .LC2
>>     23: 00000030     0 NOTYPE  LOCAL  DEFAULT    3 .LC3
>>     25: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 $t
>>     28: 00000050     0 NOTYPE  LOCAL  DEFAULT    3 .LC4
>>     29: 00000058     0 NOTYPE  LOCAL  DEFAULT    3 .LC5
>>     30: 00000080     0 NOTYPE  LOCAL  DEFAULT    3 .LC6
>>     32: 00000094     0 NOTYPE  LOCAL  DEFAULT    3 .LC7
>>     33: 000000c4     0 NOTYPE  LOCAL  DEFAULT    3 .LC8
>>     34: 000000cc     0 NOTYPE  LOCAL  DEFAULT    3 .LC9
>>     35: 000000f4     0 NOTYPE  LOCAL  DEFAULT    3 .LC10
>>     37: 00000130     0 NOTYPE  LOCAL  DEFAULT    3 $d
>>     38: 0000000c     0 NOTYPE  LOCAL  DEFAULT    4 $d
>>     40: 00000804     0 NOTYPE  LOCAL  DEFAULT    6 $d
>>     41: 00000d14   520 NOTYPE  LOCAL  DEFAULT    6 putenv_trace_ptrs
>>     42: 00000690     0 NOTYPE  LOCAL  DEFAULT    1 $t
>>     43: 00000138     0 NOTYPE  LOCAL  DEFAULT    3 .LC1
>>     44: 0000013c     0 NOTYPE  LOCAL  DEFAULT    3 .LC2 
>>     45: 0000014c     0 NOTYPE  LOCAL  DEFAULT    3 .LC3
>>     47: 00000164     0 NOTYPE  LOCAL  DEFAULT    3 .LC4
>> 
>> 
>>> On Apr 25, 2019, at 07:56 , Peter Dufault <dufault at hda.com
>>> <mailto:dufault at hda.com>> 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.  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 an fopen() and
>>> later for a format string.  In both cases the address used is 0x419f14, the
>>> address of “r”.
>>> 
>>> 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
>>> 
>>> 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
>>> 
>>> Peter
>>> -----------------
>>> Peter Dufault
>>> HD Associates, Inc.      Software and System Engineering
>>> 
>>> This email is delivered through the public internet using protocols subject to
>>> interception and tampering.
>>> 
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org <mailto:devel at rtems.org>
>>> http://lists.rtems.org/mailman/listinfo/devel
>> 
>> Peter
>> -----------------
>> Peter Dufault
>> HD Associates, Inc.      Software and System Engineering
>> 
>> This email is delivered through the public internet using protocols subject to
>> interception and tampering.
>> 
>> 
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>> 

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190425/4dff8700/attachment-0002.html>


More information about the devel mailing list