Re: [Tinycc-devel] realpath(x, NULL) doesn't work with tcc(1)

[Steffen Nurpmeso]

Good morning! :)

Michael Matz <address@hidden> wrote:
 |On Thu, 2 Jun 2016, Steffen Nurpmeso wrote:
 |> Well, have i yet asked this?  I think no...
 |> It's like that for a long time, ever since i use tcc(1) (autumn
 |> last year):
 |>
 |>  address@hidden tmp]$ cat t.c
 |>  #include <stdlib.h>
 |>  int main(void){
 |>     char *x = realpath(".", NULL);
 |>
 |>     return (x != NULL) ? 0 : 1;
 |>}
 |>  address@hidden tmp]$ for i in clang gcc tcc; do \
 |>    $i -o zt t.c && ./zt; echo $i: $?;\
 |>  done
 |>  clang: 0
 |>  gcc: 0
 |>  tcc: 1
 |>
 |> tcc(1) only gets realpath(3) with buffer argument right, i wonder
 |> what that can be?
 |
 |Wow.  You've run into the result of an unimplemented feature of tcc, which 
 |I never thought would matter in practice ;-)  I'll explain, bear with me: 

 |accepting NULL as second argument.  But glibc also has a strict no change 
 |in interfaces policy, and this was a visible change, so symbol versioning 
 |had to be used to provide the old behaviour for old applications (those 

 |"when it supports symbol versions" is of course the crucial part: tcc as 
 |ELF linker doesn't.  So it leaves in an unversioned reference to 
 |'realpath' in the executable and so the dynamic linker is free to choose 
 |any.  Now the usual ld.so uses a (normally) sensible heuristic for 
 |choosing which one when there are several: for references from dlsym it 
 |uses the newest available one, for references from applications that have 
 |no symbol version information whatsoever it uses the oldest symbol 
 |version, on the grounds that apps without any symversion info must have 
 |been created before the ELF implementation provided them, i.e. they must 
 |be very very old applications.
 |
 |This reasoning breaks down with an incomplete link editor like tcc.  It 
 |creates new applications that are regarded as very old by ld.so.  So, what 
 |you see is ld.so resolving to the old implementation of realpath, instead 
 |of the current one.

Thanks for your time and the whole picture!  Hm, symbol versioning
didn't really enter my world yet -- i know in FreeBSD you now even
find linker scripts what should be some "beefy library", well.
Terribly non-understandable choices regarding dlsym(3)/normal
link!  But now i see, this is the reason for dlvsym(3), a-ha.
I never tried, but i assume it doesn't take a POSIX/xy version
string (and what should that really be).  Please excuse that i'm
too lazy to find and look through the source code.

 |Short of implementing proper ELF symbol versioning in tcc there's only an 
 |ugly work-around: you could use a different link editor.  Perhaps there's 
 |somewhen a rainy weekend when the former can be done.

I'm even a little bit hooked to look somewhat deeper into ELF,
i have the standards laying around for a loooong time:

  address@hidden ]$ ll ~/arena/docs.coding/elf-*
  .. 525024 18 Apr  2012 /home/steffen/arena/docs.coding/elf-v1.2.pdf
  .. 630410  8 May  2012 /home/steffen/arena/docs.coding/elf-tls-abi.pdf

That is unbelievable four years; maybe in the summer; would
actually be nice to have it in tcc(1), too, since it is so much
faster than clang/gcc!

Ciao,

--steffen