2015-02-11 14:31:05 +00:00
|
|
|
commit 7a270e0c9ba0eb738a4c30258ab29c09963fcd4d
|
|
|
|
Author: Alexander Klimov <alserkli@inbox.ru>
|
|
|
|
Date: Tue Jan 27 19:56:45 2015 +0200
|
|
|
|
|
|
|
|
Fix build failure in symfile.c::unmap_overlay_command (GCC5 bug)
|
|
|
|
|
|
|
|
Compilation of (GDB) 7.9.50.20150127-cvs with (GCC) 5.0.0 20150127
|
|
|
|
fails with
|
|
|
|
|
|
|
|
In file included from symfile.c:32:0:
|
|
|
|
symfile.c: In function 'unmap_overlay_command':
|
|
|
|
objfiles.h:628:3: error: 'sec' may be used uninitialized in this
|
|
|
|
function [-Werror=maybe-uninitialized]
|
|
|
|
for (osect = objfile->sections; osect < objfile->sections_end; osect++) \
|
|
|
|
^
|
|
|
|
symfile.c:3442:23: note: 'sec' was declared here
|
|
|
|
struct obj_section *sec;
|
|
|
|
^
|
|
|
|
cc1: all warnings being treated as errors
|
|
|
|
make[2]: *** [symfile.o] Error 1
|
|
|
|
make[2]: Leaving directory `gdb/gdb'
|
|
|
|
|
|
|
|
While the bug was reported to GCC as
|
|
|
|
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64823>,
|
|
|
|
the attached patch simply initializes sec with NULL.
|
|
|
|
|
|
|
|
gdb/ChangeLog:
|
|
|
|
|
|
|
|
* symfile.c (unmap_overlay_command): Initialize sec to NULL.
|
|
|
|
|
|
|
|
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
### a/gdb/ChangeLog
|
|
|
|
### b/gdb/ChangeLog
|
|
|
|
## -1,3 +1,7 @@
|
|
|
|
+2015-01-29 Joel Brobecker <brobecker@adacore.com> (tiny patch)
|
|
|
|
+
|
|
|
|
+ * symfile.c (unmap_overlay_command): Initialize sec to NULL.
|
|
|
|
+
|
|
|
|
2015-01-27 Doug Evans <dje@google.com>
|
|
|
|
|
|
|
|
* NEWS: Mention gdb.Objfile.username.
|
|
|
|
--- a/gdb/symfile.c
|
|
|
|
+++ b/gdb/symfile.c
|
|
|
|
@@ -3439,7 +3439,7 @@ static void
|
|
|
|
unmap_overlay_command (char *args, int from_tty)
|
|
|
|
{
|
|
|
|
struct objfile *objfile;
|
|
|
|
- struct obj_section *sec;
|
|
|
|
+ struct obj_section *sec = NULL;
|
|
|
|
|
|
|
|
if (!overlay_debugging)
|
|
|
|
error (_("Overlay debugging not enabled. "
|
2015-06-19 14:43:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
commit 253828f102691732d014e8f1d62f9b5dc779b39c
|
|
|
|
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
|
|
|
|
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 <jan.kratochvil@redhat.com>
|
|
|
|
|
|
|
|
* 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 <jan.kratochvil@redhat.com>
|
|
|
|
|
|
|
|
* gdb.texinfo (Threads): Describe -ascending for thread apply all.
|
|
|
|
|
|
|
|
### a/gdb/ChangeLog
|
|
|
|
### b/gdb/ChangeLog
|
|
|
|
## -1,5 +1,14 @@
|
|
|
|
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
|
|
|
|
|
|
|
|
+ * 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 <jan.kratochvil@redhat.com>
|
|
|
|
+
|
|
|
|
* 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 <jan.kratochvil@redhat.com>
|
|
|
|
+
|
|
|
|
+ * gdb.texinfo (Threads): Describe -ascending for thread apply all.
|
|
|
|
+
|
|
|
|
2015-01-16 Eli Zaretskii <eliz@gnu.org>
|
|
|
|
|
|
|
|
* 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] <command>\n\
|
|
|
|
+-ascending: Call <command> 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\
|