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


Jim Blandy writes:
 > 
 > Roland McGrath <roland@redhat.com> writes:
 > 
 > > BFD is overkill for this (not that I'm saying BFD isn't overkill for
 > > everything).  There is no variation in the format among ELF flavors, it's
 > > just an even number of words in the format word size.  The very notion of
 > > an auxilliary vector is ELF-specific; if a non-ELF backend had something
 > > useful to export in the way of an auxilliary data from somewhere extraction
 > > interface, it seems doubtful it would be a useful abstraction to call the
 > > two the same thing in the frontend interface.  I don't have any objection
 > > to moving the parsing portion out somewhere else, but making it any more
 > > overblown than the few dozen lines of code it is would be pointless IMHO.
 > 
 > Yeah, I had in mind another elf-specific BFD function, like the one
 > that reads the solib data from memory.  All I'm suggesting is, take
 > the code that you've got, move it into bfd, and call it
 > bfd_elf_auxilliary_vector_sysinfo_ehdr.

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.

elena


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