This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: _*frame_* functions in glibc


Andreas Schwab <schwab@suse.de> writes:

> But how do you solve the problem of multiple occurences of the *frame*
> functions?  If you don't export them then it is impossible for libc to
> register the unwind information.

Well, past experiences showed us that we might want to have the
implementation change with a more recent compiler.  I.e., the libc (or
any other DSO) should not put the frame functions is stone.  They
should come from the main object.

This is not possible with libc not exporting functions alone.  We'll
have to put some work in libgcc as well.

I was thinking to have the DSO keep the actual frame handling funtion
undefined.  Either by link-line tricks (putting something in gcc's
specs file if -shared is used) or defining in crtbegin and crtbeginS
different versions of the frame function.

Then the register and unregister calls will be channeled all to the
functions in the main object.  The only problem with that is, so far,
that the functions in the main object are not visible without using
-rdynamic.  But I don't think this is a unsurmountable hurdle.  We can
have some linker magic which makes sure an object is always exported.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]