Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy <jimb@redhat.com>]

Roland McGrath <roland@redhat.com> writes:
> > I think you can rely on SOLIB_ADD not being called too early.  It would
> > be a bug if we ever called it before the shell execs the executable under
> > debug, because we use the VMA of the .dynamic section of the executable
> > file to find the dynamic structure in the inferior's memory anyway.  We
> > couldn't even find the shell's shared library list.
> 
> Right, it would fail to find any list at all.  If it treats that as "empty
> list" then this won't be a change from before and so it's a harmless no-op.
> Are we sure that is not what is happening now?  If it is, it's harmless now
> but having the auxv-reading done too early would not be harmless.

Well, child_create_inferior calls fork_inferior, passing ptrace_him as
the init_trace_fun.  ptrace_him calls startup_inferior to get past the
shell.  startup_inferior uses 'resume' to get past the various traps
that occur before we reach the actual program under debug; resume,
unlike proceed (gotta love it) does not insert breakpoints, and thus
will never yield BPSTAT_WHAT_CHECK_SHLIBS, and thus will never call
SOLIB_ADD.  I verified this by actually starting up a program and
watching things happen.

So, yes, we're sure.  Happy?  :)

(To be honest, I'm never sure of much when dealing with the program
startup and event analysis code...)

> > I disagree with moving the read of auxv to bfd. Gdb already processes
> > plenty of /proc files (on Solaris using 2 interfaces), and has target
> > methods defined for these, so I would treat the auxv case just like the
> > others.
> 
> What we have been discussing most recently is only a BFD utility function
> to examine raw auxv blocks that have already been read in somehow.
> i.e., a trivial helper function that these target methods would use.
> It doesn't matter to me whether this is in bfd/elf.c or gdb/elfread.c.

I can see going either way.  The code in question just does a bit of
grunging with ElfNN_External_Auxv and ElfNN_Internal_Auxv, but has no
contact with other GDB stuff, so I figured it should go in BFD.  The
involvement of /proc wasn't really at issue --- when you're processing
cores, it isn't involved at all.