setting $ebp fails?

Avi Kivity avi@exanet.com
Thu Apr 15 17:45:00 GMT 2004


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.




More information about the Gdb mailing list