This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: KGDB EHCI Debug Port, and follow up on --enable-64-bit-bfd and possible connection with what appears to be a truncated thread pointer.
- From: Pedro Alves <palves at redhat dot com>
- To: Pete Delaney <pdelaney at silver-peak dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, Andreas Arnez <arnez at linux dot vnet dot ibm dot com>, GDB Development <gdb at sourceware dot org>, "jason dot wessel at windriver dot com" <jason dot wessel at windriver dot com>, "kgdb-bugreport at lists dot sourceforge dot net" <kgdb-bugreport at lists dot sourceforge dot net>
- Cc: "piet dot delaney at gmail dot com" <piet dot delaney at gmail dot com>
- Date: Thu, 30 Oct 2014 11:23:42 +0000
- Subject: Re: KGDB EHCI Debug Port, and follow up on --enable-64-bit-bfd and possible connection with what appears to be a truncated thread pointer.
- Authentication-results: sourceware.org; auth=none
- References: <fe25a782ecbe4cd6ab0a089d6fc80d8e at BY2PR04MB173 dot namprd04 dot prod dot outlook dot com>
Hi,
I really don't know anything about KDB, but ...
On 10/29/2014 06:59 AM, Pete Delaney wrote:
> Andreas I tried --enable-64-bit-bfd but I don't think it helped with the core files.
>
> This evening I tried using Jason Wessel's KDB EHCI Debug port on Linux-2.6.38.
> Earlier when I was using ttyS0 kgdb and gdb seemed to work fine, other
> then when trying to use it early with ekgboe.
>
> With the EHCI Debug port, early debugging appears to be starting
> very early, which is great, but I'm getting serious protocol issues.
> Looks like gdb is try to tell the stub to write to memory location 0xb
>
> Sending packet: $mb,1#2c...Ack
... 'm' is "read memory", not write.
>
> And the stub returns with an error (E22).
>
> The size of the thread pointer returned looks truncated:
>
> Packet received: T0bthread:fffffffe;
>
> Which I suspect is the likely cause of try to write to x0b.
> ====================================================================================================================
> (gdb) c
> Continuing.
> Sending packet: $vCont?#49...Ack
> Packet received:
> Packet vCont (verbose-resume) is NOT supported
> Sending packet: $Hc0#db...Ack
> Packet received: OK
> Sending packet: $C0b#d5...Ack
> Packet received: O4b474442206f6e6c79206b6e6f7773207369676e616c20392028706173732920616e6420313520287061737320616e6420646973636f6e6e656374290a457865637574696e67206120636f6e74696e756520776974686f7574207369676e616c2070617373696e670a
> KGDB only knows signal 9 (pass) and 15 (pass and disconnect)
> Executing a continue without signal passing
> Packet received: T0bthread:fffffffe;
> Sending packet: $g#67...Ack
> Packet received: 450000000000000098ba9381ffffffff9200000000000000000000000000000000000000000000004600000000000000c89d7281ffffffffc89d7281ffffffff200000000000000005000000000000000000000000000000206764622e2e2e0ae58c8f81ffffffff0000000000000000e58c8f81ffffffff00000000000000000b00000000000000020001001000000000000000
> Sending packet: $mb,1#2c...Ack
> Packet received: E22
> Sending packet: $mb,1#2c...Ack
> Packet received: E22
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000000000b in irq_stack_union ()
0x0b is what the PC seemingly points at.
I think GDB is trying to read the prologue of the
function at 0x6, which the debug info claims is irq_stack_union,
in order to unwind the previous frame.
Thanks,
Pedro Alves