Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath <roland at redhat dot com>]

> 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.

> 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.  

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.


Thanks,
Roland