This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

KGDB EHCI Debug Port, and follow up on --enable-64-bit-bfd and possible connection with what appears to be a truncated thread pointer.


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
	
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 ()
===================================================================================================================

I looked thru the patches around 2.6.38 and didn't find anything missing
Related to the EHCI changes.

Any suggestions/thoughts?

-piet



--
Pete/Piet Delaney                                               
O: +1 408 935-1813
C: +1 408 646-8557
H: +1 408 243-8872
Home Email: piet.delaney@gmail.com




-----Original Message-----
From: crash-utility-bounces@redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of Pete Delaney
Sent: Monday, October 20, 2014 9:28 PM
To: Jan Kratochvil; Andreas Arnez
Cc: GDB Development; Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] gdb on KDUMP files

I'm glad to see this discussion today....

> Nowadays it is only enough to use during configure:
>	--enable-64-bit-bfd

I'll give it a try. I provided O_LARGEFILE  to the gdb configure but I didn't know about this option. With everything going 64-bit these days, why isn't it the default. I'm running gdb on a 64 bit machine and having trouble reading 64 bit core files. Seems like this should work correctly without any additional configure options. 

About 8 years ago I could read a 32 bit KDUMP with gdb and, as I recall, each CPU looked like a thread; just like kgdb displayed CPU's as threads. I also think embedded JTAG setups should do the same.

Are you implying that with:

	--enable-64-bit-bfd

I should be able to do that now on a 64-bit machine looking At 64 bit core dumps and see the back trace for the current CPU's at the time of the KDUMP?

I found the Documentation/kdump/gdbmacros.txt out of date
And had to fix them to work.   :(

-piet




On Fri, 17 Oct 2014 13:24:01 +0200, Andreas Arnez wrote:
> >   4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)

This was:
	https://bugzilla.redhat.com/show_bug.cgi?id=457187
Nowadays it is only enough to use during configure:
	--enable-64-bit-bfd


Additionally Fedora is carrying for Linux kernel support:
	http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.5-bz203661-emit-relocs.patch
dsicussed in the thread:
	https://sourceware.org/ml/gdb/2006-08/msg00137.html


Jan

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Attachment: EHCI_KGDB_Problem
Description: EHCI_KGDB_Problem


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]