unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> There should be an iterator over the entries in the /proc/pid/auxv
> file with a callback that processes each entry. So that the iterator
> could be used not just for finding the AT_SYSINFO_EHDR entry. 

Ok, an iterator interface is fine with me, just marginally less efficient
than the searcher when only one tag is actually used (and more efficient if
many tags are used).  (I had not proposed any function that would be useful
solely for AT_SYSINFO_EHDR, though that was one of Jim's early
suggestions.)  If others agree this is the right interface for a target_ops
addition, I will write that patch.

> I think the number of iterations would be your size_t above divided by
> the size of an auxv_t or something similar.

Indeed.

> The first thing that happens is that the breakpoint inserted at the
> dynamic linker is hit, at which point gdb gets to add the shlibs.

Obviously that's not the first thing, since inserting the breakpoint in the
dynamic linker happens before that.  It's ideal to do the vsyscall DSO
setup before letting the dynamic linker run at all.  That way you have that
information in case you get a signal in the early part of dynamic linker
startup, or attach to a process that is for some reason blocked in a system
call in that early stage, and want to see a backtrace to understand the
state.

> enable_break: search for .interp in /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break
> enable_break: opening /lib/ld-linux.so.2
> elf_locate_base: DT_DEBUG entry has value 0x0
> svr4_current_sos: no DT_DEBUG found

I don't see your debugging code in mainline gdb and so I can only guess
what these messages mean in terms of the code. 

Are you sure this doesn't mean it looked at the sh process before it
exec'd?  It wouldn't find anything there because it would be looking for
DT_DEBUG from the .dynamic address of the "break" binary and sh's layout is
different (so it's reading arbitrary other data and not finding the tag).

> Since we need the iterator method, this read/parse becomes a very
> small piece and fits nicely in linux-proc.c in the live inferior
> case. For the corefile/remote case, you would ask bfd for the .auxv
> section of the core file and parse that in order to get an element of
> the vector and this is also something that can be in gdb, unless you
> want to reuse that in some other tool.

We are all clear on the steps that need to be performed.  The part that
parses the format and deals with the target wordsize question and
byteswapping, is common work between the live and core cases that might use
a shared function rather than duplicative source code.  That is what we
have been discussing.

You said "corefile/remote case", but looking for a .auxv section applies
only to core files.  I don't think we have discussed the remote case.  It
would require the remote stub reading the local /proc/PID/auxv file and
giving the information back to gdb.  I'm not aware of anything in the
remote protocol to allow that.


Thanks,
Roland