This is the mail archive of the gdb-cvs@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]

gdb and binutils branch master updated. 2278c276a887b12b85ae30d63c446bf45a3bfd9f


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  2278c276a887b12b85ae30d63c446bf45a3bfd9f (commit)
      from  b57bacecd5f3684cd9f58b0da0e2caccbb6a546d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2278c276a887b12b85ae30d63c446bf45a3bfd9f

commit 2278c276a887b12b85ae30d63c446bf45a3bfd9f
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Sep 24 18:59:42 2014 +0100

    gdb.threads/manythreads.exp: clean up and add comment
    
    In git b57bacec, I said:
    
    > With that in place, the need to delay "Program received signal FOO"
    > was actually caught by the manythreads.exp test.  Without that bit, I
    > was getting:
    >
    >   [Thread 0x7ffff7f13700 (LWP 4499) exited]
    >   [New Thread 0x7ffff7f0b700 (LWP 4500)]
    >   ^C
    >   Program received signal SIGINT, Interrupt.
    >   [New Thread 0x7ffff7f03700 (LWP 4501)]           <<< new output
    >   [Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
    >   __GI___nptl_death_event () at events.c:31
    >   31      {
    >   (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
    >
    > That is, I was now getting "New Thread" lines after the "Program
    > received signal" line, and the test doesn't expect them.  As the
    > number of new threads discovered before and after the "Program
    > received signal" output is unbounded, it's much nicer to defer
    > "Program received signal" until after synching the thread list, thus
    > close to the "switching to thread" output and "current frame/source"
    > info:
    >
    >   [Thread 0x7ffff7863700 (LWP 7647) exited]
    >   ^C[New Thread 0x7ffff786b700 (LWP 7648)]
    >
    >   Program received signal SIGINT, Interrupt.
    >   [Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
    >   __GI___nptl_create_event () at events.c:25
    >   25      {
    >   (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1
    
    This commit factors out the two places in the test that are effected
    by this, and adds there a destilled version of the comment above.
    
    gdb/testsuite/
    2014-10-02  Pedro Alves  <palves@redhat.com>
    
    	* gdb.threads/manythreads.exp (interrupt_and_wait): New procedure.
    	(top level) <stop threads 1, stop threads 2>: Use it.

-----------------------------------------------------------------------

Summary of changes:
 gdb/testsuite/ChangeLog                   |    5 ++
 gdb/testsuite/gdb.threads/manythreads.exp |   83 ++++++++++++++++++-----------
 2 files changed, 56 insertions(+), 32 deletions(-)


hooks/post-receive
-- 
gdb and binutils


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