This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/1744: sparc solaris Call hangs after attach to waiting process
- From: Mark Kettenis <kettenis at chello dot nl>
- To: kettenis at gnu dot org
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 14 Aug 2004 11:08:01 -0000
- Subject: Re: gdb/1744: sparc solaris Call hangs after attach to waiting process
- Reply-to: Mark Kettenis <kettenis at chello dot nl>
The following reply was made to PR gdb/1744; it has been noted by GNATS.
From: Mark Kettenis <kettenis@chello.nl>
To: gdb-gnats@sources.redhat.com, woodylarue_1@earthlink.net, kettenis@gnu.org,
larue@cadence.com
Cc:
Subject: Re: gdb/1744: sparc solaris Call hangs after attach to waiting process
Date: Sat, 14 Aug 2004 13:04:35 +0200 (CEST)
I can reproduce the problem with GDB 5.3, so this isn't caused by the
sparc-tdep.c; but read on. Also, the program doesn't actually hang
*forever*; it just hangs for whatever remains of the 10000 seconds
specified in the sleep. That points out the problem. On Solaris (and
probably every host that uses SVR4-style procfs debugging), system
calls aren't interrupted when GDB attaches. So when we proceed after
tweaking the registers as a response to the 'call dummy(5)' command,
the sleep is resumed.
Something did change between 5.3 and the current HEAD though. With
5.3, after the sleep finished, dummy() would correctly be called, and
execution stops after we return from it. With HEAD execution doesn't
stop after dummy() returns; we just run until the program exits.
So it seems that we have two issues here. One's a genuine bug; we
should stop after dummy() returns. It's debatable whether the other
issue is a bug though. If we interrupt an interruptable system call
when we attach, the program might not be able to deal with it.
Mark