Re: [SH][PATCH] Disable ABI frame sniffer

[Andrew STUBBS <andrew.stubbs@st.com>]

> 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