[Gc] Patch for __libc_stack_end
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
> -----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
> > 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