This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |