On 2/11/2014 8:28 pm, Peng Fan wrote:
qemu-system-arm -no-reboot -net none -nographic -M realview-pbx-a9 -m
256M -kernel `find . -name dl01.exe` -s -S
*** BEGIN OF TEST libdl (RTL) Loader 1 ***
load: /dl-o1.o
rtl: unsupported section: 15: type=1879048195 flags=00
handle: 0x212b10 has unresolved externals
Thanks for the testing.
dl-o1.o can not be correctly loaded, because of unresolved symbols.
I do some debug using remote gdb and found it is the reloc entry
references local symbols named "LCx" saying "LC0", "LC1", "LC2".
Freenix@linux-jyl1:~/per/new/build-arm> arm-rtems4.11-readelf -s `find .
-name dl-o1.o`
Symbol table '.symtab' contains 22 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS dl-o1.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000000 0 NOTYPE LOCAL DEFAULT 5 $d
* 7: 00000000 0 NOTYPE LOCAL DEFAULT 5 .LC0*
* 8: 00000020 0 NOTYPE LOCAL DEFAULT 5 .LC1*
* 9: 00000068 0 NOTYPE LOCAL DEFAULT 5 .LC2*
10: 00000000 0 NOTYPE LOCAL DEFAULT 1 $t
11: 00000000 0 SECTION LOCAL DEFAULT 6
12: 00000000 0 SECTION LOCAL DEFAULT 8
13: 00000000 0 SECTION LOCAL DEFAULT 9
14: 00000000 0 SECTION LOCAL DEFAULT 11
15: 00000000 0 SECTION LOCAL DEFAULT 13
16: 00000010 0 NOTYPE LOCAL DEFAULT 16 $d
17: 00000000 0 SECTION LOCAL DEFAULT 16
18: 00000000 0 SECTION LOCAL DEFAULT 14
19: 00000000 0 SECTION LOCAL DEFAULT 15
20: 00000001 88 FUNC GLOBAL DEFAULT 1 rtems_main
21: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
The LCx symbols's type is NOTYPE and not included in the rtl symbol
table(local symbol may should not be included). In rtl-elf.c, line 387
see following, the LCx symbols are not included, so fails. I prefer that
if unresolved symbols detected in rtl, detailed info should be print
out, but i found no debug msg about this.
Unresolved symbols may not be an error. If you have 2 files dependent on
each other one will be loaded with unresolved externals until the other
is loaded. The loader handles this and when the second dependent module
is loaded the unresolved symbols are resolved. This means the loader is
not in a position to have a clear enough picture to decide if there are
unresolved symbols. The application loading must decide when to check,
check and raise an error when it thinks there should be no errors.
384 /*
385 * Only keep the functions and global or weak symbols.
386 */
387 if ((ELF_ST_TYPE (symbol.st_info) == STT_OBJECT) ||
388 (ELF_ST_TYPE (symbol.st_info) == STT_FUNC))
I think this cause arm load failed.
Interesting. Nothing has changed here as ELF should always have these
symbols. It must be this test does something our testing before did not
highlight.
I also suspect we will have issues with the RAP files. Let me explain.
The code that was in my personal repo placed all global and local
symbols into a single 'externals' symbol table. This worked because we
had the awk hack to create the base image symbol table that used nm and
nm only provided the global symbols. When I came to do the rtems-syms
tool that takes a base kernel image and creates an exported symbols
table I incorrectly ended up with the local symbols of the kernel in the
symbol table and embedding that symbol table in the base image via the
double link pass method failed on the second link. As a result I cleaned
up the symbol code to have the rld::symbols classes load symbols into
separate global, weak and local table. I suspect the RAP code is now
only referencing the global table and so local symbols are not being
included in the symbol table. I need to review this code.
FYI, rap file are not included in the dl test?
This is coming as I have time. It is needed.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
