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