Re: [PATCH] auxv support

[Daniel Jacobowitz <drow@mvista.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