* [patch] Suggest fixing your target for gdbserver(1)
@ 2006-09-26 15:27 Jan Kratochvil
2006-09-26 15:33 ` Daniel Jacobowitz
0 siblings, 1 reply; 3+ messages in thread
From: Jan Kratochvil @ 2006-09-26 15:27 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
Hi,
x86_64 defaults (by bfd matching) to target "i386" instead of its native
"i386:x86_64". Therefore if you connect to gdbserver(1) without any `file' or
`set architecture' command before the communication will crash on a different
expected register sizes.
As implementing architecture negotiation is complicated due to gdbserver(1) not
being aware of bfd-compatible name of its target and also it may be also
unclear to automatically change the target while working remotely it is just
suggesting to double-check which architecture you are using.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Remote debugging from host 127.0.0.1
Remote register badly formatted: T0506:0000000000000000;07:40daffbf7f000000;10:506b55952a000000;
readchar: Got EOF
here: 0000000;07:40daffbf7f000000;10:506b55952a000000;
Try to load the executable by `file' first,
you may also check `set/show architecture'.
(gdb) Remote side has terminated connection. GDBserver will reopen the connection.
Listening on port 1234
Regards,
Jan
[-- Attachment #2: gdb-6.5-gdbserver-arch-advice.patch --]
[-- Type: text/plain, Size: 1566 bytes --]
2006-09-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* remote.c (remote_wait): Suggestion on crash due to nonmatching target.
(remote_async_wait): Likewise.
Index: gdb/remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.230
diff -u -p -r1.230 remote.c
--- gdb/remote.c 22 Sep 2006 13:50:36 -0000 1.230
+++ gdb/remote.c 26 Sep 2006 15:15:32 -0000
@@ -3103,8 +3103,13 @@ Packet: '%s'\n"),
reg->regnum, regs);
}
+ /* It may also occur on amd64 which defaults to 32-bit i386
+ target. gdbserver(1) is not aware of the `set architecture'
+ name itself as it is not using libbfd. */
if (*p++ != ';')
- error (_("Remote register badly formatted: %s\nhere: %s"),
+ error (_("Remote register badly formatted: %s\nhere: %s"
+ "\nTry to load the executable by `file' first,"
+ "\nyou may also check `set/show architecture'."),
buf, p);
}
}
@@ -3299,8 +3304,13 @@ Packet: '%s'\n"),
regcache_raw_supply (current_regcache, reg->regnum, regs);
}
+ /* It may also occur on amd64 which defaults to 32-bit i386
+ target. gdbserver(1) is not aware of the `set architecture'
+ name itself as it is not using libbfd. */
if (*p++ != ';')
- error (_("Remote register badly formatted: %s\nhere: %s"),
+ error (_("Remote register badly formatted: %s\nhere: %s"
+ "\nTry to load the executable by `file' first,"
+ "\nyou may also check `set/show architecture'."),
buf, p);
}
}
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch] Suggest fixing your target for gdbserver(1)
2006-09-26 15:27 [patch] Suggest fixing your target for gdbserver(1) Jan Kratochvil
@ 2006-09-26 15:33 ` Daniel Jacobowitz
2006-10-02 15:55 ` Daniel Jacobowitz
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Jacobowitz @ 2006-09-26 15:33 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches
On Tue, Sep 26, 2006 at 05:27:15PM +0200, Jan Kratochvil wrote:
> Hi,
>
> x86_64 defaults (by bfd matching) to target "i386" instead of its native
> "i386:x86_64". Therefore if you connect to gdbserver(1) without any `file' or
> `set architecture' command before the communication will crash on a different
> expected register sizes.
>
> As implementing architecture negotiation is complicated due to gdbserver(1) not
> being aware of bfd-compatible name of its target and also it may be also
> unclear to automatically change the target while working remotely it is just
> suggesting to double-check which architecture you are using.
As a matter of fact I'm implementing automatic detection of 32-bit vs
64-bit targets based on the size of register responses right now.
I hope to have it done later in the week, though it will be tricky
to break it apart from the rest of my patches for merging.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch] Suggest fixing your target for gdbserver(1)
2006-09-26 15:33 ` Daniel Jacobowitz
@ 2006-10-02 15:55 ` Daniel Jacobowitz
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Jacobowitz @ 2006-10-02 15:55 UTC (permalink / raw)
To: gdb-patches; +Cc: Jan Kratochvil
On Tue, Sep 26, 2006 at 11:33:31AM -0400, Daniel Jacobowitz wrote:
> On Tue, Sep 26, 2006 at 05:27:15PM +0200, Jan Kratochvil wrote:
> > Hi,
> >
> > x86_64 defaults (by bfd matching) to target "i386" instead of its native
> > "i386:x86_64". Therefore if you connect to gdbserver(1) without any `file' or
> > `set architecture' command before the communication will crash on a different
> > expected register sizes.
> >
> > As implementing architecture negotiation is complicated due to gdbserver(1) not
> > being aware of bfd-compatible name of its target and also it may be also
> > unclear to automatically change the target while working remotely it is just
> > suggesting to double-check which architecture you are using.
>
> As a matter of fact I'm implementing automatic detection of 32-bit vs
> 64-bit targets based on the size of register responses right now.
> I hope to have it done later in the week, though it will be tricky
> to break it apart from the rest of my patches for merging.
Just to keep you updated: I got this working on Saturday. I'm still
trying to figure out how to merge it without dragging in all the rest
of this source tree. I'll post some more about that later today.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-10-02 15:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-26 15:27 [patch] Suggest fixing your target for gdbserver(1) Jan Kratochvil
2006-09-26 15:33 ` Daniel Jacobowitz
2006-10-02 15:55 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox