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

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

[drow]

Synopsis: target extended-remote with --multi does not work on MIPS

Responsible-Changed-From-To: unassigned->drow
Responsible-Changed-By: drow
Responsible-Changed-When: Mon Nov 24 18:05:48 2008
Responsible-Changed-Why:
    Thanks for the report.  I've fixed both this and the command line vRun parsing bug in CVS now.
State-Changed-From-To: open->closed
State-Changed-By: drow
State-Changed-When: Mon Nov 24 18:05:48 2008
State-Changed-Why:
    Fixed in CVS

http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2474

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

[Daniel Jacobowitz]

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

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

[Doug Graham]

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

From: "Doug Graham" <dgraham@nortel.com>
To: Daniel Jacobowitz <drow@false.org>
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:19:04 -0400

 --Bu8it7iiRSEf40bY
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 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.
 
 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,
 Doug.
 
 -----Original Message-----
 Date: Mon, 14 Jul 2008 12:58:59 -0400
 From: Daniel Jacobowitz <drow@false.org>
 To: dgraham@nortel.com
 Cc: gdb-gnats@sources.redhat.com
 Subject: Re: remote/2474: target extended-remote with --multi does not
  work	on MIPS
 
 On Wed, Jul 09, 2008 at 01:20:54AM -0000, dgraham@nortel.com wrote:
 > When gdbserver is started with --multi on a MIPS target,
 > and a MIPS targetted GDB is connected to the server with
 > "target extended-remote <ip>:<port>", the extended-remote
 > command fails, and I think drops back to non-extended mode.
 > The reason appears to be that GDB is attempting to fetch
 > the MIPS registers, but there is not yet any live process
 > on the target to fetch the registers from.  Here is the packet
 > exchange:
 
 Thanks for the report.  This is definitely a bug; the register check
 shouldn't be done when no process is running.  Unfortunately it is a
 little tricky to fix... until the ? packet is sent, we do not know if
 the process is running yet.  But until we have a description, we can
 not fully parse the reply to ?.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery
 
 --Bu8it7iiRSEf40bY
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="gdb-6.8.patch"
 
 *** ./gdb/gdbserver/server.c	2008/07/09 21:10:26	1.1
 --- ./gdb/gdbserver/server.c	2008/07/09 23:50:43
 ***************
 *** 453,459 ****
 --- 453,477 ----
         const char *document;
         char *annex;
   
 + #if 0
 +       /*
 +        * Taking this out because it breaks when using --multi on MIPS.
 +        * When the debugger connects, we don't have a running target yet,
 +        * but the debugger issues this query, which fails.  This
 +        * same failure occurs on x86 and ppc targets too, but the mips
 +        * debugger falls back to attempting to read the register set
 +        * and checking the size of the register set to see what kind of
 +        * target it's dealing with.  That register read also fails because
 +        * there is no active target, causing the "target extended-remote"
 +        * command to fail as a whole.  x86 and ppc do not fall back to
 +        * reading the target register set, although I don't know what they
 +        * do do.
 +        *
 +        * Is there any reason we really need a running target in order to
 +        * return this XML info anyway?
 +        */
         require_running (own_buf);
 + #endif
   
         /* Check for support.  */
         document = get_features_xml ("target.xml");
 ***************
 *** 877,883 ****
 --- 895,913 ----
   	  return 0;
   	}
   
 + #if 0
         new_argv[0] = strdup (program_argv[0]);
 +       new_argv[1] = NULL;
 + #else
 +       /*
 +        * Original code had two problems: it didn't NULL terminate
 +        * new_argv if an argument vector was not provided from the host
 +        * this time, and it loses any arguments following the program name
 +        * in that scenario too.
 +        */
 +       free (new_argv);
 +       goto skip_useless_copy;
 + #endif
       }
   
     /* Free the old argv.  */
 ***************
 *** 889,894 ****
 --- 919,925 ----
       }
     program_argv = new_argv;
   
 + skip_useless_copy:
     *signal = start_inferior (program_argv, status);
     if (*status == 'T')
       {
 
 --Bu8it7iiRSEf40bY--

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

[Daniel Jacobowitz]

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

From: Daniel Jacobowitz <drow@false.org>
To: 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 12:58:59 -0400

 On Wed, Jul 09, 2008 at 01:20:54AM -0000, dgraham@nortel.com wrote:
 > When gdbserver is started with --multi on a MIPS target,
 > and a MIPS targetted GDB is connected to the server with
 > "target extended-remote <ip>:<port>", the extended-remote
 > command fails, and I think drops back to non-extended mode.
 > The reason appears to be that GDB is attempting to fetch
 > the MIPS registers, but there is not yet any live process
 > on the target to fetch the registers from.  Here is the packet
 > exchange:
 
 Thanks for the report.  This is definitely a bug; the register check
 shouldn't be done when no process is running.  Unfortunately it is a
 little tricky to fix... until the ? packet is sent, we do not know if
 the process is running yet.  But until we have a description, we can
 not fully parse the reply to ?.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

remote/2474: target extended-remote with --multi does not work on MIPS

[dgraham]

>Number:         2474
>Category:       remote
>Synopsis:       target extended-remote with --multi does not work on MIPS
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 09 01:28:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Doug Graham (not exactly sure what to put here)
>Release:        6.8
>Organization:
>Environment:
mipsel-linux-uclibc and mips64-octeon-linux-gnu targets
Linux x86 host
GDB 6.8
>Description:
When gdbserver is started with --multi on a MIPS target,
and a MIPS targetted GDB is connected to the server with
"target extended-remote <ip>:<port>", the extended-remote
command fails, and I think drops back to non-extended mode.
The reason appears to be that GDB is attempting to fetch
the MIPS registers, but there is not yet any live process
on the target to fetch the registers from.  Here is the packet
exchange:

 (gdb) target extended-remote 47.224.40.105:1234

Sending packet: $qSupported#37...Ack
Packet received:
PacketSize=7cf;QPassSignals+;qXfer:libraries:read+;qXfer:auxv:read+;qXfer:featu
res:read+
Sending packet: $qXfer:features:read:target.xml:0,7ca#46...Ack
Packet received: E01
Sending packet: $g#67...Ack
Packet received: E01

The first E01 error occurs in an exclusively x86 environment
too, but the the x86 debugger does not go on to send the
'g' (fetch registers) packet.  It doesn't make sense to
fetch registers here, since there is no live inferior.
>How-To-Repeat:
On a mips target do:
  $ gdbserver --multi :1234

On a host with a debugger targetted for MIPS, do
  (gdb) target extended-remote <ip>:1234
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: