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


On Thu, Jun 15, 2000 at 09:34:18AM -0700, Ulrich Drepper wrote:
> 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.

If those functions are referenced in the DSO in any way, they
will be exported from the main object. A reference can be as
simple as

static void *(foo) () = funtion;


H.J.


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