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

["Doug Graham" <dgraham at nortel dot com>]

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--