[RFA] Re: x86 linux GDB and SIGALRM

Mark Kettenis kettenis@wins.uva.nl
Wed May 3 16:18:00 GMT 2000


   Date: Wed, 03 May 2000 13:48:20 -0700
   From: Michael Snyder <msnyder@cygnus.com>

   Mark Kettenis wrote:
   > 
   >    Date: Tue, 02 May 2000 10:48:57 +1000
   >    From: Andrew Cagney <ac131313@cygnus.com>
   > 
   >    I think your analysis of the history is correct.  I'd just like to
   >    (infrun.c is the most frail code of code in GDB) see a testsuite
   >    addition (is there one already?) and a yay from someone with threads on
   >    a non-linux target.  I just have a feeling that creating a test case
   >    isn't easy :-( Hmm, does steping through a SIGBUS trigger the behavour?
   > 
   > I'll test it on Solaris 2.6.  I already promised Stan a testcase.
   > Would you prefer a SIGBUS/SIGSEGV testcase, or rather a SIGALRM
   > testcase?  I actually think the SIGALRM one is easier, but of course
   > there are targets without SIGALRM.  Do you know any targets that do
   > #define SIGALRM, but don't actually support it?

   Mark, 

   Going by JimB's comments, it seems like an essential test 
   would be stepping over a pthread_create call.  And the 
   concern is probably that it would fail on Linux (more so
   than on Solaris).  This is because GDB will be doing a
   wait() system call that may be interrupted by the signals
   (esp. SIGCHLD) generated by the libthreads library.

   I would like to see this tested with both lin-thread and
   the older linux-thread module (which I suspect is the one
   that Jim was compensating for when he made the change in
   infrun).

There is a test that does this in gdb.threads/linux-dp.exp.  I ran the
testsuite (both with libthread_db and without) and got only passes.
So my patch doesn't seems to break it again.  Actually, I don't think
that my patch reverses Jim's fix at all, read on!

I think there is some confusion about who did what to the code in
question.  JimB last touched this code end of July:

1999-07-28  Jim Blandy  <jimb@cygnus.com>

        * infrun.c (handle_inferior_event): Don't try to use the code for
        stepping over a function call to also handle stepping out of a
        sigtramp on HP-UX.  That ends up trashing step-resume breakpoints.
        This change reverts some of David Taylor's change of 31 Dec 1998.
        The HP-UX maintainer needs to submit a new change for whatever
        problem the original change was trying to fix.

This is probably the fix that was needed for the threads on Linux (I
think that what whas happening is that the HP-UX change caused the
SIGCHLD from the creation of a new thread during stepping to add a
second step-resume breakpoint).  JimB changed the code back such that
it always did a `goto check_sigtramp2' (which would land at keep_going
and then return).  Then Stan came and changed all goto's into function
calls.  He did put a call to check_sigtramp2() here, but put a
keep_going() and a return in.  That causes us to land in the
breakpoint handling code even if we didn't get a trap.  He probably
didn't notice it because I think leaving those out will only cause
"problems" if we're stepping a single instruction.

Does this remove your worries?  If so, please tell so I can put this in.

Mark


More information about the Gdb-patches mailing list