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-0001.html>
More information about the devel
mailing list