Re: [Tinycc-devel] [PATCH] TCC arm64 back end

[Thomas Preud'homme]

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.