This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
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