Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Oct 04, 2003 at 03:01:09PM -0700, Roland McGrath wrote:
> > Yes, since this is when solibs are normally loaded anyway.
> 
> Ok.  I was concerned that it might just try to look at the shell, where its
> symbols wouldn't match and it would just ignore those errors.  Getting the
> auxv information will always work, but could be wrong information if there
> is another exec, so that would not be as resilient as SOLIB_ADD now is.
> To wit, infrun.c:1352:
> 
>     case TARGET_WAITKIND_LOADED:
>       /* Ignore gracefully during startup of the inferior, as it
>          might be the shell which has just loaded some objects,
>          otherwise add the symbols for the newly loaded objects.  */
> 
> If this comment is accurate and I'm understanding its context correctly,
> the problem I just described is in fact a problem.

It is not accurate.  TARGET_WAITKIND_LOADED isn't currenty used for
non HP/UX targets.

> > An issue is whether it gets called early enough, i.e. before the
> > dynamic linker breakpoint is hit, or at all for static applications. 
> > We'll have to see.
> 
> Indeed, it doesn't look to me like it is, except for the attach case.
> Aside from attach_command, all the SOLIB_ADD calls in infrun.c are
> conditional on some kind of "shlib loaded" event.  I am presuming those
> don't happen at exec.  

We don't want to SOLIB_ADD before the dynamic linker has gotten a
chance to initialize, I suspect.  Let me think about it; let's fix the
dynamic case first.

> Incidentally, I'm also noticing another case we haven't been discussing
> directly.  In addition to the core, attach, and run scenarios, there is
> "follow exec" apparently.  I ran across this in looking for the earliest
> places insert_breakpoints is called, which seems like around the same time
> the auxv examination and vsyscall DSO setup should be done.

Don't worry about follow_exec.  It's currently broken and needs some
serious redesigning.  I haven't had a chance to revisit this since I
fixed fork following.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer