Hi. On Wed, Jul 17, 2013 at 8:09 PM, Richard Braun <rbr...@sceen.net> wrote: > On Wed, Jul 17, 2013 at 02:11:58PM +0800, Yue Lu wrote: >> When I get the exception message, I set the EIP to the next instruction >> (for instance 0x12345678), after resume it, I call get_thread_state(), and >> found the EIP is still 0x12345678. The inferior never running anymore. > > I don't think it has anything to do with the instruction cache. Use the > thread_info() call to determine what the suspend count is, it may have > been incremented implicitely.
when I used thread_info() to check the suspend count, they are zero. But I met a strange thing. this is my code snippet: thread_basic_info_data_t _info; thread_basic_info_t info = &_info; mach_msg_type_number_t info_len = THREAD_BASIC_INFO_COUNT; error_t err = thread_info (thread->port, THREAD_BASIC_INFO, (int *) &info, &info_len); after this call, the info turn out to be a _NULL_ pointer. I think something maybe wrong, but the err is zero. In thread_takeover_sc_cmd() [gdb/gdb/gnu-nat.c] it has directly access info after thread_info call, so I think this pointer never become a NULL pointer, but in my code, it does. So I think something maybe wrong, or this is a bug in gdb code. -- Yue Lu (陆岳)
