Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Oct 06, 2003 at 04:59:52PM -0700, Roland McGrath wrote:
> > 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.

I agree that this would be nice.  This'll require a new hook. 
Preferably it should be done using the new observers mechanism.

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

No, but extending it to do so is easy (and vital).  I'll do it later.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer