public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* Re: remote/2474: target extended-remote with --multi does not work on MIPS
@ 2008-07-14 17:08 Daniel Jacobowitz
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2008-07-14 17:08 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: remote/2474: target extended-remote with --multi does not work on MIPS
@ 2008-11-24 18:05 drow
0 siblings, 0 replies; 5+ messages in thread
From: drow @ 2008-11-24 18:05 UTC (permalink / raw)
To: dgraham, drow, gdb-prs, nobody
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: remote/2474: target extended-remote with --multi does not work on MIPS
@ 2008-07-14 17:38 Daniel Jacobowitz
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2008-07-14 17:38 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: remote/2474: target extended-remote with --multi does not work on MIPS
@ 2008-07-14 17:28 Doug Graham
0 siblings, 0 replies; 5+ messages in thread
From: Doug Graham @ 2008-07-14 17:28 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
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--
^ permalink raw reply [flat|nested] 5+ messages in thread
* remote/2474: target extended-remote with --multi does not work on MIPS
@ 2008-07-09 1:28 dgraham
0 siblings, 0 replies; 5+ messages in thread
From: dgraham @ 2008-07-09 1:28 UTC (permalink / raw)
To: gdb-gnats
>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:
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-11-24 18:05 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-14 17:08 remote/2474: target extended-remote with --multi does not work on MIPS Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2008-11-24 18:05 drow
2008-07-14 17:38 Daniel Jacobowitz
2008-07-14 17:28 Doug Graham
2008-07-09 1:28 dgraham
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).