single-step SIGALRM issue

single-step SIGALRM issue

[Laszlo Benedek]

Hi,

I am part of a team developing a simulator and we have problems
debugging the simulator with gdb.
The simulator is an application written for x86-linux and it was
written in c/c++.
It uses the SIGALRM signal to simulate interrupts.

The test that fails:
I start the simulator in gdb and insert a breakpoint at a certain function call.
When the program reaches the breakpoint it correctly stops, then I try
to use single stepping.
At this point something wierd happens, sometimes it works fine and I
can use the step command
but sometimes the program starts to run and then hangs.

I tried to find the reason of this and here is what I've found. When
gdb starts single stepping
it is expecting a SIGTRAP signal but sometimes it receives a SIGALRM
instead. In this case it
decides to switch the inferior in 'continue' mode, inserts a
breakpoint and waits. In this case our
program continues to run from the original breakpoint and eventually
it reaches a point where it calls sigsuspend
and it waits for signals but it does not receive any signals anymore.
It seems that gdb is blocking them somehow
when this single-step => continue switch happens. I read the comment
in the gdb source and it says that gdb expects
that the program's signal handler will be called and it will stop at
the return of the signal handler because gdb just
inserted a breakpoint there. For some reason the signal handler of our
program is not called at all after it gets into this 'continue' mode.

I'd like to fix this or at least decide if this is an error in gdb or
in the simulator (or both?), but I don't really know how to continue.
Has anyone experienced anything like this before ?
Any comment, idea would be appreciated.

Thanks for your help in advance!

Best regards,
Laszlo Benedek

Re: single-step SIGALRM issue

[Daniel Jacobowitz]

On Mon, Jan 19, 2009 at 06:50:00PM +0100, Laszlo Benedek wrote:
> I tried to find the reason of this and here is what I've found. When
> gdb starts single stepping
[...]

What version of GDB are you using?  And could you try a current
snapshot?  Also, what is your host operating system - I'm guessing
Linux from the description, but what version?  Sigsuspend is known
to have some bad interactions with GDB.

-- 
Daniel Jacobowitz
CodeSourcery

Re: single-step SIGALRM issue

[Laszlo Benedek]

On Tue, Jan 20, 2009 at 3:22 AM, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Jan 19, 2009 at 06:50:00PM +0100, Laszlo Benedek wrote:
>> I tried to find the reason of this and here is what I've found. When
>> gdb starts single stepping
> [...]
>
> What version of GDB are you using?  And could you try a current
> snapshot?  Also, what is your host operating system - I'm guessing
> Linux from the description, but what version?  Sigsuspend is known
> to have some bad interactions with GDB.
>

I thought a new version of gdb would work better so I downloaded the
source of gdb 6.8 a few days ago.
As far as I know that is the most recent version. Unfortunately it did
not make the situation any better.
I have a SLED10 SP1 linux. Kernel version: 2.6.16.53-0.16-bigsmp #1
SMP Tue Oct 2 16:57:49 UTC 2007 i686 i686 i386 GNU/Linux

Laszlo Benedek

Re: single-step SIGALRM issue

[teawater]

"it is expecting a SIGTRAP signal but sometimes it receives a SIGALRM
instead."

Why you can't aways return SIGTRAP?

On Tue, Jan 20, 2009 at 01:50, Laszlo Benedek <laszlo.benedek@gmail.com> wrote:
> Hi,
>
> I am part of a team developing a simulator and we have problems
> debugging the simulator with gdb.
> The simulator is an application written for x86-linux and it was
> written in c/c++.
> It uses the SIGALRM signal to simulate interrupts.
>
> The test that fails:
> I start the simulator in gdb and insert a breakpoint at a certain function call.
> When the program reaches the breakpoint it correctly stops, then I try
> to use single stepping.
> At this point something wierd happens, sometimes it works fine and I
> can use the step command
> but sometimes the program starts to run and then hangs.
>
> I tried to find the reason of this and here is what I've found. When
> gdb starts single stepping
> it is expecting a SIGTRAP signal but sometimes it receives a SIGALRM
> instead. In this case it
> decides to switch the inferior in 'continue' mode, inserts a
> breakpoint and waits. In this case our
> program continues to run from the original breakpoint and eventually
> it reaches a point where it calls sigsuspend
> and it waits for signals but it does not receive any signals anymore.
> It seems that gdb is blocking them somehow
> when this single-step => continue switch happens. I read the comment
> in the gdb source and it says that gdb expects
> that the program's signal handler will be called and it will stop at
> the return of the signal handler because gdb just
> inserted a breakpoint there. For some reason the signal handler of our
> program is not called at all after it gets into this 'continue' mode.
>
> I'd like to fix this or at least decide if this is an error in gdb or
> in the simulator (or both?), but I don't really know how to continue.
> Has anyone experienced anything like this before ?
> Any comment, idea would be appreciated.
>
> Thanks for your help in advance!
>
> Best regards,
> Laszlo Benedek
>

