* KGDB EHCI Debug Port, and follow up on --enable-64-bit-bfd and possible connection with what appears to be a truncated thread pointer.
@ 2014-10-29 6:59 Pete Delaney
2014-10-30 11:24 ` Pedro Alves
0 siblings, 1 reply; 2+ messages in thread
From: Pete Delaney @ 2014-10-29 6:59 UTC (permalink / raw)
To: Jan Kratochvil, Andreas Arnez, GDB Development, jason.wessel,
kgdb-bugreport
Cc: piet.delaney, Pete Delaney
[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]
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 #2: EHCI_KGDB_Problem --]
[-- Type: application/octet-stream, Size: 12113 bytes --]
root@piet-t3600:/home/pdelaney/src/gdb/gdb-7.8# ./gdb/gdb /home/piet/src/linux_2.6.38/vmlinux
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/piet/src/linux_2.6.38/vmlinux...done.
(gdb) bt
No stack.
(gdb) set debug remote 1
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
Sending packet: $qSupported:multiprocess+;xmlRegisters=i386;qRelocInsn+#b5...Ack
Packet received:
Packet qSupported (supported-packets) is NOT supported
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qTStatus#49...Ack
Packet received:
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: S0b
Sending packet: $qfThreadInfo#bb...Ack
Packet received: mfffffffe
Sending packet: $qAttached#8f...Ack
Packet received:
Packet qAttached (query-attached) is NOT supported
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QCfffffffe
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $g#67...Ack
Packet received: 450000000000000098ba9381ffffffff9200000000000000000000000000000000000000000000004600000000000000c89d7281ffffffffc89d7281ffffffff200000000000000005000000000000000000000000000000206764622e2e2e0ae58c8f81ffffffff0000000000000000e58c8f81ffffffff00000000000000003ed10881ffffffff020001001000000000000000
arch_kgdb_breakpoint () at /home/piet/src/linux_2.6.38/arch/x86/include/asm/kgdb.h:76
76 asm(" int $3");
Sending packet: $qSymbol::#5b...Ack
Packet received:
Packet qSymbol (symbol-lookup) is NOT supported
(gdb) where
#0 arch_kgdb_breakpoint () at /home/piet/src/linux_2.6.38/arch/x86/include/asm/kgdb.h:76
#1 kgdb_breakpoint () at kernel/debug/debug_core.c:959
Sending packet: $mffffffff81729dd0,8#04...Ack
Packet received: ac318d81ffffffff
Sending packet: $mffffffff81729dd0,8#04...Ack
Packet received: ac318d81ffffffff
Sending packet: $mffffffff81729dd0,8#04...Ack
Packet received: ac318d81ffffffff
Sending packet: $mffffffff81729dd0,8#04...Ack
Packet received: ac318d81ffffffff
Sending packet: $mffffffff81729dc8,8#0b...Ack
Packet received: d89d7281ffffffff
#2 0xffffffff818d31ac in kgdb_initial_breakpoint () at kernel/debug/debug_core.c:858
Sending packet: $mffffffff81729de0,8#05...Ack
Packet received: 07968b81ffffffff
Sending packet: $mffffffff81729de0,8#05...Ack
Packet received: 07968b81ffffffff
Sending packet: $mffffffff81729dd0,8#04...Ack
Packet received: ac318d81ffffffff
Sending packet: $mffffffff81729de0,8#05...Ack
Packet received: 07968b81ffffffff
Sending packet: $mffffffff81729dd8,8#0c...Ack
Packet received: 089e7281ffffffff
#3 opt_kgdb_wait (str=<optimized out>) at kernel/debug/debug_core.c:971
Sending packet: $mffffffff81729e10,8#d2...Ack
Packet received: 42120681ffffffff
Sending packet: $mffffffff81729e10,8#d2...Ack
Packet received: 42120681ffffffff
Sending packet: $mffffffff81729de0,8#05...Ack
Packet received: 07968b81ffffffff
Sending packet: $mffffffff81729e10,8#d2...Ack
Packet received: 42120681ffffffff
Sending packet: $mffffffff81729e10,8#d2...Ack
Packet received: 42120681ffffffff
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e28,8#db...Ack
Packet received: a6958b81ffffffff
Sending packet: $mffffffff818f8ce5,8#3d...Ack
Packet received: 6b67646277616974
Sending packet: $mffffffff818f8ced,8#6c...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e28,8#db...Ack
Packet received: a6958b81ffffffff
Sending packet: $mffffffff81729e00,8#d1...Ack
Packet received: 0000000000000000
#4 0xffffffff818b9607 in do_early_param (param=param@entry=0xffffffff818f8ce5 <tmp_cmdline+133> "kgdbwait", val=val@entry=0x0 <irq_stack_union>) at init/main.c:494
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e28,8#db...Ack
Packet received: a6958b81ffffffff
Sending packet: $mffffffff81729df0,8#06...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e40,8#d5...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729e00,8#d1...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff818f8ce5,8#3d...Ack
Packet received: 6b67646277616974
Sending packet: $mffffffff818f8ced,8#6c...Ack
Packet received: 0000000000000000
#5 0xffffffff81061242 in parse_one (handle_unknown=0xffffffff818b95a6 <do_early_param>, num_params=0, params=0x0 <irq_stack_union>, val=0x0 <irq_stack_union>, param=0xffffffff818f8ce5 <tmp_cmdline+133> "kgdbwait")
at kernel/params.c:112
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e80,8#d9...Ack
Packet received: 75988b81ffffffff
Sending packet: $mffffffff81729e80,8#d9...Ack
Packet received: 75988b81ffffffff
Sending packet: $mffffffff81729e10,8#d2...Ack
Packet received: 42120681ffffffff
Sending packet: $mffffffff81729e80,8#d9...Ack
Packet received: 75988b81ffffffff
Sending packet: $mffffffff81729e78,8#e0...Ack
Packet received: 889e7281ffffffff
Sending packet: $mffffffff81729e38,8#dc...Ack
Packet received: 917b6781ffffffff
Sending packet: $mffffffff81677b91,8#da...Ack
Packet received: 6561726c79206f70
Sending packet: $mffffffff81677b99,8#e2...Ack
Packet received: 74696f6e73003c35
Sending packet: $mffffffff81729e90,8#da...Ack
Packet received: a8988b81ffffffff
Sending packet: $mffffffff81729e90,8#da...Ack
Packet received: a8988b81ffffffff
Sending packet: $mffffffff81729e80,8#d9...Ack
Packet received: 75988b81ffffffff
Sending packet: $mffffffff81729e90,8#da...Ack
Packet received: a8988b81ffffffff
Sending packet: $mffffffff81729e88,8#e1...Ack
Packet received: 989e7281ffffffff
Sending packet: $mffffffff818f8c60,8#09...Ack
Packet received: 726f00726f6f7400
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e40,8#d5...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729df0,8#06...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729e08,8#d9...Ack
Packet received: 789e7281ffffffff
Sending packet: $mffffffff81729e28,8#db...Ack
Packet received: a6958b81ffffffff
#6 parse_args (name=name@entry=0xffffffff81677b91 "early options", args=<optimized out>, args@entry=0xffffffff818f8c60 <tmp_cmdline> "ro", params=params@entry=0x0 <irq_stack_union>, num=num@entry=0,
unknown=unknown@entry=0xffffffff818b95a6 <do_early_param>) at kernel/params.c:191
Sending packet: $mffffffff818f8c60,8#09...Ack
Packet received: 726f00726f6f7400
#7 0xffffffff818b9875 in parse_early_options (cmdline=cmdline@entry=0xffffffff818f8c60 <tmp_cmdline> "ro") at init/main.c:505
#8 0xffffffff818b98a8 in parse_early_param () at init/main.c:519
Sending packet: $mffffffff81729ea0,8#02...Ack
Packet received: a0f48b81ffffffff
Sending packet: $mffffffff81729ea0,8#02...Ack
Packet received: a0f48b81ffffffff
Sending packet: $mffffffff81729e90,8#da...Ack
Packet received: a8988b81ffffffff
Sending packet: $mffffffff81729ea0,8#02...Ack
Packet received: a0f48b81ffffffff
Sending packet: $mffffffff81729e98,8#e2...Ack
Packet received: 389f7281ffffffff
Sending packet: $mffffffff81729e60,8#d7...Ack
Packet received: 509f7281ffffffff
Sending packet: $mffffffff81729f40,8#d6...Ack
Packet received: 8f998b81ffffffff
Sending packet: $mffffffff81729f40,8#d6...Ack
Packet received: 8f998b81ffffffff
Sending packet: $mffffffff81729ea0,8#02...Ack
Packet received: a0f48b81ffffffff
Sending packet: $mffffffff81729f40,8#d6...Ack
Packet received: 8f998b81ffffffff
Sending packet: $mffffffff81729f38,8#dd...Ack
Packet received: 789f7281ffffffff
Sending packet: $mffffffff81729f38,8#dd...Ack
Packet received: 789f7281ffffffff
#9 0xffffffff818bf4a0 in setup_arch (cmdline_p=cmdline_p@entry=0xffffffff81729f50 <init_thread_union+8016>) at arch/x86/kernel/setup.c:830
#10 0xffffffff818b998f in start_kernel () at init/main.c:594
Sending packet: $mffffffff81729f80,8#da...Ack
Packet received: 47938b81ffffffff
Sending packet: $mffffffff81729f80,8#da...Ack
Packet received: 47938b81ffffffff
Sending packet: $mffffffff81729f40,8#d6...Ack
Packet received: 8f998b81ffffffff
Sending packet: $mffffffff81729f80,8#da...Ack
Packet received: 47938b81ffffffff
Sending packet: $mffffffff81729f78,8#e1...Ack
Packet received: 989f7281ffffffff
Sending packet: $mffffffff81729fa0,8#03...Ack
Packet received: 52948b81ffffffff
Sending packet: $mffffffff81729fa0,8#03...Ack
Packet received: 52948b81ffffffff
Sending packet: $mffffffff81729f80,8#da...Ack
Packet received: 47938b81ffffffff
Sending packet: $mffffffff81729fa0,8#03...Ack
Packet received: 52948b81ffffffff
Sending packet: $mffffffff81729f98,8#e3...Ack
Packet received: e89f7281ffffffff
Sending packet: $mffffffff81729f30,8#d5...Ack
Packet received: 803e090000000000
Sending packet: $mffffffff81729f30,8#d5...Ack
Packet received: 803e090000000000
Sending packet: $m93e80,8#0a...Ack
Packet received: E22
Sending packet: $m93e80,1#03...Ack
Packet received: E22
#11 0xffffffff818b9347 in x86_64_start_reservations (real_mode_data=real_mode_data@entry=0x93e80 <error: Cannot access memory at address 0x93e80>) at arch/x86/kernel/head64.c:127
Sending packet: $mffffffff81729f30,8#d5...Ack
Packet received: 803e090000000000
Sending packet: $mffffffff81729ff0,8#08...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729ff0,8#08...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729fa0,8#03...Ack
Packet received: 52948b81ffffffff
Sending packet: $mffffffff81729ff0,8#08...Ack
Packet received: 0000000000000000
Sending packet: $m93e80,8#0a...Ack
Packet received: E22
Sending packet: $m93e80,1#03...Ack
Packet received: E22
#12 0xffffffff818b9452 in x86_64_start_kernel (real_mode_data=0x93e80 <error: Cannot access memory at address 0x93e80>) at arch/x86/kernel/head64.c:97
#13 0x0000000000000000 in ?? ()
Sending packet: $mffffffff81729ff8,8#10...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729ff0,8#08...Ack
Packet received: 0000000000000000
Sending packet: $mffffffff81729ff8,8#10...Ack
Packet received: 0000000000000000
(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 ()
(gdb)
^ permalink raw reply [flat|nested] 2+ messages in thread
* 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.
2014-10-29 6:59 KGDB EHCI Debug Port, and follow up on --enable-64-bit-bfd and possible connection with what appears to be a truncated thread pointer Pete Delaney
@ 2014-10-30 11:24 ` Pedro Alves
0 siblings, 0 replies; 2+ messages in thread
From: Pedro Alves @ 2014-10-30 11:24 UTC (permalink / raw)
To: Pete Delaney, Jan Kratochvil, Andreas Arnez, GDB Development,
jason.wessel, kgdb-bugreport
Cc: piet.delaney
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-10-30 11:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-29 6:59 KGDB EHCI Debug Port, and follow up on --enable-64-bit-bfd and possible connection with what appears to be a truncated thread pointer Pete Delaney
2014-10-30 11:24 ` Pedro Alves
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).