Note: Sending SIGCONT to GDB manually makes it work properly again (until it hangs again eventually). I now do this in a separate console whenever I want to use gdb:

while true; do killall -s SIGCONT gdb || break; sleep 1; done

Same problem here with 7.8.

Thing is that this seems to happen quite randomly. I've run into the problem with a larger project, sometimes it would hang on thread creation and sometimes when joining or destructing the threads.

Also, it doesn't seem to hang at all when attaching strace to the gdb process itself, which doesn't exactly help gathering more information about this problem...

I've tried various things to recreate this but have failed.
Presumably it's a race condition somewhere.

I'm not sure this will help track things down, but it's easy enough to try.

Can the problem be repro'd after adding

set debug infrun 1
set debug lin-lwp 1

to the set of gdb commands before the inferior is run?
If so, attaching the (entire!) output of that to this bug may be helpful.

Created attachment 7742 [details]
gdb debug output

here's the output when running the example compiled test.cpp in GDB with the debug options enabled

I can confirm this issue. To me it happens when debugging Geany.

I recently ran into this on ArchLinux too, since I ran into this debugging Blender3D application (gdb typically locks up quickly within ~5 or so 'step' commands, but not instantly)


I tried to look into this further, with the intention of finding which sha1 broke... 

- lldb works fine (just a sanity check that its not the application)
- gdb 7.7.1 works. *
- gdb 7.8 locks up. *

* - Both clean build compiled on my own system, default configuration,(--prefix=/opt/gdb --with-python=no)

I had troubles with misc build errors attempting to find the git revision that broke however, all the revisions I managed to build would lock-up, but quite a few revisions I checked out failed to build.

Can we make this a critical priority? This makes gdb pretty much useless for all multithreaded programs...

By the way, I can reproduce this on my machine. For me, SIGCONT unfortunately does not have any effect on the hanging gdb. However, downgrading to 7.7.1 works fine!

I can confirm that the SIGCONT workaround works for me. Remember that you have to send it to gdb itself, not the debugee.

Comment on attachment 7742 [details]
gdb debug output

I don't understand this part:

infrun: TARGET_WAITKIND_EXITED
[Inferior 1 (process 4912) exited normally]
infrun: stop_waiting
(gdb) # it hangs here, sending sigcont from another terminal now
(gdb) # again, stuck here - sending another sigcont
(gdb) # and again hung.... one more sigcont
(gdb) q

Did you send a SIGCONT before or after you saw the (gdb) prompt here?
[Just want to confirm how to interpret this.]

