Eli Zaretskii [Sat, 21 Mar 2015 08:48:34 +0000 (10:48 +0200)]
Fix undefined behavior in TUI's TAB expansion
gdb/ChangeLog:
* tui/tui-io.c (tui_expand_tabs): Reinitialize the column counter
before the second loop, to avoid undefined behavior. Reported by
Anton Blanchard <anton@samba.org>.
David Taylor [Thu, 19 Feb 2015 14:53:50 +0000 (18:53 +0400)]
[gdb/ax] small "setv" fix and documentation's adjustment.
gdb/doc/agentexpr.texi documents the "setv" opcode as follow:
@item @code{setv} (0x2d) @var{n}: @result{} @var{v}
Set trace state variable number @var{n} to the value found on the top
of the stack. The stack is unchanged, so that the value is readily
available if the assignment is part of a larger expression. The
handling of @var{n} is as described for @code{getv}.
The @item line is incorrect (and does not match with its
description), so this patch fixes it.
Additionally, in gdb/common/ax.def we find the line:
DEFOP (setv, 2, 0, 0, 1, 0x2d)
From the comment earlier in the file:
Each line is of the form:
DEFOP (name, size, data_size, consumed, produced, opcode)
[...]
CONSUMED is the number of stack elements consumed.
PRODUCED is the number of stack elements produced.
which is saying that nothing is consumed and one item is produced.
Both should be 0 or both should be 1.
This patch sets them both to 1, which seems better since if nothing
is on the stack an error will occur.
gdb/ChangeLog:
* common/ax.def (setv): Fix consumed entry in setv DEFOP.
gdb/doc/ChangeLog:
* agentexpr.texi (Bytecode Descriptions): Fix summary line for setv.
Andreas Arnez [Wed, 14 Jan 2015 12:01:38 +0000 (12:01 +0000)]
Fix internal error when core file section is too big
As reported in PR 17808, a test case with a forged (invalid) core file
can crash GDB with an assertion failure. In that particular case the
prstatus of an i386 core file looks like that from an AMD64 core file.
Consequently the respective regset supply function i386_supply_gregset
is invoked with a larger buffer than usual. But i386_supply_gregset
asserts a specific buffer size, and this assertion fails.
The patch relaxes all buffer size assertions in regset supply
functions such that they merely check for a sufficiently large buffer.
For consistency the regset collect functions are adjusted as well.
gdb/ChangeLog:
PR corefiles/17808:
* gdbarch.sh (iterate_over_regset_sections_cb): Document this
function type, particularly its SIZE parameter.
* gdbarch.h: Regenerate.
* amd64-tdep.c (amd64_supply_fpregset): In gdb_assert, compare
actual against required size using ">=" instead of "==".
(amd64_collect_fpregset): Likewise.
* i386-tdep.c (i386_supply_gregset): Likewise.
(i386_collect_gregset): Likewise.
(i386_supply_fpregset): Likewise.
(i386_collect_fpregset): Likewise.
* mips-linux-tdep.c (mips_supply_gregset_wrapper): Likewise.
(mips_fill_gregset_wrapper): Likewise.
(mips_supply_fpregset_wrapper): Likewise.
(mips_fill_fpregset_wrapper): Likewise.
(mips64_supply_gregset_wrapper): Likewise.
(mips64_fill_gregset_wrapper): Likewise.
(mips64_supply_fpregset_wrapper): Likewise.
(mips64_fill_fpregset_wrapper): Likewise.
* mn10300-linux-tdep.c (am33_supply_gregset_method): Likewise.
(am33_supply_fpregset_method): Likewise.
(am33_collect_gregset_method): Likewise.
(am33_collect_fpregset_method): Likewise.
Even with the previous patch installed, we'll still see
sigall-reverse.exp occasionally fail. The problem is that the event
loop's event handling processing is done in two steps:
#1 - poll all event sources, and push new event objects to the event
queue, until all event sources are drained.
#2 - go through the event queue, processing each event object at a
time. For each event, call the associated callback, and deletes the
event object from the queue.
and then bad things happen if between #1 and #2 something decides that
events from an event source that has already queued events shouldn't
be processed yet. To do that, we either remove the event source from
the list of event sources, or clear its "have events" flag. However,
if an event for that source has meanwhile already been pushed in the
event queue, #2 will still process it and call the associated
callback...
One way to fix it that I considered was to do something to the event
objects already in the event queue when an event source is no longer
interesting. But then I couldn't find any good reason for the
two-step process in the first place. It's much simpler (and less
code) to call the event source callbacks as we poll the sources and
find events.
Tested on x86-64 Fedora 20, native and gdbserver.
gdb/
2015-02-17 Pedro Alves <palves@redhat.com>
* event-loop.c: Don't declare nor define a queue type for
gdb_event_p.
(event_queue): Delete.
(create_event, create_file_event, gdb_event_xfree)
(initialize_event_loop, process_event): Delete.
(gdb_do_one_event): Return as soon as one event is handled.
(handle_file_event): Change prototype. Used the passed in
file_handler pointer and ready_mask instead of looping over all
file handlers.
(gdb_wait_for_event): Update the poll/select timeouts before
blocking. Run event handlers directly instead of queueing events.
Return as soon as one event is handled.
(struct async_event_handler_data): Delete.
(invoke_async_event_handler): Delete.
(check_async_event_handlers): Change return type to int. Run
event handlers directly instead of queueing events. Return as
soon as one event is handled.
(handle_timer_event): Delete.
(update_wait_timeout): New function, factored out from
poll_timers.
(poll_timers): Reimplement.
* event-loop.h (initialize_event_loop): Delete declaration.
* top.c (gdb_init): Don't call initialize_event_loop.
Pedro Alves [Tue, 17 Feb 2015 11:36:54 +0000 (11:36 +0000)]
When disabling target async, remove all target event sources from the event loop
The sigall-reverse.exp test occasionally fails with something like this:
(gdb) PASS: gdb.reverse/sigall-reverse.exp: send signal TERM
continue
Continuing.
The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?([y] or n) FAIL: gdb.reverse/sigall-reverse.exp: continue to signal exit (timeout)
FAIL: gdb.reverse/sigall-reverse.exp: reverse to handler of TERM (timeout)
FAIL: gdb.reverse/sigall-reverse.exp: reverse to gen_TERM (timeout)
This is another event-loop/async related problem exposed by the patch
that made 'query' use gdb_readline_wrapper (588dcc3edbde19f9).
The problem is that even though gdb_readline_wrapper disables
target-async while the secondary prompt is in progress, the record
target's async event source is left marked. So when
gdb_readline_wrapper nests an event loop to process input, it may
happen that that event loop ends up processing a target event while
GDB is not really ready for it. Here's the relevant part of the
backtrace showing the root issue in action:
...
#14 0x000000000061cb48 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:4158
#15 0x0000000000642917 in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:57
#16 0x000000000077ca5c in record_full_async_inferior_event_handler (data=0x0) at src/gdb/record-full.c:791
#17 0x0000000000640fdf in invoke_async_event_handler (data=...) at src/gdb/event-loop.c:1067
#18 0x000000000063fb01 in process_event () at src/gdb/event-loop.c:339
#19 0x000000000063fb2a in gdb_do_one_event () at src/gdb/event-loop.c:360
#20 0x000000000074d607 in gdb_readline_wrapper (prompt=0x3588f40 "The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?([y] or n) ") at src/gdb/top.c:842
#21 0x0000000000750bd9 in defaulted_query (ctlstr=0x8c6588 "The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?", defchar=121 'y', args=0x7fff70524410) at src/gdb/utils.c:1279
#22 0x0000000000750e4c in yquery (ctlstr=0x8c6588 "The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?") at src/gdb/utils.c:1358
#23 0x00000000004b020e in record_linux_system_call (syscall=gdb_sys_exit_group, regcache=0x3529450, tdep=0xd6c840 <amd64_linux_record_tdep>) at src/gdb/linux-record.c:1933
With my all-stop-on-top-of-non-stop series, I'm also seeing
gdb.server/ext-attach.exp fail occasionally due to the same issue.
The first part of the fix is for target_async implementations to make
sure to remove/unmark all target-related event sources from the event
loop.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2015-02-17 Pedro Alves <palves@redhat.com>
* event-loop.c (clear_async_event_handler): New function.
* event-loop.h (clear_async_event_handler): New declaration.
* record-btrace.c (record_btrace_async): New function.
(init_record_btrace_ops): Install record_btrace_async.
* record-full.c (record_full_async): New function.
(record_full_resume): Don't mark the async event source here.
(init_record_full_ops): Install record_full_async.
(record_full_core_resume): Don't mark the async event source here.
(init_record_full_core_ops): Install record_full_async.
* remote.c (remote_async): Mark and clear the async stop reply
queue event-loop token as appropriate.
Pedro Alves [Tue, 17 Feb 2015 11:36:53 +0000 (11:36 +0000)]
Fix up some target is-async vs can-async confusions
In all these cases we're interested in whether the target is currently
async, with its event sources installed in the event loop, not whether
it can async if needed. Also, I'm not seeing the point of the
target_async call from within linux_nat_wait. That's normally done on
resume instead, which this target already does.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2015-02-17 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_child_follow_fork, linux_nat_wait_1): Use
target_is_async_p instead of target_can_async.
(linux_nat_wait): Use target_is_async_p instead of
target_can_async. Don't enable async here.
* remote.c (interrupt_query, remote_wait, putpkt_binary): Use
target_is_async_p instead of target_can_async.
Jan Kratochvil [Wed, 11 Feb 2015 13:45:17 +0000 (14:45 +0100)]
framefilter quit: Make it exception safe
gdb/ChangeLog
2015-02-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* python/py-framefilter.c (py_print_frame): Mention RETURN_QUIT in
function comment. Wrap all function that can throw in cleanups.
(gdbpy_apply_frame_filter): Wrap all function that can throw in
cleanups.
Jan Kratochvil [Wed, 11 Feb 2015 13:42:22 +0000 (14:42 +0100)]
framefilter quit: Code cleanup: Avoid gotos
goto error patters are sometimes AFAIK used in C for the cases like:
int retval=-1;
if (!(a=malloc())) goto error;
if (!(b=malloc())) goto error_a;
if (!(c=malloc())) goto error_b;
retval=0;
error_c: free(c);
error_b: free(b);
error_a: free(a);
error: return retval;
But here there is single error label with one do_cleanups() which I do not find
it worth the goto complication. Without goto one can then furher merge code in
the exit paths in the next patches and ... after all it is all the same, just
without a goto.
gdb/ChangeLog
2015-02-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* python/py-framefilter.c (py_print_frame): Substitute goto error.
Remove the error label.
Jan Kratochvil [Wed, 11 Feb 2015 13:38:56 +0000 (14:38 +0100)]
framefilter quit: Code cleanup: Reindentation
Nothing significant but I find code more clear with less deep indentation.
gdb/ChangeLog
2015-02-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* python/py-framefilter.c (py_print_frame): Put conditional code paths
with goto first, indent the former else codepath left. Put variable
'elided' to a new inner block.
Doug Evans [Wed, 4 Feb 2015 12:04:30 +0000 (13:04 +0100)]
Speed up GDB's TUI output
In the TUI mode, we call wrefresh after outputting every single
character. This results in the I/O becoming very slow. Fix this by
delaying refreshing the console window until an explicit flush of
gdb_stdout is requested, a write to any other (unbuffered) file is
done.
2015-02-04 Doug Evans <dje@google.com>
Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
PR tui/17810
* tui/tui-command.c (tui_refresh_cmd_win): New function.
* tui/tui-command.c (tui_refresh_cmd_win): Declare.
* tui/tui-file.c: #include tui/tui-command.h.
(tui_file_fputs): Refresh command window if stream is not gdb_stdout.
(tui_file_flush): Refresh command window if stream is gdb_stdout.
* tui/tui-io.c (tui_puts): Remove calls to wrefresh, fflush.
(tui_readline_output): Call tui_refresh_cmd_win.
(print_filename): Likewise.
(tui_rl_display_match_list): Likewise.
Jan Kratochvil [Tue, 3 Feb 2015 17:20:49 +0000 (18:20 +0100)]
compile: Filter out -fpreprocessed
With global system gcc-5.0 if one also installs ccache (needing a different
patch
https://bugzilla.samba.org/show_bug.cgi?id=11060
for -fplugin=libcc1plugin) it breaks as GDB will read from inferior
DW_AT_producer containing -fpreprocessed (due to ccache used to compile the
inferior).
<c> DW_AT_producer : (indirect string, offset: 0x52): GNU C11 5.0.0 20150114 (Red Hat 5.0.0-0.1) -fpreprocessed -mtune=generic -
march=x86-64 -g
It is wrong that gcc puts -fpreprocessed into DW_AT_producer - fixed it in
trunk GCCs:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01495.html
But even with that fix there are already built inferiors out there which GDB
could be compatible (for the 'compile' mode) with.
gdb/ChangeLog
2015-02-03 Jan Kratochvil <jan.kratochvil@redhat.com>
Filter out inferior gcc option -fpreprocessed.
* compile/compile.c (filter_args): New function.
(get_args): Use it.
Joel Brobecker [Mon, 2 Feb 2015 03:28:12 +0000 (07:28 +0400)]
[Ada] Do not re-cache symbol-lookup result found from cache lookup.
When ada-lang.c:ada_lookup_symbol_list_worker finds a match in
the symbol cache, it caches the result again, which is unecessary.
This patch fixes the code to avoid that.
gdb/ChangeLog:
PR gdb/17856:
* ada-lang.c (ada_lookup_symbol_list_worker): Do not re-cache
results found in the cache.
Joel Brobecker [Mon, 2 Feb 2015 03:20:58 +0000 (07:20 +0400)]
[Ada] pspace_data->sym_cache is always NULL
The Ada symbol cache has been designed to have one instance of that
of that cache per program space, and for each instance to be created
on-demand. ada_get_symbol_cache is the function responsible for both
lookup and creation on demand.
Unfortunately, ada_get_symbol_cache forgot to store the reference
to newly created caches, thus causing it to:
- Leak old caches;
- Allocate a new cache each time the cache is being searched or
a new entry is to be inserted.
This patch fixes the issue by avoiding the use of the local variable,
which indirectly allowed the bug to happen. We manipulate the reference
in the program-space data instead.
gdb/ChangeLog:
PR gdb/17854:
* ada-lang.c (ada_get_symbol_cache): Set pspace_data->sym_cache
when allocating a new one.
Eli Zaretskii [Sat, 31 Jan 2015 08:47:14 +0000 (10:47 +0200)]
Make sure TABs are expanded in TUI windows on MS-Windows.
gdb/
2015-01-31 Eli Zaretskii <eliz@gnu.org>
* tui/tui-io.c (tui_expand_tabs): New function.
(tui_puts, tui_redisplay_readline): Expand TABs into the
appropriate number of spaces.
* tui/tui-regs.c: Include tui-io.h.
(tui_register_format): Call tui_expand_tabs to expand TABs into
the appropriate number of spaces.
* tui/tui-io.h: Add prototype for tui_expand_tabs.
projects / thirdparty / binutils-gdb.git / log
