how to continue from a breakpoint in GNU/Hurd

how to continue from a breakpoint in GNU/Hurd

[Yue Lu]

Hi.

I am writing a debugger demo under GNU/Hurd when I study the gdb
source code. And I have met a big problem that when I set a breakpoint
in the inferior, my code can't resume inferior from it.

I can get the exception message from the mach kernel when the inferior
hit the breakpoint. As soon as I got the exception message, I removed
the int3, and set the EIP to the previous values, then post a signal
zero to the inferior by msg_sig_post_untraced_request(). at last I
called thread_resume() to resume it. But thing goes wrong, the
inferior is always stops at the breakpoint. and seems never to
continue.

I don't know how to fix this, could any of you give me a suggestion?
thanks very much.

--
Yue Lu (陆岳)

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

[Hui Zhu]

On Wed, Jul 17, 2013 at 12:45 AM, Yue Lu <hacklu.newborn@gmail.com> wrote:
> Hi.
>
> I am writing a debugger demo under GNU/Hurd when I study the gdb
> source code. And I have met a big problem that when I set a breakpoint
> in the inferior, my code can't resume inferior from it.
>
> I can get the exception message from the mach kernel when the inferior
> hit the breakpoint. As soon as I got the exception message, I removed
> the int3, and set the EIP to the previous values,

I am not sure but I think you need care about this part is:
In x86, after the inferior is broken by int3, it will point to the
address after int3. So the right address to continue inferior is
eip-1.

Thanks,
Hui

then post a signal
> zero to the inferior by msg_sig_post_untraced_request(). at last I
> called thread_resume() to resume it. But thing goes wrong, the
> inferior is always stops at the breakpoint. and seems never to
> continue.
>
> I don't know how to fix this, could any of you give me a suggestion?
> thanks very much.
>
> --
> Yue Lu (陆岳)

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

[Luis Machado]

Hi,

On 07/16/2013 01:28 PM, Yue Lu wrote:
> Hi.
>
> I am writing a debugger demo under GNU/Hurd when I study the gdb source
> code. And I have met a big problem that when I set a breakpoint in the
> inferior, my code can't resume inferior from it.
>
> I can get the exception message from the mach kernel when the inferior
> hit the breakpoint. As soon as I got the exception message, I removed
> the int3, and set the EIP to the previous values, then post a signal
> zero to the inferior by msg_sig_post_untraced_request(). at last I
> called thread_resume() to resume it. But thing goes wrong, the inferior
> is always stops at the breakpoint. and seems never to continue.

Some general thoughts...

Can you make sure the breakpoint has been lifted from the instruction it 
replaced? If the breakpoint has been lifted and it is still being hit, 
then it sounds like there is some kind of instruction cache problem 
going on, where we first need to flush the icache before resuming execution.

If the icache is the problem, then it sounds like something the kernel 
itself needs to address.

Luis

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

[Yue Lu]

Hi,

thanks for you reply.

On Wed, Jul 17, 2013 at 12:44 AM, Luis Machado
<lgustavo@codesourcery.com> wrote:
> Hi,
>
>
> On 07/16/2013 01:28 PM, Yue Lu wrote:
>>
>> Hi.
>>
>> I am writing a debugger demo under GNU/Hurd when I study the gdb source
>> code. And I have met a big problem that when I set a breakpoint in the
>> inferior, my code can't resume inferior from it.
>>
>> I can get the exception message from the mach kernel when the inferior
>> hit the breakpoint. As soon as I got the exception message, I removed
>> the int3, and set the EIP to the previous values, then post a signal
>> zero to the inferior by msg_sig_post_untraced_request(). at last I
>> called thread_resume() to resume it. But thing goes wrong, the inferior
>> is always stops at the breakpoint. and seems never to continue.
>
>
> Some general thoughts...
>
> Can you make sure the breakpoint has been lifted from the instruction it
> replaced? If the breakpoint has been lifted and it is still being hit, then
> it sounds like there is some kind of instruction cache problem going on,
> where we first need to flush the icache before resuming execution.
>
> If the icache is the problem, then it sounds like something the kernel
> itself needs to address.
>
> Luis

I don't know how to flush the icache off-hand, so I used anther way to
bypass this issue. I set the eip to the next instruction's address to
bypass the breakpoint ins. But problem seems doesn't go away.


--
Yue Lu (陆岳)

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

[Luis Machado]

Hi,

On 07/16/2013 02:04 PM, Yue Lu wrote:
> Hi,
>
> thanks for you reply.
>
> On Wed, Jul 17, 2013 at 12:44 AM, Luis Machado
>> Some general thoughts...
>>
>> Can you make sure the breakpoint has been lifted from the instruction it
>> replaced? If the breakpoint has been lifted and it is still being hit, then
>> it sounds like there is some kind of instruction cache problem going on,
>> where we first need to flush the icache before resuming execution.
>>
>> If the icache is the problem, then it sounds like something the kernel
>> itself needs to address.
>>
>> Luis
>
> I don't know how to flush the icache off-hand, so I used anther way to
> bypass this issue. I set the eip to the next instruction's address to
> bypass the breakpoint ins. But problem seems doesn't go away.

I don't think the cache invalidation is something the debugger should 
do. Sounds like something the kernel would do.

When you set the EIP to some other instruction (not the breakpoint one), 
what do you see when you instruction-step? What does the EIP show after 
that?

Luis

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

[Richard Braun]

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.

-- 
Richard Braun

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

[Yue Lu]

Hi.

On Wed, Jul 17, 2013 at 8:09 PM, Richard Braun <rbraun@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 (陆岳)

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

[Richard Braun]

On Thu, Jul 18, 2013 at 12:07:20AM +0800, Yue Lu wrote:
> 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

If the info pointer is NULL, how do you determine the suspend count ?

> something maybe wrong, but the err is zero.

Something does look wrong. Check all the parameters of your call, one
by one, rigorously.

-- 
Richard Braun

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

[Yue Lu]

On Thu, Jul 18, 2013 at 12:13 AM, Richard Braun <rbraun@sceen.net> wrote:
> On Thu, Jul 18, 2013 at 12:07:20AM +0800, Yue Lu wrote:
>> 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
>
> If the info pointer is NULL, how do you determine the suspend count ?
>
I used this (&_info)->suspend_count to get the sc value.

> Something does look wrong. Check all the parameters of your call, one
> by one, rigorously.

The only one parameter I used is the first one, I give it as the
thread port, something like 119 (I have printf it), the left three
parameters are all the same as the code in gnu-nat.c.
,

--
Yue Lu (陆岳)

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

[Richard Braun]

On Thu, Jul 18, 2013 at 12:22:07AM +0800, Yue Lu wrote:
> On Thu, Jul 18, 2013 at 12:13 AM, Richard Braun <rbraun@sceen.net> wrote:
> > On Thu, Jul 18, 2013 at 12:07:20AM +0800, Yue Lu wrote:
> >> 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
> >
> > If the info pointer is NULL, how do you determine the suspend count ?
> >
> I used this (&_info)->suspend_count to get the sc value.
> 
> > Something does look wrong. Check all the parameters of your call, one
> > by one, rigorously.
> 
> The only one parameter I used is the first one, I give it as the
> thread port, something like 119 (I have printf it), the left three
> parameters are all the same as the code in gnu-nat.c.

So, in the end, the code (which is taken from GDB) is wrong. It uses
&info, the address of a pointer to _info, where it should use &_info or
info instead. The kernel happily writes the thread info there, erasing
the pointer on the way.

-- 
Richard Braun