Re: remote/2474: target extended-remote with --multi does not workon MIPS

[Daniel Jacobowitz <drow at false dot org>]

The following reply was made to PR remote/2474; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: Doug Graham <dgraham@nortel.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: remote/2474: target extended-remote with --multi does not work
	on MIPS
Date: Mon, 14 Jul 2008 13:30:52 -0400

 On Mon, Jul 14, 2008 at 01:19:04PM -0400, Doug Graham wrote:
 > Thanks for looking at this.  I solved it for now by removing the call to
 > require_running() from the "qXfer:features:read:" case of handle_query().
 > I didn't see why this query couldn't be made without a running target,
 > and so far, it seems to work fine, at least with the limited testing I've
 > done on it on MIPS and x86 targets.  If the "features" query succeeds,
 > gdb never goes on to ask for the MIPS registers.
 
 It's a bit problematic, because different processes can have different
 feature lists.  My canonical example is if one has an emulated FPU and
 another has an incompatible hardware FPU; this used to happen on ARM.
 Another is one might have 32-bit registers and another 64-bit
 registers.
 
 GDB will always re-query later, so the workaround is safe, but we'll
 look into the bug (time permitting, of course :-).
 
 > I also found another bug in server.c, related to not NULL-terminating
 > the argument list passed to exec() (and later to free()) when the app
 > is restarted without the host passing it an argument list (so the server
 > uses the default).  My patch for both problems is attached.
 
 Thanks!  I'll take a look at this too.  I'm happy to see someone
 taking advantage of --multi :-)
 
 -- 
 Daniel Jacobowitz
 CodeSourcery