This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unwind support for Linux 2.6 vsyscall DSO


Roland McGrath writes:
 > > > 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.
 > 
 > Actually, I think this is not as useful an interface as one that fetches
 > the whole block for you.  There is another use for this call besides the
 > Linux-specific AT_SYSINFO_EHDR check: gcore.  We want gcore to produce
 > NT_AUXV notes in core dumps so that those core dumps can be used to extract
 > whatever AT_* information we could extract from core dumps written by a kernel.
 > 

It is useful if you want to apply a specific function to the entries
of the auxv vectors in a generic way while iterating. There are plenty
of other examples in gdb and bfd where this interface is used, albeit
it may not be the most efficient. I think you could still write an
iterator because it will be needed.

 > This is easy to add either way, but is cleaner, simpler, and more efficient
 > if it just writes the whole block uninterpreted than if it dissects and
 > reassembles it.

For the corefile case.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]