[Gc] __libc_stack_end not weak

Boehm, Hans hans.boehm at hp.com
Thu Oct 21 10:41:17 PDT 2004


__libc_stack_end is used, when available, because it's by far the
easiest and fastest way to get access to the stack base under Linux.
There was discussion of fixing this by allowing use of
pthread_getattr_np in single threaded code, but I haven't checked
recently whether that's in current glibc versions.

The alternatives of reading /proc, or walking the stack until you
encounter a fault, are also implemented, but have disadvantages.
(/proc may not be mounted; the fault is annoying when you try to
debug, and results in lots of bogus bug reports.  And the result
may be too conservative.)

This comes up regularly.  I'd be happy to fix it if I were convinced
there were a better alternative.  And I'll grudgingly remove the
test for __libc_stack_end when I'm convinced that it fails on all
common systems, and thus no longer buys anything.  But the current
code should work correctly whether or not that symbol is visible.

I've also seen bug reports similar to Ben's on a few occasions.
But the problem seems to come and go.  My impression from the past
was that it was a GNU tool chain bug related to weak and
versioned symbols, and that it only exists in a few versions,
none of which I run.

When I use the same readelf command that Ben used on a version of gctest
that was compiled with gcc3.3.4 (on Itanium, though I doubt that
matters) and ld2.14.90, it does list __libc_stack_end as weak.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Mike Hearn
> Sent: Thursday, October 21, 2004 8:59 AM
> To: Ben Hutchings
> Cc: GC List
> Subject: Re: [Gc] __libc_stack_end not weak
> 
> 
> Ben Hutchings wrote:
> > os_dep.c uses "#pragma weak __libc_stack_end" so we should be able
> > to live without it.  However, when I look at the executable with
> > "readelf -Ds", I see:
> > 
> > Symbol table for image:
> >   Num Buc:    Value  Size   Type   Bind Vis      Ndx Name
> > ...
> >   149 128: 08270a44     4  OBJECT GLOBAL DEFAULT  24 
> __libc_stack_end
> > 
> > Shouldn't there be a "WEAK" in the Bind column?  What might be the
> > cause for it being "GLOBAL" instead?
> 
> Does it work if you change the #pragma to __attribute__((weak)) ?
> 
> More to the point, why is GC using internal symbols that may 
> disappear 
> or change semantics at any time?
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list