This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [wip] "info auxv"
On Tue, Nov 11, 2003 at 10:48:03AM -0500, Andrew Cagney wrote:
> >On Mon, Nov 10, 2003 at 06:16:23PM -0500, Andrew Cagney wrote:
> >
> >>This work-in-progress is more questions than answers.
> >>
> >>- Common code in "procfs.c" (tested) and "inftarg.c"
> >>It makes me wonder if the native inferior code should be re-arranged
> >>(has this come up before?).
> >>
> >>- The new files "auxv.[hc]" for parsing the file.
> >>Perhaphs it belongs in "procfs.c" but that gets me back to the first
> >>question - could the native inferior code be better structured?
> >
> >
> >>+ switch (auxv.type)
> >>+ {
> >>+ case AT_NULL:
> >>+ name = "End of vector";
> >>+ break;
> >
> >
> >Just a comment - as Roland said,
>
> Ref: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00265.html
>
> >the values in "elf/common.h" are not
> >authoritive, and I don't even think they match Solaris? Should this be
> >in common code?
>
> Note the "????" in that output:
> 2000 ??? 0x9f4
> Adding some sort of table is a todo item.
>
> I'm mainly worried about the "auxv.h" interface. For instance, how to
> provide a generic mechanism for fetching the entry-point address.
> Should "auxv.h" "define an OS independant set of enums and then map that
> onto the real numbers" (ala signals), or assume AT_ENTRY is constant
> across platforms (it actually is), or export an
> auxv_entry_point_address() and handle it all internally.
I'd say, assume it's a constant across platforms until/unless we hit
one where it isn't?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer