Re: how to continue from a breakpoint in GNU/Hurd

Yue Lu <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.os.hurd.bugs
Message-ID <CAB8fV=hvso0fYxZwm11DTYaZeGrdaMG9nzE04G1G-TbR6wyDOw@mail.gmail.com>
Hi.

On Wed, Jul 17, 2013 at 8:09 PM, Richard Braun <[email protected]> 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 (陆岳)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.