[Gc] Patch for __libc_stack_end

Boehm, Hans hans.boehm at hp.com
Wed Jan 26 11:57:05 PST 2005


I think that the only objections to using /proc are:

1) It might not be mounted.  I don't know how much of an issue
that is.  I would imagine that some embedded kernels might not
support it.  And there might be an issue if the application is
run as part of system start-up.

2) You're running a fair amount of extra code at process start-up
to rediscover something that's already stored in a glibc variable.

My concern with dlsym is that I was under the impression that
dlopen/dlsym support for static executables also varied with
library versions.  And static executables presumably need to be
explicitly linked with -ldl, which I've otherwise tried to avoid.

Perhaps we should leave 6.4 as it is, until I get a complaint about
the /proc dependence?  (You can still work around that
by explicitly setting GC_stackbottom (and GC_register_stackbottom
on IA64) before the collector/allocator is invoked.)

It sounds like the current 6.4 solution works for everybody on this
list.

Hans

> -----Original Message-----
> From: Mike Hearn [mailto:mike at navi.cx]
> Sent: Monday, January 24, 2005 12:48 PM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: RE: [Gc] Patch for __libc_stack_end
> 
> 
> On Mon, 2005-01-24 at 12:21 -0800, Boehm, Hans wrote:
> > Thanks for pursuing this.
> > 
> > Does this approach work in a completely statically-linked
> > executable?
> 
> Yep. I'm shipping Inkscape (inkscape.org) nightly autopackages
> (autopackage.org) which statically link libgc and the C++ 
> support code.
> It seems to work OK there (or no problem reports yet). 
> 
> I don't really know if it's using __libc_stack_end or just 
> falling back
> though: while the code looks correct to my eye I haven't tested it
> extensively.
> 
> > Version 6.4 of the collector no longer checks 
> __libc_stack_end by default.
> > That unfortunately means it relies on /proc, which isn't perfect
> > either.
> 
> How is /proc not good? I guess while it's more code and less clean, if
> it works everywhere but this does not the __libc_stack_end code has no
> reason to exist anymore ...
> 
> thanks -mike
> 
> 


More information about the Gc mailing list