This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] auxv support
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: Andrew Cagney <cagney at gnu dot org>, gdb-patches at sources dot redhat dot com
- Date: Tue, 24 Feb 2004 23:03:09 -0500
- Subject: Re: [PATCH] auxv support
- References: <401AF1E1.7040908@gnu.org> <200402240350.i1O3oIFk027102@magilla.sf.frob.com>
On Mon, Feb 23, 2004 at 07:50:18PM -0800, Roland McGrath wrote:
> 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".)
Here's the board file I use to run locally, gross hacks and all.
========================
# gdbserver running native.
load_generic_config "gdbserver";
process_multilib_options "";
# The default compiler for this target.
set_board_info compiler "[find_gcc]";
# We will be using the standard GDB remote protocol
set_board_info gdb_protocol "remote"
# Path to the gdbserver executable, if required.
set_board_info gdb_server_prog \
"../gdbserver/gdbserver"
# Name of the computer whose socket will be used, if required.
set_board_info sockethost "localhost:"
# Port ID to use for socket connection
# set_board_info gdb,socketport "4004"
# Use techniques appropriate to a stub
set_board_info use_gdb_stub 1;
# This gdbserver can only run a process once per session.
set_board_info gdb,do_reload_on_run 1;
# There's no support for argument-passing (yet).
set_board_info noargs 1
# Can't do input (or output) in the current gdbserver.
set_board_info gdb,noinferiorio 1
# Can't do hardware watchpoints, in general
set_board_info gdb,no_hardware_watchpoints 1;
set_board_info protocol foonevyn
proc foonevyn_download { board host dest } {
return $host
}
proc foonevyn_spawn { board cmd } {
global board_info
set baseboard [lindex [split $board "/"] 0]
set board_info($baseboard,isremote) 0
set foo [remote_spawn $board $cmd]
set board_info($baseboard,isremote) 1
return $foo
}
========================
> 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).
Perhaps arrange to distinguish in the error message?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer