New "info auxv" command and $auxv variable?

New "info auxv" command and $auxv variable?

[Andrew Cagney]

Hello,

In implementing a mechanism to query values from the the target's AUXV 
(/proc/$$/auxv) I decided I might as well add a generic command:

	(gdb) info auxv
	Entry point 0x1234
	...
	(gdb)

that listed the contents of the processes auxv table.

But why stop there?  What about a builtin $auxv variable, a struct, vis:

	(gdb) print $auxv
	$1 = { entry = 0x1234, ... }

Oh, and I guess:

	(gdb) interpreter mi --info-auxv
	^ok,result={entry="0x1234",...}

Thoughts?
Andrew

PS: Can any one point me at an official GNU/Linux or, I guess *BSD, 
distro that supports /proc/$$/auxv?  So far I've only got Solaris :-/

PPS: The second one is actually tricky.  It requires a type bound to the 
lifetime of the inferior - it is only in querying the inferior that the 
fields can be determined.  An alternative would be to always create the 
type and then shove it into a type system bcache - ensuring that only 
one struct of that form exists.

Re: New "info auxv" command and $auxv variable?

[Daniel Jacobowitz]

On Tue, Nov 04, 2003 at 11:46:00AM -0500, Andrew Cagney wrote:
> Hello,
> 
> In implementing a mechanism to query values from the the target's AUXV 
> (/proc/$$/auxv) I decided I might as well add a generic command:
> 
> 	(gdb) info auxv
> 	Entry point 0x1234
> 	...
> 	(gdb)
> 
> that listed the contents of the processes auxv table.

This would be useful.

> But why stop there?  What about a builtin $auxv variable, a struct, vis:
> 
> 	(gdb) print $auxv
> 	$1 = { entry = 0x1234, ... }
> 
> Oh, and I guess:
> 
> 	(gdb) interpreter mi --info-auxv
> 	^ok,result={entry="0x1234",...}
> 
> Thoughts?

I don't know if there's enough utility to bother doing this, though...
the only thing likely to be generally useful is the entry point (and
maybe the vsyscall address).

> PS: Can any one point me at an official GNU/Linux or, I guess *BSD, 
> distro that supports /proc/$$/auxv?  So far I've only got Solaris :-/

There aren't any released distros that do, as far as I know.  You'd
have to run a 2.6.0-test9 kernel.  Unless RH has backported it to their
2.4 patches?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New "info auxv" command and $auxv variable?

[Andrew Cagney]

> But why stop there?  What about a builtin $auxv variable, a struct, vis:
>> 
>> 	(gdb) print $auxv
>> 	$1 = { entry = 0x1234, ... }
>> 
>> Oh, and I guess:
>> 
>> 	(gdb) interpreter mi --info-auxv
>> 	^ok,result={entry="0x1234",...}
>> 
>> Thoughts?
> 
> 
> I don't know if there's enough utility to bother doing this, though...
> the only thing likely to be generally useful is the entry point (and
> maybe the vsyscall address).

If we start making the CLI more usable by making this stuff available 
people might start using it :-)

Anyway, the MI stuff is almost free (the code is common).  The $auxv 
variable is a bit tricky but still ok.  Could just add $entrypoint?

Andrew

Re: New "info auxv" command and $auxv variable?

[Daniel Jacobowitz]

On Tue, Nov 04, 2003 at 02:59:04PM -0500, Andrew Cagney wrote:
> >But why stop there?  What about a builtin $auxv variable, a struct, vis:
> >>
> >>	(gdb) print $auxv
> >>	$1 = { entry = 0x1234, ... }
> >>
> >>Oh, and I guess:
> >>
> >>	(gdb) interpreter mi --info-auxv
> >>	^ok,result={entry="0x1234",...}
> >>
> >>Thoughts?
> >
> >
> >I don't know if there's enough utility to bother doing this, though...
> >the only thing likely to be generally useful is the entry point (and
> >maybe the vsyscall address).
> 
> If we start making the CLI more usable by making this stuff available 
> people might start using it :-)
> 
> Anyway, the MI stuff is almost free (the code is common).  The $auxv 
> variable is a bit tricky but still ok.  Could just add $entrypoint?

Oops, I misread you.  The MI command is definitely a good idea -
"-info-auxv", right?

I think $entrypoint is more useful than $auxv.  Should we have a
reserved namespace for these things?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New "info auxv" command and $auxv variable?

[Andrew Cagney]

