Hi Michael, Le mercredi 11 mars 2015, 23:10:45 Thomas Preud'homme a écrit : > Le dimanche 22 février 2015, 06:13:21 Michael Matz a écrit : > > > > And I pulled my hair out again when tracing the different paths the > > linker can go through in different modes, and how the relocs and symbol > > values change over the course of compilation. One of those days ... :-) > > I think that's the next thing I'm going to work on. And then maybe simplify > the Makefile and configure machinery but that's less fun and easier to break > in my experience. I already started looking at bind_exe_dynsyms and why > it's needed. All I can say for now is that without it the linking fails on > x86-64 because of unresolved __libc_start_main. This is unsurprisingly > provided by the libc. >
> From what I understand a symbol is considered unresolved if it cannot be > found in the dynsym section of the output file and it seems only > relocation handled in build_got_entries leads to a dynsym being created. > However > __libc_start_main has a R_X86_64_PC32 that doesn't lead to a got + plt so > no entry created in dynsym. I was a bit puzzled because I saw symbols are resolved when a file is loaded that define them (in tcc_load_object_file). The reason this doesn't happen here is that the symbol is provided by libc.so.6 and the function that loads dynamic libraries (tcc_load_dll) only look for undefined symbols in dynsymtab_section rather than symtab_section. There might be an obvious reason but I'm not sure why symbols from object files and libraries are handled differently in terms of name resolution. Of course relocation happens differently but name resolution should be the same, shouldn't it? > > I probably won't write any code tonight and it'll take time but we'll get > things cleaned up eventually. To be honest I just finally started really working on it (I already check a small thing in the code last time before I wrote the mail and then another small bit later). I didn't write anything yet but already found a bug in tcc: the name resolution put the program last in the global order rather than first. I confirmed it with the following example: % cat program_resolve_lib.c #include <stdio.h> int foo (const char * __restrict, ...); int printf (const char * __restrict s, ...) { puts ("Program's printf"); return puts (s); } int main (void) { return foo ("Hello, world!"); } % cat libprogram_resolve_lib.c #include <stdio.h> int foo (const char * __restrict s, ...) { return !printf (s); } I compiled and linked the library with gcc, and compiled the main with gcc as well. When linking the main with gcc I get: Program's printf Hello, world! But when linking with tcc I get: Hello, world! (without newline after). I also found a possible speed improvement. Currently tcc_load_dll load dll recursively. That should only be necessary for tcc_run but that require changing bind_libs_dynsyms (which requires changing anyway because of the bug above). I'll let you know of my progress if you are interested. Anyway, as usual with the linker, I'm having a lot of fun. :-) Best regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel