This is the mail archive of the gdb-patches@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]

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


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