From 5979e98c0613bd88915f740f6c7ab32c570b5091 Mon Sep 17 00:00:00 2001 From: Jan Kratochvil Date: Fri, 19 Jun 2015 16:43:15 +0200 Subject: [PATCH] Backport 'thread apply all' option '-ascending' for ABRT. --- gdb-upstream.patch | 188 +++++++++++++++++++++++++++++++++++++++++++++ gdb.spec | 5 +- 2 files changed, 192 insertions(+), 1 deletion(-) diff --git a/gdb-upstream.patch b/gdb-upstream.patch index 3116a53..03ddcf4 100644 --- a/gdb-upstream.patch +++ b/gdb-upstream.patch @@ -51,3 +51,191 @@ Date: Tue Jan 27 19:56:45 2015 +0200 if (!overlay_debugging) error (_("Overlay debugging not enabled. " + + + +commit 253828f102691732d014e8f1d62f9b5dc779b39c +Author: Jan Kratochvil +Date: Thu Jan 22 21:04:53 2015 +0100 + + Sort threads for thread apply all + + downstream Fedora request: + Please make it easier to find the backtrace of the crashing thread + https://bugzilla.redhat.com/show_bug.cgi?id=1024504 + + Currently after loading a core file GDB prints: + + Core was generated by `./threadcrash1'. + Program terminated with signal SIGSEGV, Segmentation fault. + 8 *(volatile int *)0=0; + (gdb) _ + + there is nowhere seen which of the threads had crashed. In reality GDB always + numbers that thread as #1 and it is the current thread that time. But after + dumping all the info into a file for later analysis it is no longer obvious. + 'thread apply all bt' even puts the thread #1 to the _end_ of the output!!! + + I find maybe as good enough and with no risk of UI change flamewar to just + sort the threads by their number. Currently they are printed as they happen + in the internal GDB list which has no advantage. Printing thread #1 as the + first one with assumed 'thread apply all bt' (after the core file is loaded) + should make the complaint resolved I guess. + + On Thu, 15 Jan 2015 20:29:07 +0100, Doug Evans wrote: + No objection to sorting the list, but if thread #1 is the important one, + then a concern could be it'll have scrolled off the screen (such a + concern has been voiced in another thread in another context), + and if not lost (say it's in an emacs buffer) one would still have + to scroll back to see it. + So one *could* still want #1 to be last. + Do we want an option to choose the sort direction? + + gdb/ChangeLog + 2015-01-22 Jan Kratochvil + + * NEWS (Changes since GDB 7.9): Add 'thread apply all' option + '-ascending'. + * thread.c (tp_array_compar_ascending, tp_array_compar): New. + (thread_apply_all_command): Parse CMD for tp_array_compar_ascending. + Sort tp_array using tp_array_compar. + (_initialize_thread): Extend thread_apply_all_command help. + + gdb/doc/ChangeLog + 2015-01-22 Jan Kratochvil + + * gdb.texinfo (Threads): Describe -ascending for thread apply all. + +### a/gdb/ChangeLog +### b/gdb/ChangeLog +## -1,5 +1,14 @@ + 2015-01-22 Jan Kratochvil + ++ * NEWS (Changes since GDB 7.9): Add 'thread apply all' option ++ '-ascending'. ++ * thread.c (tp_array_compar_ascending, tp_array_compar): New. ++ (thread_apply_all_command): Parse CMD for tp_array_compar_ascending. ++ Sort tp_array using tp_array_compar. ++ (_initialize_thread): Extend thread_apply_all_command help. ++ ++2015-01-22 Jan Kratochvil ++ + * corelow.c (core_open): Call also thread_command. + * gdbthread.h (thread_command): New prototype moved from ... + * thread.c (thread_command): ... here. +--- gdb-7.9.1/gdb/NEWS.orig 2015-06-19 15:45:57.614937084 +0200 ++++ gdb-7.9.1/gdb/NEWS 2015-06-19 15:46:26.352104210 +0200 +@@ -1,6 +1,13 @@ + What has changed in GDB? + (Organized release by release) + ++*** Changes since GDB 7.9.1 ++ ++* New options ++ ++* The command 'thread apply all' can now support new option '-ascending' ++ to call its specified command for all threads in ascending order. ++ + *** Changes in GDB 7.9.1 + + * Python Scripting +### a/gdb/doc/ChangeLog +### b/gdb/doc/ChangeLog +## -1,3 +1,7 @@ ++2015-01-22 Jan Kratochvil ++ ++ * gdb.texinfo (Threads): Describe -ascending for thread apply all. ++ + 2015-01-16 Eli Zaretskii + + * doc/gdb.texinfo (TUI Commands): Document the possible +--- a/gdb/doc/gdb.texinfo ++++ b/gdb/doc/gdb.texinfo +@@ -2959,14 +2959,17 @@ information on convenience variables. + + @kindex thread apply + @cindex apply command to several threads +-@item thread apply [@var{threadno} | all] @var{command} ++@item thread apply [@var{threadno} | all [-ascending]] @var{command} + The @code{thread apply} command allows you to apply the named + @var{command} to one or more threads. Specify the numbers of the + threads that you want affected with the command argument + @var{threadno}. It can be a single thread number, one of the numbers + shown in the first field of the @samp{info threads} display; or it +-could be a range of thread numbers, as in @code{2-4}. To apply a +-command to all threads, type @kbd{thread apply all @var{command}}. ++could be a range of thread numbers, as in @code{2-4}. To apply ++a command to all threads in descending order, type @kbd{thread apply all ++@var{command}}. To apply a command to all threads in ascending order, ++type @kbd{thread apply all -ascending @var{command}}. ++ + + @kindex thread name + @cindex name a thread +--- a/gdb/thread.c ++++ b/gdb/thread.c +@@ -1381,6 +1381,24 @@ make_cleanup_restore_current_thread (void) + restore_current_thread_cleanup_dtor); + } + ++/* If non-zero tp_array_compar should sort in ascending order, otherwise in ++ descending order. */ ++ ++static int tp_array_compar_ascending; ++ ++/* Sort an array for struct thread_info pointers by their NUM, order is ++ determined by TP_ARRAY_COMPAR_ASCENDING. */ ++ ++static int ++tp_array_compar (const void *ap_voidp, const void *bp_voidp) ++{ ++ const struct thread_info *const *ap = ap_voidp; ++ const struct thread_info *const *bp = bp_voidp; ++ ++ return ((((*ap)->num > (*bp)->num) - ((*ap)->num < (*bp)->num)) ++ * (tp_array_compar_ascending ? +1 : -1)); ++} ++ + /* Apply a GDB command to a list of threads. List syntax is a whitespace + seperated list of numbers, or ranges, or the keyword `all'. Ranges consist + of two numbers seperated by a hyphen. Examples: +@@ -1397,6 +1415,14 @@ thread_apply_all_command (char *cmd, int from_tty) + int tc; + struct thread_array_cleanup ta_cleanup; + ++ tp_array_compar_ascending = 0; ++ if (cmd != NULL ++ && check_for_argument (&cmd, "-ascending", strlen ("-ascending"))) ++ { ++ cmd = skip_spaces (cmd); ++ tp_array_compar_ascending = 1; ++ } ++ + if (cmd == NULL || *cmd == '\000') + error (_("Please specify a command following the thread ID list")); + +@@ -1430,6 +1456,8 @@ thread_apply_all_command (char *cmd, int from_tty) + i++; + } + ++ qsort (tp_array, i, sizeof (*tp_array), tp_array_compar); ++ + make_cleanup (set_thread_refcount, &ta_cleanup); + + for (k = 0; k != i; k++) +@@ -1738,7 +1766,14 @@ The new thread ID must be currently known."), + &thread_apply_list, "thread apply ", 1, &thread_cmd_list); + + add_cmd ("all", class_run, thread_apply_all_command, +- _("Apply a command to all threads."), &thread_apply_list); ++ _("\ ++Apply a command to all threads.\n\ ++\n\ ++Usage: thread apply all [-ascending] \n\ ++-ascending: Call for all threads in ascending order.\n\ ++ The default is descending order.\ ++"), ++ &thread_apply_list); + + add_cmd ("name", class_run, thread_name_command, + _("Set the current thread's name.\n\ diff --git a/gdb.spec b/gdb.spec index 5f97f4d..6d36cdd 100644 --- a/gdb.spec +++ b/gdb.spec @@ -26,7 +26,7 @@ Version: 7.9.1 # The release always contains a leading reserved number, start it at 1. # `upstream' is not a part of `name' to stay fully rpm dependencies compatible for the testing. -Release: 15%{?dist} +Release: 16%{?dist} License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ and GPLv2+ with exceptions and GPL+ and LGPLv2+ and BSD and Public Domain and GFDL Group: Development/Debuggers @@ -1330,6 +1330,9 @@ then fi %changelog +* Fri Jun 19 2015 Jan Kratochvil - 7.9.1-16.fc22 +- Backport 'thread apply all' option '-ascending' for ABRT. + * Tue Jun 16 2015 Jan Kratochvil - 7.9.1-15.fc22 - Fix enum e e 'Attempt to use a type name as an expr.' (Keith Seitz, PR 16253).