This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [SH][PATCH] Disable ABI frame sniffer
I'm currently in the process of trying to patch GDB HEAD sufficiently to
run OS21 threaded programs on ST targets like I do with our 6.3 based
tools. When I've got that done I'll have a better idea whether anything
needs to be done any more. I suspect we will still _like_ to.
The following shows the difference between the unwinder enabled and
disabled:
(gdb) thread apply all bt
Thread 7 (Thread 7):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
#2 0xdeaddead in ?? ()
Previous frame identical to this frame (corrupt stack?)
Thread 6 (Thread 6):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
#2 0xdeaddead in ?? ()
Previous frame identical to this frame (corrupt stack?)
Thread 5 (Thread 5):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
#2 0xdeaddead in ?? ()
Previous frame identical to this frame (corrupt stack?)
Thread 4 (Thread 4):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
#2 0xdeaddead in ?? ()
Previous frame identical to this frame (corrupt stack?)
Thread 3 (Thread 3):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
#2 0xdeaddead in ?? ()
Previous frame identical to this frame (corrupt stack?)
Thread 2 (Thread 2):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
#2 0xdeaddead in ?? ()
Previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 1):
#0 main () at /home/afra/users/stubbsa/os21test.c:30
(gdb) set backtrace abi-sniffer off
(gdb) thread apply all bt
Thread 7 (Thread 7):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
Thread 6 (Thread 6):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
Thread 5 (Thread 5):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
Thread 4 (Thread 4):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
Thread 3 (Thread 3):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
Thread 2 (Thread 2):
#0 _md_kernel_task_launch (entry_point=0x9, datap=0x8)
at src/st40/kernel/kernel.c:164
#1 0xdeaddead in ?? ()
Thread 1 (Thread 1):
#0 main () at /home/afra/users/stubbsa/os21test.c:30
The situation clearly has improved since 6.3, but I'm still not happy
about giving a debugger with this behaviour to our customers.
Unfortunately I have been unable to test how eclipse reacts to the error
message due to a mysterious seg fault in ui_file_put() when using -i=mi1
(but not mi2) after the first 'Loading section' message. Apparently
'0x19' isn't a useful value for 'file'. Something to look forward to
tomorrow.
BFN
Andrew