This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 3.4 and glibc/nptl: Cancellation broken


Hi,

On Thu, 22 Jan 2004, Jakub Jelinek wrote:

> Another temporary solution can be linking all NPTL -fexceptions C
> programs with -shared-libgcc for the time being.

Note though that there is still something fishy about how glibc deals with 
this.  The test programs are linked with libgcc_eh.a, so they contain all 
the _Unwind_* functions.

Then glibc's pthread dlopens libgcc_s.so to get a pointer to various 
functions in it (like _Unwind_ForceUnwind), which it then calls directly.  
This circumvents the normal ELF lookup order of symbols which would use 
the symbols in the executable.

So, we have all the _Unwind_Functions twice in the executable image.  Now 
when cancelation occurs, glibc's pthread calls libgcc_s's 
_Unwind_ForceUnwind, which then later looks for the personality routine, 
which is the on in the executable, which then is called.  That personality 
routine calls _Unwind_SetGR which of course resolves to the copy in the 
executable.

So we have first some _Unwind* functions called from libgcc_s and later it 
calls indirectly some _Unwind* functinos from the executable.  Both have 
their own set of data structures (because it was static data).

At the very least this is extremely fragile.  IMHO glibc's pthread 
shouldn't circumvent ELF lookup rules by explicitely dlopening libgcc_s.  
Instead it should first look with RTLD_DEFAULT for the necessary symbols, 
and only if that results in nothing should it load libgcc_s itself (if 
this really is necessary at all).

> As soon as I implement (or anyone else beats me to do it)
> http://sources.redhat.com/ml/binutils/2003-12/msg00211.html
> GCC driver should link all non-static binaries with:
> --start-only-if-used -lgcc_s --end-only-if-used
> and things will work just fine.

How would this fix it?  No matter if the executable is also linked against 
libgcc_s, it still would be linked against libgcc_eh, so would provide the 
_Unwind_* symbols on it's own, which should then be choosen, instead of 
the symbols of libgcc_s.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]