Re: [PATCH] auxv support

[Andrew Cagney <cagney@gnu.org>]

>> The target vector update is fine.
> 
> 
> Sorry, I'm not entirely clear on how to read you.  Should I commit the
> whole patch I posted now?  (I'm not sure because you said "target vector
> update", and my patch includes to_xfer_partial target updates,
> to_make_corefile_notes target updates, and the `info auxv' user command.)
> 
> 
>> Would you be able to also knock up an "auxv.exp" test case?  
> 
> 
> Sure!  That is, I'd be happy to try.  Is there an especially good existing
> test case to take as the canonical template for a test such as this?
> 
> To be complete, a test should try a live process, try a real core file, and
> also try making a core file with gcore and then seeing that it matches the
> real process it was made from.  Can you point me to an example of a test
> that elicits core dumps and examines them?

I'd start with corefile.exp, and then delete.  Alternatively:
http://sources.redhat.com/ml/gdb-patches/2004-01/msg00610.html
where I've parked my bigcore.exp test - it compares the output from the 
core file with that of the running program (but note, this will have PIE 
have to be re-aranged for pie).

>> Something to run the command and, most notably, fail if "???" comes out
>> as the auxv entry name?
> 
> 
> That's not really a failure if it does.  Some random kernel change that we
> have no reason to know or care about could cause that to be the case on
> some system.  Do we want to make the gdb test suite complain whenever a new
> constant appears in nature that's not in our table?  

Yes, it's a bug - GDB should correctly display the name of all auxv 
entries for the system it is running on (if we don't do this, no one 
will ever notice, and the auxv table will never be updated ;-).

> If all you intend is a sanity check that we're not reading garbage values,
> there are at least one or two AT_FOO tags that I think can be reliably
> expected to be seen on every system that has an auxv at all.  So we could
> make sure those are there, or just make sure that at least some entries had
> names found.

If you can do this wow.

Look at the

>> Also, just file a bug reports that there isn't an equivalent MI auxv 
>> command, and that those other commands need need documenting.  I'll (or 
>> someone) will need to come back to that.
> 
> 
> Will do.  What about the remote protocol issue?  Should I file a bug for
> that too?  Conversely, I'd be happy to get that resolved right here and
> now, do the implementation work in remote.c and gdbserver.
> 
> 
> Thanks,
> Roland
>