__lib_stack_end

[Mike Hearn <mike at navi dot cx>]

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