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.

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