This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
setting $ebp fails?
- From: Avi Kivity <avi at exanet dot com>
- To: gdb at sources dot redhat dot com
- Date: Thu, 15 Apr 2004 12:20:47 +0300
- Subject: setting $ebp fails?
I have a user-level threads package on x86, which does the usual
setjmp() tricks to switch stacks. Unfortunately, the application which
sits atop this package experiences the occasional bug, so I wrote a few
user-defined gdb commands to help with debugging:
define tio_switchto
echo before switchto
set $new_esp = (('TioSingle::Thread'*)(($arg0)._impl)).state.esp
echo after esp
set $new_ebp = (('TioSingle::Thread'*)(($arg0)._impl)).state.ebp
echo after ebp
set $new_eip = (('TioSingle::Thread'*)(($arg0)._impl)).state.eip
echo after eip
set $eip = $new_eip
echo after new_eip
set $esp = $new_esp
echo after new_esp
set $ebp = $new_ebp
echo after new_ebp
echo after switchto
end
tio_switchto expects a pointer to a user-level thread in $arg0, extracts
the state from the saved context, and sets the processor registers so
that commands like 'backtrace' and examination of stack variables can work.
gdb, however, fails after the 'set $ebp' line. It appears to have
executed ($ebp is equal to $new_ebp), but execution of the script stops:
before switchto
after esp
after ebp
after eip
after new_eip
after new_esp
Cannot access memory at address 0xb73a0000
'backtrace' after this failure gives the expected results, and mentions
the faulting address, but I don't see why 'echo' should trigger that:
(gdb) bt
#0 0x08405b29 in setjmp (buf=@0x86f3360) at shmsync/setjmp.cpp:8
#1 0x083fe3de in TioSingle::Thread::suspend (this=0x8702338) at
shmsync/single.cpp:165
#2 0x083c565c in TioThread::suspend (this=0x8702230) at tio.hpp:18
[...]
#14 0x083fde9c in TioSingle::Thread::setup_stack (thread=0x8702338,
creator=0xb73df4f4)
at shmsync/single.cpp:98
#15 0xb7459854 in makecontext () from /lib/i686/libc.so.6
#16 0x08702338 in ?? ()
#17 0xb73df4f4 in ?? ()
#18 0x00000000 in ?? ()
Cannot access memory at address 0xb73a0000
Linux 2.4 on i386, C++, gdb-20040413.
Any help would be appreciated.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.