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 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 <dufa...@hda.com >> <mailto:dufa...@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@rtems.org <mailto:devel@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
