From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5531 invoked by alias); 25 Feb 2004 04:03:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5515 invoked from network); 25 Feb 2004 04:03:11 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 25 Feb 2004 04:03:11 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AvqGL-0005fl-JB; Tue, 24 Feb 2004 23:03:09 -0500 Date: Wed, 25 Feb 2004 04:03:00 -0000 From: Daniel Jacobowitz To: Roland McGrath Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [PATCH] auxv support Message-ID: <20040225040309.GA21742@nevyn.them.org> Mail-Followup-To: Roland McGrath , Andrew Cagney , gdb-patches@sources.redhat.com References: <401AF1E1.7040908@gnu.org> <200402240350.i1O3oIFk027102@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402240350.i1O3oIFk027102@magilla.sf.frob.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00720.txt.bz2 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