Re: single-step SIGALRM issue

[teawater]

This is because GDB think SIGALRM is a random signal.
Maybe command "handle SIGALRM stop print nopass" can deal with it.

On Wed, Jan 21, 2009 at 16:22, Laszlo Benedek <laszlo.benedek@gmail.com> wrote:
> No, we don't use RSP, we simply start our program with gdb. Did you
> mean that by linking together?
> I know why the SIGALRM signals come, my original question was why gdb
> fails to single step our program when the SIGALRM signals come instead
> of the SIGTRAP.
>
> Best regards,
> Laszlo Benedek
>
> On Wed, Jan 21, 2009 at 8:31 AM, teawater <teawater@gmail.com> wrote:
>> How do your simulator work with GDB? Link together or connect with RSP?
>>
>> I think maybe "It uses the SIGALRM signal to simulate interrupts."
>> this is the reason you got SIGALRM.
>>
>> On Wed, Jan 21, 2009 at 15:16, Laszlo Benedek <laszlo.benedek@gmail.com> wrote:
>>> I am afraid I don't understand your question. What do you mean by
>>> returning a SIGTRAP?
>>> GDB receives the signals from the OS, not my program sends them.
>>>
>>> On Wed, Jan 21, 2009 at 7:17 AM, teawater <teawater@gmail.com> wrote:
>>>> "it is expecting a SIGTRAP signal but sometimes it receives a SIGALRM
>>>> instead."
>>>>
>>>> Why you can't aways return SIGTRAP?
>>>>
>>>> On Tue, Jan 20, 2009 at 01:50, Laszlo Benedek <laszlo.benedek@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I am part of a team developing a simulator and we have problems
>>>>> debugging the simulator with gdb.
>>>>> The simulator is an application written for x86-linux and it was
>>>>> written in c/c++.
>>>>> It uses the SIGALRM signal to simulate interrupts.
>>>>>
>>>>> The test that fails:
>>>>> I start the simulator in gdb and insert a breakpoint at a certain function call.
>>>>> When the program reaches the breakpoint it correctly stops, then I try
>>>>> to use single stepping.
>>>>> At this point something wierd happens, sometimes it works fine and I
>>>>> can use the step command
>>>>> but sometimes the program starts to run and then hangs.
>>>>>
>>>>> I tried to find the reason of this and here is what I've found. When
>>>>> gdb starts single stepping
>>>>> it is expecting a SIGTRAP signal but sometimes it receives a SIGALRM
>>>>> instead. In this case it
>>>>> decides to switch the inferior in 'continue' mode, inserts a
>>>>> breakpoint and waits. In this case our
>>>>> program continues to run from the original breakpoint and eventually
>>>>> it reaches a point where it calls sigsuspend
>>>>> and it waits for signals but it does not receive any signals anymore.
>>>>> It seems that gdb is blocking them somehow
>>>>> when this single-step => continue switch happens. I read the comment
>>>>> in the gdb source and it says that gdb expects
>>>>> that the program's signal handler will be called and it will stop at
>>>>> the return of the signal handler because gdb just
>>>>> inserted a breakpoint there. For some reason the signal handler of our
>>>>> program is not called at all after it gets into this 'continue' mode.
>>>>>
>>>>> I'd like to fix this or at least decide if this is an error in gdb or
>>>>> in the simulator (or both?), but I don't really know how to continue.
>>>>> Has anyone experienced anything like this before ?
>>>>> Any comment, idea would be appreciated.
>>>>>
>>>>> Thanks for your help in advance!
>>>>>
>>>>> Best regards,
>>>>> Laszlo Benedek
>>>>>
>>>>
>>>
>>
>