Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Laszlo Benedek <laszlo.benedek@gmail.com>
To: gdb@sourceware.org
Subject: single-step SIGALRM issue
Date: Mon, 19 Jan 2009 17:53:00 -0000	[thread overview]
Message-ID: <d53687720901190950s408e3757n4ffd51ee34527def@mail.gmail.com> (raw)

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


             reply	other threads:[~2009-01-19 17:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-19 17:53 Laszlo Benedek [this message]
2009-01-20  2:22 ` Daniel Jacobowitz
2009-01-20  7:46   ` Laszlo Benedek
2009-01-21  6:17 ` teawater
     [not found]   ` <d53687720901202316w61622f5p1fd9b5f3d17c1a66@mail.gmail.com>
     [not found]     ` <daef60380901202331v224042fatad3ec9119a8e1f86@mail.gmail.com>
     [not found]       ` <d53687720901210022r17d76f77h80ff42f3424af597@mail.gmail.com>
2009-01-21 16:05         ` teawater

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d53687720901190950s408e3757n4ffd51ee34527def@mail.gmail.com \
    --to=laszlo.benedek@gmail.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox