Re: [PATCH] auxv support

[Roland McGrath <roland at redhat dot com>]

> 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?

> 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?  

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.

> 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