This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
__lib_stack_end
- From: Mike Hearn <mike at navi dot cx>
- To: libc-alpha at sources dot redhat dot com
- Date: Fri, 10 Dec 2004 18:45:03 +0000
- Subject: __lib_stack_end
Hello,
I am distributing a binary that statically links Boehm GC. This program
attempts to weak link against __libc_stack_end as this information is
required for the garbage collector to work, however as the symbol isn't
exported weak from glibc this fails and a standard link is made.
I've done a bit of research and concluded that this symbol has an odd
history: it was apparently first public, then made private, then made
public again so it could be used by the non-exec-stack system. At all
points it was exported. I would like to check that I'm right: have I
misinterpreted what I'm seeing, or did this really happen?
If the symbol is now public again then presumably it will be stable from
now on. In this case, I would like to patch Boehm GC to use dlsym to get
__libc_stack_end rather than a #pragma weak, therefore bypassing the
symbol versioning system and allowing Boehm GC to work on all glibcs. Is
there some reason I should not do this?
I understand that this is an internal symbol and that Boehm GC should not
have been using it. The ideal solution from the perspective of GC
developers would be for a public API to be provided that provides this
information. Currently the fallback is parsing /proc on Linux, which is
complex and fragile. Is there any chance of this, or is __libc_stack_end
now considered officially public exported API?
So in summary:
- Am I right about this symbols history?
- Is using dlsym to bypass the 2.1 -> PRIVATE -> 2.1 switch kosher?
- Is there any chance of getting an officially exported __libc_stack_end
equivalent?
thanks -mike