Re: [wip] "info auxv"

[Daniel Jacobowitz <drow@mvista.com>]

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