This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] gdb.threads/attach-into-signal.exp: don't rely on linux native target's internal debug output


On 02/20/2012 08:57 AM, Jan Kratochvil wrote:
> On Fri, 17 Feb 2012 20:37:50 +0100, Pedro Alves wrote:
>> > We can't use this method for the non-threaded case too, because the Linux
>> > native target when attaching finds another signal other than SIGSTOP, puts
>> > that other signal pending, and waits for the SIGSTOP, so siginfo.si_signo
>> > will always show SIGSTOP.
> It works with this patch from Fedora but it is not yet upstreamed:
> 	ping: [patch 3/4]#3 linux-nat: Do not respawn signals
> 	http://sourceware.org/ml/gdb-patches/2011-05/msg00407.html

Yeah.  We can revisit/simplify the test once that's in.

>> > Jan, is this okay with you?
> Yes.

Great.

> 
> 
>> > +		    set test2 "pull thread list"
>> > +		    gdb_test_multiple "info threads" $test2 {
>> > +			-re "\r\n$gdb_prompt $" {
>> > +			}
>> > +		    }
> This can be just:
> 		    gdb_test "info threads" ".*" "pull thread list"

I avoided that on purpose, because that'd generate a PASS for every
attempt/iteration at trying to catch the signal.

> Still this is a bug of extended gdbserver mode.

Yeah, it could be considered a bug.  Not only of extended gdbserver
tough.  It happens with all remote targets, and we have similar things
in other tests.  One thing at a time though, otherwise, I'll never be
done.  :-)

Thanks!

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]