(In reply to Jan Rüegg from comment #7)
> Can we make this a critical priority? This makes gdb pretty much useless for
> all multithreaded programs...

Can anyone recreate this on ubuntu precise or trusty or fedora fc20?
[those are machines I have]

If you can, and can provide the testcase and complete session log,
that'd be great.

@dje: The first occurrences of these "# ..." lines is when I typed them into the console when GDB was hung. Later, once GDB becomes unfrozen again, it will re-print the strings I inserted into the console apparently, which is why you'll see them again below. So just ignore the (gdb) prompt lines which include these lines at the end. Only the lines before that are relevant.

Hope that helps.

I encountered this issue on Archlinux with gdb 7.8.
I bisected the issue to the commit

commit ed3ef33944c39d9a3cea72b9a7cef3c20f0e3461
Author: Doug Evans <xdje42@gmail.com>
Date:   Sun Feb 9 19:40:01 2014 -0800

    Add Guile as an extension language.

I hope this helps to track down the issue.

(In reply to Bernd Amend from comment #13)
> I encountered this issue on Archlinux with gdb 7.8.
> I bisected the issue to the commit
> 
> commit ed3ef33944c39d9a3cea72b9a7cef3c20f0e3461
> Author: Doug Evans <xdje42@gmail.com>
> Date:   Sun Feb 9 19:40:01 2014 -0800
> 
>     Add Guile as an extension language.
> 
> I hope this helps to track down the issue.

I'm not sure how much help a bisect can be here is the issue is a race condition.
But you have given me an idea.
Guile uses a separate thread to help with garbage collection, and perhaps a SIGCHLD is being lost somehow (or whatever).

Question: Does the bug go away if you configure gdb --without-guile?
[Assuming you've got guile installed and the buggy gdb was configured with it.]

The bug goes away if I compile gdb without guile.

I'm affected by this bug but my gdb doesn't know the --without-guile options, or any other that contains guile (checked with gdb --help | grep guile).

(In reply to Thomas Martitz from comment #16)
> I'm affected by this bug but my gdb doesn't know the --without-guile
> options, or any other that contains guile

It's a compile-time flag for the 'configure' script, not a runtime option.

I can confirm it works just fine with guile disabled.

(In reply to Philip Rebohle from comment #17)
> (In reply to Thomas Martitz from comment #16)
> > I'm affected by this bug but my gdb doesn't know the --without-guile
> > options, or any other that contains guile
> 
> It's a compile-time flag for the 'configure' script, not a runtime option.
> 
> I can confirm it works just fine with guile disabled.

For those where --without-guile fixes things,
can you record here what version of guile, and what version of libgc you are using is?
Thanks!

(In reply to Doug Evans from comment #18)
> (In reply to Philip Rebohle from comment #17)
> > (In reply to Thomas Martitz from comment #16)
> > > I'm affected by this bug but my gdb doesn't know the --without-guile
> > > options, or any other that contains guile
> > 
> > It's a compile-time flag for the 'configure' script, not a runtime option.
> > 
> > I can confirm it works just fine with guile disabled.
> 
> For those where --without-guile fixes things,
> can you record here what version of guile, and what version of libgc you are
> using is?
> Thanks!

Also, can you repeat the experiment 1000 times or so?
[I'm assuming it's easy enough to script.]
There are reports that people are experiencing the issue with 7.7.
7.7 does not have guile.

What is "the experiment"? I experience the problem every single time I start gdb with a multithreaded application, what information will give you this 1000 times?

(In reply to Thomas Martitz from comment #20)
> What is "the experiment"? I experience the problem every single time I start
> gdb with a multithreaded application, what information will give you this
> 1000 times?

If it's a race condition independent of guile, then if you get a hang even with --without-guile, then that is good data to have.  I don't know if it's a race condition.  It may not be.  At this point I'm still collecting data.

I only picked 1000 as something out of the air.
Even if gdb hangs 10 times in 10 tries that's good data.

Questions:
What system are you on, and which version?
What version of libgc are you using?
What version of guile are you using?
I may need to install it, as I cannot recreate this on the systems I have access to (ubuntu precise, fedora fc20).

(In reply to Thomas Martitz from comment #20)
> What is "the experiment"? I experience the problem every single time I start
> gdb with a multithreaded application, what information will give you this
> 1000 times?

btw, can I get repro instructions?
Thanks!

The initial bug report says:

g++ -std=c++11 -lpthread test.cpp -o test
gdb ./test
^C^C^C -> nothing, it's impossible to interrupt

But after doing just "gdb ./test" gdb has not run the program, therefore no shared libraries have been loaded yet, and therefore gdb does not yet even know if the program is multithreaded.

Can anyone reproduce this with a non-multithreaded program?
[I suspect the problem is just more easily triggered with a multithreaded program, but it would be good data to have.]

(In reply to Doug Evans from comment #22)
> But after doing just "gdb ./test" gdb has not run the program, therefore no
> shared libraries have been loaded yet, and therefore gdb does not yet even
> know if the program is multithreaded.

For pedantic completeness sake,
I guess I should mention that libpthread could be statically linked in.
[Or that one could have one's own thread implementation - I've never used one so I don't know how well gdb works with it.]

Still, does gdb hang *before* the program is run?

(In reply to Doug Evans from comment #21)
> Questions:
> What system are you on, and which version?
> What version of libgc are you using?
> What version of guile are you using?

For me, it's the following:
- Arch Linux (everything up to date, as always)
- gc=7.4.2
- guile=2.0.11

Works fine even a thousand times with guile disabled, yes.


(In reply to Doug Evans from comment #23)
> Still, does gdb hang *before* the program is run?

Just tried this with a trivial, single-threaded Hello World program, a few runs *did* actually lock up before the program was run. Interestingly, ^C works in that case and gives me a gdb prompt.

Multi-threaded programs will almost always hang on thread creation, which indeed happens far more often.

Again, this only goes for the guile-enabled version. Without guile, I cannot reproduce any lockup.

(In reply to Philip Rebohle from comment #24)
> - gc=7.4.2

Just downgraded that one to 7.2d and the lockups are gone.

(In reply to Philip Rebohle from comment #25)
> (In reply to Philip Rebohle from comment #24)
> > - gc=7.4.2
> 
> Just downgraded that one to 7.2d and the lockups are gone.

That's great data.
Thanks!

> Still, does gdb hang *before* the program is run?

I have never seen it.

During the bisecting the different versions behaved differently.
Most of the versions hang directly after entering run.
In this case it was sometimes possible to get a prompt with ^C.

Others versions only if a breakpoint was set and hit. (The released version 7.8 shows this behaviour)
In this case I was unable to reach a gdb prompt with ^C.
Nevertheless even without a breakpoint the application doesn't terminate.
Interestingly if I step thru an application the freeze always appears on the same position. The position itself changes with the different gdb versions.

This:

gdb ./test
^C^C^C -> nothing, it's impossible to interrupt

probably was due to a alias which reads "gdb --eval-command="run" --args", I never saw gdb freeze without running anything.

Can confirm that compiling gdb without Guile fixes this for me. Latest Arch Linux x86_64, GDB-7.8, Guile-2.0.11, gc-7.4.2.

Data point:
If I hack libgc and guile to block SIGCHLD in all the threads they create, I can make the hang go away.

-->

The sigsuspend that gdb/linux-nat.c calls doesn't receive the SIGCHLD because another thread receives it.

Can I ask someone to try this patch to see if it fixes the hang?
It does for me, but I'd like to get more confirmation if I can.

If you've changed libgc from 7.4 to 7.2, you'll need to restore back to 7.4.
And if you've built gdb --without-guile, you'll need to rebuild it with guile.
[The point being we want to test with a gdb that experiences the hang.
It would be a good idea to first do a "before" test, just to verify you are seeing the hang, apply the patch, rebuild, and see if the hang goes away.

Many thanks to any who can try this.

[I'm not sure bugzilla will let me attach the file in this post.
Look for 17247-experiment-1.patch in the Attachments list.]

Created attachment 7762 [details]
17247-experiment-1.patch

Tentative fix.

Comment on attachment 7762 [details]
17247-experiment-1.patch

> +#ifdef HAVE_SIGPROCMASK
> +  /* Before we initialize Guile, block SIGCHLD.
> +     This is done so that all threads created during Guile initialization
> +     have SIGCHLD blocked.  PR 17247.  */
> +  sigprocmask (SIG_SETMASK, NULL, &sigset_for_guile);
> +  sigaddset (&sigset_for_guile, SIGCHLD);
> +  sigprocmask (SIG_SETMASK, &sigset_for_guile, NULL);

Using SIG_BLOCK lets this be a single syscall.

> +#endif
> +
>    /* scm_with_guile is the most portable way to initialize Guile.
>       Plus we need to initialize the Guile support while in Guile mode
>       (e.g., called from within a call to scm_with_guile).  */
>    scm_with_guile (call_initialize_gdb_module, NULL);
>  
> +#ifdef HAVE_SIGPROCMASK
> +  /* Undo the blocking of SIGCHLD.  */
> +  sigdelset (&sigset_for_guile, SIGCHLD);
> +  sigprocmask (SIG_SETMASK, &sigset_for_guile, NULL);

This assumes SIGCHLD wasn't blocked before.  Best avoid that, like
in the below pseudo-patch.

+ sigset_t sigchld_set, prev_set;
...
+#ifdef HAVE_SIGPROCMASK
+  /* Before we initialize Guile, make sure SIGCHLD is blocked.
+     This is done so that all threads created during Guile initialization
+     have SIGCHLD blocked.  PR 17247.  */
+  sigemptyset (sigchld_set);
+  sigaddset (&sigchld_set, SIGCHLD);
+  sigprocmask (SIG_BLOCK, &sigchld_set, &prev_set);
+#endif
...
+#ifdef HAVE_SIGPROCMASK
+  /* Restore the previous mask.  */
+  sigprocmask (SIG_SETMASK, &prev_set, NULL);
+#endif

We're encountering a reliable hang on Cygwin GDB 7.8 as well, and Cygwin's
GDB was never built with guile.  It can simply be reproduced like this:

  $ gdb /usr/bin/emacs-w32
  [...]
  (gdb) r
  Starting program: /bin/emacs-w32.exe
  [New Thread 3944.0xfe4]
  [New Thread 3944.0xcb8]
  [New Thread 3944.0xcdc]
  [New Thread 3944.0xf0]
  [New Thread 3944.0x9d4]
  [New Thread 3944.0x9fc]

At this point the GUI program is up and running, for about a second.
Then the cursor stops moving and neither the inferior nor GDB can be
interrupted.  A hard kill of GDB is required.

The previous Cygwin GDB version was 7.6.50, and it doesn't have this
problem.


Corinna

I've tested GDB with Doug Evans' patch and it seems to be working for me -- I've tested it on a couple Qt apps so far. Patch with corrections proposed by Pedro Alves also works.

Could it be possible that the Cygwin hang is caused by something else? When this bug manifests itself on my system, GUI apps never display at all, let alone run for a second, and killing the hung app leaves GDB operable.

For reference sake, see also PR 17314.

*** Bug 17185 has been marked as a duplicate of this bug. ***

(In reply to Evgeny Grablyk from comment #35)
> I've tested GDB with Doug Evans' patch and it seems to be working for me --
> I've tested it on a couple Qt apps so far. Patch with corrections proposed
> by Pedro Alves also works.
> 
> Could it be possible that the Cygwin hang is caused by something else? When
> this bug manifests itself on my system, GUI apps never display at all, let
> alone run for a second, and killing the hung app leaves GDB operable.

I honestly don't know.  This was the first release of GDB for Cygwin built
with Python support so I suspected this.  However, even after rebuilding
GDB without python support, GDB and the inferior still hang the same way.
For completeness I also tried Doug's patch, but to no avail.

I also attached a second GDB to the hanging GDB and I got this backtrace:

(gdb) thr 1
[Switching to thread 1 (Thread 2832.0x640)]
#0  0x00007ff9efc6c7da in ntdll!ZwWaitForDebugEvent ()
   from /mnt/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x00007ff9efc6c7da in ntdll!ZwWaitForDebugEvent ()
   from /mnt/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007ff9ed31a0c1 in WaitForDebugEvent ()
   from /mnt/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000010042b9b6 in get_windows_debug_event (pid=-1, ourstatus=0xc3a2c0,
    ops=0x6000bfb80) at /usr/src/debug/gdb-7.8-1/gdb/windows-nat.c:1409
#3  windows_wait (ops=0x6000bfb80, ptid=..., ourstatus=0xc3a2c0, options=0)
    at /usr/src/debug/gdb-7.8-1/gdb/windows-nat.c:1643
#4  0x000000010055734b in delegate_wait (self=<optimized out>, arg1=...,
    arg2=<optimized out>, arg3=0)
    at /usr/src/debug/gdb-7.8-1/gdb/target-delegates.c:60
#5  0x000000010055f2d4 in target_wait (ptid=..., status=status@entry=0xc3a2c0,
    options=options@entry=0) at /usr/src/debug/gdb-7.8-1/gdb/target.c:2107
#6  0x0000000100524efc in wait_for_inferior ()
    at /usr/src/debug/gdb-7.8-1/gdb/infrun.c:2828
#7  0x000000010052517a in proceed (addr=<optimized out>,
    siggnal=siggnal@entry=GDB_SIGNAL_0, step=step@entry=0)
    at /usr/src/debug/gdb-7.8-1/gdb/infrun.c:2388
#8  0x0000000100517fbd in run_command_1 (args=0x0, from_tty=1,
    tbreak_at_main=<optimized out>)
    at /usr/src/debug/gdb-7.8-1/gdb/infcmd.c:630
#9  0x00000001005f789d in execute_command (p=<optimized out>,
    p@entry=0x600038940 "", from_tty=1)
    at /usr/src/debug/gdb-7.8-1/gdb/top.c:462
#10 0x000000010053c206 in command_handler (command=0x600038940 "")
    at /usr/src/debug/gdb-7.8-1/gdb/event-top.c:433
#11 0x000000010053c838 in command_line_handler (rl=<optimized out>)
    at /usr/src/debug/gdb-7.8-1/gdb/event-top.c:630
#12 0x00000003f5285c03 in rl_callback_read_char ()
   from /usr/bin/cygreadline7.dll
#13 0x000000010053c269 in rl_callback_read_char_wrapper (
    client_data=<optimized out>)
    at /usr/src/debug/gdb-7.8-1/gdb/event-top.c:167
#14 0x000000010053ae54 in process_event ()
    at /usr/src/debug/gdb-7.8-1/gdb/event-loop.c:343
#15 0x000000010053b1d7 in gdb_do_one_event ()
    at /usr/src/debug/gdb-7.8-1/gdb/event-loop.c:407
#16 0x000000010053b41e in start_event_loop ()
    at /usr/src/debug/gdb-7.8-1/gdb/event-loop.c:432
#17 0x0000000100534b56 in captured_command_loop (data=data@entry=0x0)
    at /usr/src/debug/gdb-7.8-1/gdb/main.c:302
#18 0x0000000100531c8a in catch_errors (
    func=func@entry=0x100534b40 <captured_command_loop>,
    func_args=func_args@entry=0x0,
    errstring=errstring@entry=0x1007621c3 <__PRETTY_FUNCTION__.13666+257> "",
    mask=mask@entry=RETURN_MASK_ALL)
    at /usr/src/debug/gdb-7.8-1/gdb/exceptions.c:506
#19 0x0000000100535b5b in captured_main (data=data@entry=0xc3aab0)
    at /usr/src/debug/gdb-7.8-1/gdb/main.c:1155
#20 0x0000000100531c8a in catch_errors (
    func=func@entry=0x1005350b0 <captured_main>,
    func_args=func_args@entry=0xc3aab0,
    errstring=errstring@entry=0x1007621c3 <__PRETTY_FUNCTION__.13666+257> "",
    mask=mask@entry=RETURN_MASK_ALL)
    at /usr/src/debug/gdb-7.8-1/gdb/exceptions.c:506
#21 0x0000000100536090 in gdb_main (args=args@entry=0xc3aab0)
    at /usr/src/debug/gdb-7.8-1/gdb/main.c:1163
#22 0x00000001006e8e58 in main (argc=2, argv=0xc3ab30)
    at /usr/src/debug/gdb-7.8-1/gdb/gdb.c:33



Corinna

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  92d8d229d9a310ebfcfc13bf4a75a286c1add1ac (commit)
      from  837405970476d31d6b4d7774e2c914fdfa7a9930 (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=92d8d229d9a310ebfcfc13bf4a75a286c1add1ac

commit 92d8d229d9a310ebfcfc13bf4a75a286c1add1ac
Author: Doug Evans <xdje42@gmail.com>
Date:   Mon Sep 8 22:45:34 2014 -0700

    Fix for PR 17247: Block SIGCHLD while initializing Guile.
    
    The problem here is that if a thread other than gdb's main thread
    gets a SIGCHLD (it's an asynchronous signal so the kernel will
    essentially pick a random thread) then gdb will hang if it is
    in sigsuspend when the SIGCHLD is delivered.  The other thread
    will see the signal and the sigsuspend won't "wake up".
    
    Guile and libgc should be blocking SIGCHLD in their threads,
    but we need to work with Guile 2.0 and libgc 7.4.
    The problem first shows up in libgc 7.4 because it is the first
    release that enables multiple marker threads by default.
    
    gdb/ChangeLog:
    
    	PR 17247
    	* guile.c: #include <signal.h>.
    	(_initialize_guile): Block SIGCHLD while initializing Guile.
    
    	Replaces the following, which is reverted.
    
    	2014-07-26  Doug Evans  <xdje42@gmail.com>
    
    	PR 17185
    	* configure.ac: Add check for header gc/gc.h.
    	Add check for function setenv.
    	* configure: Regenerate.
    	* config.in: Regenerate.
    	* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.

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

Summary of changes:
 gdb/ChangeLog     |   17 +++++++++++++
 gdb/config.in     |    6 ----
 gdb/configure     |   26 --------------------
 gdb/configure.ac  |    5 ----
 gdb/guile/guile.c |   67 ++++++++++++++++++++++++++++------------------------
 5 files changed, 53 insertions(+), 68 deletions(-)

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, gdb-7.8-branch has been updated
       via  0df33300929f9b54ddcf040f9b1fe69c1a88304b (commit)
      from  0fefcb3282480d15a66fbf5daf65ef25adee9e76 (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=0df33300929f9b54ddcf040f9b1fe69c1a88304b

commit 0df33300929f9b54ddcf040f9b1fe69c1a88304b
Author: Doug Evans <xdje42@gmail.com>
Date:   Tue Sep 9 21:42:20 2014 -0700

    Fix for PR 17247: Block SIGCHLD while initializing Guile.
    
    The problem here is that if a thread other than gdb's main thread
    gets a SIGCHLD (it's an asynchronous signal so the kernel will
    essentially pick a random thread) then gdb will hang if it is
    in sigsuspend when the SIGCHLD is delivered.  The other thread
    will see the signal and the sigsuspend won't "wake up".
    
    Guile and libgc should be blocking SIGCHLD in their threads,
    but we need to work with Guile 2.0 and libgc 7.4.
    The problem first shows up in libgc 7.4 because it is the first
    release that enables multiple marker threads by default.
    
    gdb/ChangeLog:
    
        	PR 17247
        	* guile.c: #include <signal.h>.
        	(_initialize_guile): Block SIGCHLD while initializing Guile.
    
        	Replaces the following, which is reverted.
    
        	2014-07-26  Doug Evans  <xdje42@gmail.com>
    
        	PR 17185
        	* configure.ac: Add check for header gc/gc.h.
        	Add check for function setenv.
        	* configure: Regenerate.
        	* config.in: Regenerate.
        	* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.

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

Summary of changes:
 gdb/ChangeLog     |   17 +++++++++++++
 gdb/config.in     |    6 ----
 gdb/configure     |   26 --------------------
 gdb/configure.ac  |    5 ----
 gdb/guile/guile.c |   67 ++++++++++++++++++++++++++++------------------------
 5 files changed, 53 insertions(+), 68 deletions(-)

patch committed to both trunk and 7.8 branch

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 annotated tag, gdb-7.8.1-release has been created
        at  60cd8f8e7f38daf7d59e82b9fb3b8840a3a714c9 (tag)
   tagging  21de41c04a26bb04f2e827d35fd48c991fa991b1 (commit)
  replaces  gdb-7.8-release
 tagged by  Joel Brobecker
        on  Wed Oct 29 12:47:08 2014 -0700

- Log -----------------------------------------------------------------
GDB 7.8.1 Release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEABECAAYFAlRRRDwACgkQku2wS/8yXPNA3gCgmaBkksiuRbHoYAudWcZYwiJ4
upIAoI2vGr/6e6CNHxIinVYQ2IJCY/4V
=wgXR
-----END PGP SIGNATURE-----

Doug Evans (3):
      Fix for PR 17247: Block SIGCHLD while initializing Guile.
      PR guile/17367
      PR python/17364

Eli Zaretskii (1):
      Avoid compiler warnings about incomplete parameter types.

GDB Administrator (92):
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in
      Automatic date update in version.in

Jan Kratochvil (4):
      Fix incorrect placement of two Intel gdb/NEWS items
      Fix 'gcore' with exited threads
      Fix crash on Python frame filters with unreadable arg
      Fix regression for Linux vDSO in GDB (PR gdb/17407).

Joel Brobecker (5):
      Document the GDB 7.8 release in gdb/ChangeLog
      Bump GDB version number to 7.8.0.DATE-cvs.
      Add "frame.h" #include in gdbarch.h.
      state->dr_control_mirror == 0 failed assertion in gdbserver on Windows XP
      Set GDB version number to 7.8.1.

Pedro Alves (9):
      testsuite: refactor spawn and wait for attach
      gdb/17347 - Regression: GDB stopped on run with attached process
      Aarch64: Make CPSR a 32-bit register again in the target description
      Make common code handle target_terminal_* idempotency
      PR gdb/17472: With annotations, input while executing in the foreground crashes readline/GDB
      PR gdb/17300: Input after "c -a" crashes readline/GDB
      PR gdb/17471: Repeating a background command makes it foreground
      PR python/17372 - Python hangs when displaying help()
      PR 17408 - assertion failure in switch_back_to_stepped_thread

Siva Chandra (1):
      Fix xmethod Python so that it works with Python3.

Yao Qi (2):
      Fix build/17104
      Remove workaround to libbabeltrace 1.1.0 issue

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