This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] auxv support
- From: Andrew Cagney <cagney at gnu dot org>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>,gdb-patches at sources dot redhat dot com
- Date: Tue, 24 Feb 2004 22:59:12 -0500
- Subject: Re: [PATCH] auxv support
- References: <200402240350.i1O3oIFk027102@magilla.sf.frob.com>
I've written a new test case for the live process support, grokking native
core files, and gcore. It works peachy on Linux 2.6 and on Solaris. It
should work omitting the native core dump part for remote, but I don't know
off hand how to test that. Are there runtest arguments to make it run
gdbserver for tests? (I tried --target_board linux-gdbserver, but that
tries to do "rsh linux-gdbserver ../gdbserver/gdbserver ..." instead of
running gdbserver locally. I can't figure out how to make it not use rsh,
or use a hostname other than "linux-gdbserver".)
I'd not worry (I think that should instead use "(gdb) target remote
|gdbserver").
However, on a system that does not support getting the auxv data, it shows
three failures. What is the right thing to do about this? The difficulty
is that the error from `info auxv' does not distinguish an error/bug in
reading the data from the target code not supporting auxv access or from
the native system not supporting the access even though the gdb target code
does (e.g. Linux < 2.6).
Just a few tweaks:
2004-02-23 Roland McGrath <roland@redhat.com>
* gdb.base/auxv.exp: New file.
Index: testsuite/gdb.base/auxv.exp
===================================================================
RCS file: testsuite/gdb.base/auxv.exp
diff -N testsuite/gdb.base/auxv.exp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ testsuite/gdb.base/auxv.exp 24 Feb 2004 03:06:02 -0000
@@ -0,0 +1,186 @@
+# Test `info auxv' and related functionality.
+
+# Copyright 1992,93,94,95,96,97,98,99,2000,04 Free Software Foundation, Inc.
Just write the years in full.
+set testfile "coremaker2"
+set srcfile ${testfile}.c
Here a new file "auxv.c" is prefered for the new test (making a copy of
coremaker2.c is ok).
Otherwize, remember to post the final patch when committing,
thanks,
Andrew
+set binfile ${objdir}/${subdir}/${testfile}
+set corefile ${objdir}/${subdir}/${testfile}.corefile
+set gcorefile ${objdir}/${subdir}/${testfile}.gcore