> If we start making the CLI more usable by making this stuff available 
>> people might start using it :-)
>> 
>> Anyway, the MI stuff is almost free (the code is common).  The $auxv 
>> variable is a bit tricky but still ok.  Could just add $entrypoint?
> 
> 
> Oops, I misread you.  The MI command is definitely a good idea -
> "-info-auxv", right?

Yep.

> I think $entrypoint is more useful than $auxv.  Should we have a
> reserved namespace for these things?

Ah, that.  Ref: Replace $fp with $frame / $gdbframe / $gdb.frame
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=327

Never been a decision.  $ variables are reserved for both builtins and 
registers but the two overlap.  Ok, here's something warped:

	$.auxv

(i.e., "dollar dot auxv" so you know I didn't make a typo :-)

Andrew

Re: New "info auxv" command and $auxv variable?

[Daniel Jacobowitz]

On Tue, Nov 04, 2003 at 03:15:08PM -0500, Andrew Cagney wrote:
> >If we start making the CLI more usable by making this stuff available 
> >>people might start using it :-)
> >>
> >>Anyway, the MI stuff is almost free (the code is common).  The $auxv 
> >>variable is a bit tricky but still ok.  Could just add $entrypoint?
> >
> >
> >Oops, I misread you.  The MI command is definitely a good idea -
> >"-info-auxv", right?
> 
> Yep.
> 
> >I think $entrypoint is more useful than $auxv.  Should we have a
> >reserved namespace for these things?
> 
> Ah, that.  Ref: Replace $fp with $frame / $gdbframe / $gdb.frame
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=327
> 
> Never been a decision.  $ variables are reserved for both builtins and 
> registers but the two overlap.  Ok, here's something warped:
> 
> 	$.auxv
> 
> (i.e., "dollar dot auxv" so you know I didn't make a typo :-)

Eek?  I'd prefer $gdb.auxv or $_auxv.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New "info auxv" command and $auxv variable?

[Andrew Cagney]

> Yep.
>> 
> 
>> >I think $entrypoint is more useful than $auxv.  Should we have a
>> >reserved namespace for these things?
> 
>> 
>> Ah, that.  Ref: Replace $fp with $frame / $gdbframe / $gdb.frame
>> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=327
>> 
>> Never been a decision.  $ variables are reserved for both builtins and 
>> registers but the two overlap.  Ok, here's something warped:
>> 
>> 	$.auxv
>> 
>> (i.e., "dollar dot auxv" so you know I didn't make a typo :-)
> 
> 
> Eek?  I'd prefer $gdb.auxv or $_auxv.

There is always the chance that some architecture has a register called 
"gdb".  Don't laugh, there's already a "gdt" register that's too close 
for comfort :-(

Looking at the doco:

> @cindex @code{$}
> @cindex @code{$$}
> @cindex history number
> The values printed are given @dfn{history numbers} by which you can
> refer to them.  These are successive integers starting with one.
> @code{print} shows you the history number assigned to a value by
> printing @samp{$@var{num} = } before the value; here @var{num} is the
> history number.
> 
> To refer to any previous value, use @samp{$} followed by the value's
> history number.  The way @code{print} labels its output is designed to
> remind you of this.  Just @code{$} refers to the most recent value in
> the history, and @code{$$} refers to the value before that.
> @code{$$@var{n}} refers to the @var{n}th value from the end; @code{$$2}
> is the value just prior to @code{$$}, @code{$$1} is equivalent to
> @code{$$}, and @code{$$0} is equivalent to @code{$}.

So "$.frame" won't work. (=== "$$0.frame" === "<history-value>.frame") 
-> your safe :-)

So its' looking somewhat bleakly like $_frame :-)

Andrew

Re: New "info auxv" command and $auxv variable?

[Eli Zaretskii]

> Date: Tue, 04 Nov 2003 11:46:00 -0500
> From: Andrew Cagney <ac131313@redhat.com>
> 
> 	(gdb) info auxv
> 	Entry point 0x1234
> 	...
> 	(gdb)
> 
> that listed the contents of the processes auxv table.
> 
> But why stop there?  What about a builtin $auxv variable, a struct, vis:
> 
> 	(gdb) print $auxv
> 	$1 = { entry = 0x1234, ... }
> 
> Oh, and I guess:
> 
> 	(gdb) interpreter mi --info-auxv
> 	^ok,result={entry="0x1234",...}
> 
> Thoughts?

Yes, please!