Nick Clifton [Wed, 11 Feb 2015 14:36:39 +0000 (14:36 +0000)]
Fixes a problem with the RL78 disassembler which would incorrectly disassemble [HL+0] as [HL].
* rl78-decode.opc: Add 'a' attribute to instructions that support
[HL+0] addressing.
* rl78-decode.c: Regenerate.
* rl78-dis.c (print_insn_rl78): Display the offset in [HL+0]
addresses.
* 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:40:14 +0000 (14:40 +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.
* 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.
Nick Clifton [Wed, 11 Feb 2015 13:05:04 +0000 (13:05 +0000)]
Fixes for invalid memory accesses triggered by running readelf on fuzzed binaries.
PR binutils/17531
* dwarf.c (display_debug_pubnames_worker): Work around compiler
bug checking address ranges.
(display_debug_frames): Likewise.
(display_gdb_index): Likewise.
(process_cu_tu_index): Add range check on the ncols value.
H.J. Lu [Wed, 11 Feb 2015 13:01:03 +0000 (05:01 -0800)]
Merge linker plugin handling into BFD plugin support
Linker plugin_maybe_claim is the interface of linker plugin support.
This patch extracts linker plugin_maybe_claim into plugin_object_p and
makes it available to BFD via a new function:
bfd_plugin_object_p calls plugin_object_p registered by linker first. It
adds an enum bfd_plugin_format field and a pointer to plugin dummy BFD so
that plugin_object_p stores plugin dummy BFD to allow plugin_maybe_claim
to retrieve it later.
bfd/
PR ld/17878
* bfd.c (bfd_plugin_format): New.
(bfd): Add plugin_format and plugin_dummy_bfd.
* plugin.c (try_load_plugin): Take a pointer to bfd_boolean
argument to return TRUE if any plugin is found. Set plugin_format.
(has_plugin): New.
(bfd_plugin_target_p): New.
(bfd_plugin_specified_p): Likewise.
(bfd_plugin_target_p): Likewise.
(register_ld_plugin_object_p): Likewise.
(bfd_plugin_set_plugin): Set has_plugin.
(load_plugin): Cache try_load_plugin result.
(bfd_plugin_object_p): Try ld_plugin_object_p first. Check
plugin_format.
* plugin.h (bfd_plugin_target_p): New.
(bfd_plugin_specified_p): Likewise.
(register_ld_plugin_object_p): Likewise.
* bfd-in2.h: Regenerated.
ld/
PR ld/17878
* plugin.c: Include ../bfd/plugin.h.
(plugin_get_ir_dummy_bfd): Call bfd_create with
link_info.output_bfd instead of srctemplate. Copy BFD info
from srctemplate only if it doesn't use BFD plugin target
vector.
(plugin_load_plugins): Call register_ld_plugin_object_p with
(plugin_object_p)
(plugin_maybe_claim): Renamed to ...
(plugin_object_p): This. Return dummy BFD target vector if
input is calimed by plugin library, otherwise return NULL.
Update plugin_format and plugin_dummy_bfd.
(plugin_maybe_claim): New. Use plugin_object_p.
Tom Tromey [Wed, 11 Feb 2015 11:20:21 +0000 (11:20 +0000)]
Fix redefinition errors in C++ mode
In C, we can forward declare static structure instances. That doesn't
work in C++ though. C++ treats these as definitions. So then the
compiler complains about symbol redefinition, like:
src/gdb/elfread.c:1569:29: error: redefinition of ‘const sym_fns elf_sym_fns_lazy_psyms’
src/gdb/elfread.c:53:29: error: ‘const sym_fns elf_sym_fns_lazy_psyms’ previously declared here
The intent of static here is naturally to avoid making these objects
visible outside the compilation unit. The equivalent in C++ would be
to instead define the objects in the anonymous namespace. But given
that it's desirable to leave the codebase compiling as both C and C++
for a while, this just makes the objects extern.
(base_breakpoint_ops is already declared in breakpoint.h, so we can
just remove the forward declare from breakpoint.c)
Pedro Alves [Wed, 11 Feb 2015 09:45:41 +0000 (09:45 +0000)]
Fix adjust_pc_after_break, remove still current thread check
On decr_pc_after_break targets, GDB adjusts the PC incorrectly if a
background single-step stops somewhere where PC-$decr_pc has a
breakpoint, and the thread that finishes the step is not the current
thread, like:
ADDR1 nop <-- breakpoint here
ADDR2 jmp PC
IOW, say thread A is stepping ADDR2's line in the background (an
infinite loop), and the user switches focus to thread B. GDB's
adjust_pc_after_break logic confuses the single-step stop of thread A
for a hit of the breakpoint at ADDR1, and thus adjusts thread A's PC
to point at ADDR1 when it should not, and reports a breakpoint hit,
when thread A did not execute the instruction at ADDR1 at all.
The test added by this patch exercises exactly that.
I can't find any reason we'd need the "thread to be examined is still
the current thread" condition in adjust_pc_after_break, at least
nowadays; it might have made sense in the past. Best just remove it,
and rely on currently_stepping().
Here's the test's log of a run with an unpatched GDB:
35 while (1);
(gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next over nop
next&
(gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next& over inf loop
thread 1
[Switching to thread 1 (Thread 0x7ffff7fc2740 (LWP 29027))](running)
(gdb)
PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: switch to main thread
Breakpoint 2, thread_function (arg=0x0) at ...src/gdb/testsuite/gdb.threads/step-bg-decr-pc-switch-thread.c:34
34 NOP; /* set breakpoint here */
FAIL: gdb.threads/step-bg-decr-pc-switch-thread.exp: no output while stepping
H.J. Lu [Wed, 11 Feb 2015 01:01:17 +0000 (17:01 -0800)]
Unmap the buffer if plugin didn't claim the file
If plugin didn't claim the file, unmap the buffer.
* plugin.c (plugin_input_file_t): Add use_mmap.
(plugin_pagesize): New.
(get_view): Use plugin_pagesize. Set use_mmap if mmap is used.
(plugin_load_plugins): Initialize plugin_pagesize.
(plugin_maybe_claim): Unmap the buffer if plugin didn't claim the
file.
Patrick Palka [Tue, 10 Feb 2015 23:45:10 +0000 (18:45 -0500)]
Fix a pair of screen-resizing issues in TUI
This patch fixes a pair of TUI issues related to screen resizing:
1. In tui_handle_resize_during_io(), when the TUI screen gets resized,
we fail to update GDB's idea about the height of the output window.
You can see this bug by doing:
a. Enter TUI mode.
b. "show height"
c. Resize the terminal.
d. "show height"
And observe that despite resizing the terminal, the reported height
remains unchanged. Note that a similar issue exists in the CLI.
The fix for this is simple: call tui_update_gdb_sizes() after performing
a resize, so that the "height" variable remains consistent with the
height of TUI's output window.
2. In tui_enable(), the call to tui_update_gdb_sizes() may clobber
readline's idea of the actual screen dimensions, and a subsequent
pending resize will use bogus terminal dimensions.
You can see this bug by doing:
a. Enter TUI mode.
b. Exit TUI mode.
c. Resize the terminal.
d. Enter TUI mode.
e. Press a key to resize the screen.
And observe that the terminal gets incorrectly resized to the wrong
dimensions. To fix this issue, we should oppurtunistically resize the
screen in tui_enable(). That way we eliminate the possibility of a
pending resize triggering right after we call tui_update_gdb_sizes().
gdb/ChangeLog:
* tui/tui-io.c (tui_handle_resize_during_io): Call
tui_update_gdb_sizes() after resizing the screen.
* tui/tui.c (tui_enable): Resize the terminal before
calling tui_update_gdb_sizes().
Patrick Palka [Tue, 10 Feb 2015 23:44:56 +0000 (18:44 -0500)]
Fix truncation of TUI command history
If we submit a command while the prompt cursor is somewhere other than
at the end of the command line, the command line gets truncated as the
command window gets shifted one line up. This happens because we fail
to properly move the cursor to the end of the command line before
transmitting the newline to ncurses. We need to move the cursor because
when ncurses outputs a newline it truncates any text that appears
past the end of the cursor.
The fix is generic enough to work properly even in multi-line secondary
prompts like the quit prompt.
gdb/ChangeLog:
* tui/tui-io.c (tui_getc): Move cursor to the end of the command
line before printing a newline.
Pedro Alves [Mon, 26 Jan 2015 17:52:28 +0000 (17:52 +0000)]
Add "signal SIGTRAP" test
Some local changes I was working on related to SIGTRAP handling
resulted in "signal SIGTRAP" no longer passing the SIGTRAP to the
inferior.
Surprisingly, only annota1.exp catches this. This commit adds a test
that doesn't rely on annotations, so that at the point annotations are
finaly dropped, we still have this use case covered ...
This is a multi-threaded test to also exercise the case of first
needing to do a step-over before delivering the signal.
Tested on x86_64 Fedora 20, native, remote/extended-remote gdbserver.
Pedro Alves [Tue, 10 Feb 2015 19:13:31 +0000 (19:13 +0000)]
displaced_step_fixup may access memory from the wrong inferior/thread
displaced_step_fixup takes an thread to work with, as argument. OTOH,
gdbarch_displaced_step_fixup fixes up the current thread. The former
calls the latter without making sure the current thread is the one
that was passed in. If it is not, then gdbarch_displaced_step_fixup
may e.g., try reading from a running thread, which doesn't work on
some targets, or worse, read memory from the wrong inferior and
succeed.
This is mostly a latent problem currently, as non-stop switches the
current thread to the event thread early in fetch_inferior_event.
Antoine Tremblay [Mon, 26 Jan 2015 18:08:53 +0000 (13:08 -0500)]
gdbserver: Fix crash when QTinit is handled with no inferior process attached
When gdbserver is called with --multi and attach has not been called yet
and tstart is called on the gdb client, gdbserver would crash.
This patch fixes gdbserver so that it returns E01 to the gdb client.
Also this patch adds a testcase to verify this bug named no-attach-trace.exp
gdb/gdbserver/ChangeLog:
PR breakpoints/15956
* tracepoint.c (cmd_qtinit): Add check for current_thread.
gdb/testsuite/ChangeLog:
* gdb.trace/no-attach-trace.c: New file.
* gdb.trace/no-attach-trace.exp: New file.
Simon Marchi [Tue, 10 Feb 2015 15:46:12 +0000 (10:46 -0500)]
Finish constification of varobj interface
This completes the constification of the struct varobj pointers in the
lang_varobj_ops interface partially done in b09e2c591f9221d865bfe8425990a6bf9fab24e3. As suggested by Pedro,
varobj_get_path_expr casts away the const to assign the "mutable" struct
member.
gdb/ChangeLog:
* ada-varobj.c (ada_name_of_child): Constify parent.
(ada_path_expr_of_child): Same.
(ada_value_of_child): Same.
(ada_type_of_child): Same.
* c-varobj.c (c_is_path_expr_parent): Same.
(c_describe_child): Same.
(c_name_of_child): Same.
(c_value_of_child): Same.
(c_type_of_child): Same.
(cplus_number_of_children): Same.
(cplus_describe_child): Constify var.
(cplus_name_of_child): Constify parent.
(cplus_value_of_child): Same.
(cplus_type_of_child): Same.
* jv-varobj.c (java_name_of_child): Same.
(java_value_of_child): Same.
(java_type_of_child): Same.
* varobj.c (value_of_child): Same.
(varobj_default_is_path_expr_parent): Constify var, parent and return
value.
(varobj_get_path_expr): Constify var, modify path_expr through
mutable_var.
(install_new_value): Constify parent.
(value_of_child): Constify parent.
* varobj.h (struct varobj): Constify parent.
(struct lang_varobj_ops): Constify name_of_child, value_of_child and
type_of_child.
(varobj_get_path_expr): Constify var.
(varobj_get_path_expr_parent): Constify var and return value.
Nick Clifton [Tue, 10 Feb 2015 17:53:53 +0000 (17:53 +0000)]
Fix memory access violations discovered by running readelf compiled with undefined memory access sanitization on fuzzed binaries.
PR binutils/17531
* dwarf.c (display_debug_pubnames_worker): Use dwarf_vma type for
offset.
* readelf.c (dump_relocations): Handle printing offsets which are
MIN_INT.
(process_corefile_note_segment): Add range check of the namesz
field.
Nick Clifton [Tue, 10 Feb 2015 17:13:31 +0000 (17:13 +0000)]
Fixes for memory access violations triggered by running readelf on fuzzed binaries.
PR binutils/17531
* dwarf.c (process_debug_info): Zero the debug information array
since correct initialisation cannot be relied upon.
(process_cu_tu_index): Improve range checks.
Nick Clifton [Tue, 10 Feb 2015 14:11:00 +0000 (14:11 +0000)]
Fix memory access violations triggered by running objdump compiled with out-of-bounds sanitization checking.
PR binutils/17512
* dwarf.c (eh_addr_size): Use an unsigned type.
(size_of_encoded_value): Return an unsigned type.
(read_leb128): Break if the shift becomes too big.
(process_extended_line_op): Do not read the address if the length
is too long.
(read_cie): Warn and fail if the pointer size or segment size are
too big.
* dwarf.h (DWARF2_External_LineInfo): Delete unused and incorrect
structure definition.
(DWARF2_External_PubNames): Likewise.
(DWARF2_External_CompUnit): Likewise.
(DWARF2_External_ARange): Likewise.
(DWARF2_Internal_LineInfo): Use dwarf_vma type for
li_prologue_length.
(eh_addr_size): Update prototype.
* coffcode.h (styp_to_sec_flags): Use an unsigned long type to
hold the flag bits.
* peXXigen.c (pe_print_reloc): Use unsigned types to hold the
size and number of relocs.
(pe_print_debugdata): Use a 32-bit aligned buffer to store the
codeview record.
* versados.c (process_otr): Check the esdid value before using it
to access the EDATA.
* arm-tdep.c (arm_prologue_unwind_stop_reason): New function.
(arm_prologue_this_id): Move PC and SP limit checks to
arm_prologue_unwind_stop_reason.
(arm_prologue_unwind) <stop_reason> : Set to
arm_prologue_unwind_stop_reason.
Mark Wielaard [Mon, 9 Feb 2015 22:14:38 +0000 (23:14 +0100)]
Recognize new DWARF5/GCC5 DW_LANG Fortran 2003 and Fortran 2008 standards.
DWARFv5 defines and GCC5 may output two new DW_LANG constants for the
Fortran 2003 and Fortran 2008 standards. Recognize both as variants of
language_fortran.
gdb/ChangeLog:
* dwarf2read.c (set_cu_language): Recognize DW_LANG_Fortran03 and
DW_LANG_Fortran08 as language_fortran.
PR remote/17946: Fix wrong comparison of pointer against char
We were comparing a pointer against a char on remote.c. 'dcb' filed a
bug to inform us about that. I pushed the following patch under the
obvious rule.
Markus Metzger [Thu, 30 Jan 2014 08:51:10 +0000 (09:51 +0100)]
record-btrace: indicate gaps
Indicate gaps in the trace due to decode errors. Internally, a gap is
represented as a btrace function segment without instructions and with a
non-zero format-specific error code.
Show the gap when traversing the instruction or function call history.
Also indicate gaps in "info record".
It looks like this:
(gdb) info record
Active record target: record-btrace
Recording format: Branch Trace Store.
Buffer size: 64KB.
Recorded 32 instructions in 5 functions (1 gaps) for thread 1 (process 7182).
(gdb) record function-call-history /cli
1 fib inst 1,9 at src/fib.c:9,14
2 fib inst 10,20 at src/fib.c:6,14
3 [decode error (1): instruction overflow]
4 fib inst 21,28 at src/fib.c:11,14
5 fib inst 29,33 at src/fib.c:6,9
(gdb) record instruction-history 20,22
20 0x000000000040062f <fib+47>: sub $0x1,%rax
[decode error (1): instruction overflow]
21 0x0000000000400613 <fib+19>: add $0x1,%rax
22 0x0000000000400617 <fib+23>: mov %rax,0x200a3a(%rip)
(gdb)
Gaps are ignored during reverse execution and replay.
* btrace.c (ftrace_find_call): Skip gaps.
(ftrace_new_function): Initialize level.
(ftrace_new_call, ftrace_new_tailcall, ftrace_new_return)
(ftrace_new_switch): Update
level computation.
(ftrace_new_gap): New.
(ftrace_update_function): Create new function after gap.
(btrace_compute_ftrace_bts): Create gap on error.
(btrace_stitch_bts): Update parameters. Clear trace if it
becomes empty.
(btrace_stitch_trace): Update parameters. Update callers.
(btrace_clear): Reset the number of gaps.
(btrace_insn_get): Return NULL if the iterator points to a gap.
(btrace_insn_number): Return zero if the iterator points to a gap.
(btrace_insn_end): Allow gaps at the end.
(btrace_insn_next, btrace_insn_prev, btrace_insn_cmp): Handle gaps.
(btrace_find_insn_by_number): Assert that the found iterator does
not point to a gap.
(btrace_call_next, btrace_call_prev): Assert that the last function
is not a gap.
* btrace.h (btrace_bts_error): New.
(btrace_function): Update comment.
(btrace_function) <insn, insn_offset, number>: Update comment.
(btrace_function) <errcode>: New.
(btrace_thread_info) <ngaps>: New.
(btrace_thread_info) <replay>: Update comment.
(btrace_insn_get): Update comment.
* record-btrace.c (btrace_ui_out_decode_error): New.
(record_btrace_info): Print number of gaps.
(btrace_insn_history, btrace_call_history): Call
btrace_ui_out_decode_error for gaps.
(record_btrace_step_thread, record_btrace_start_replaying): Skip gaps.
Markus Metzger [Wed, 29 Jan 2014 11:56:09 +0000 (12:56 +0100)]
btrace: extend struct btrace_insn
Add the instruction's size as well as a coarse classification to struct
btrace_insn. Use the information in ftrace_update_function and
ftrace_find_call.
Allow the size of the branch trace ring buffer to be defined by the
user. The specified buffer size will be used when BTS tracing is
enabled for new threads.
The obtained buffer size may differ from the requested size. The
actual buffer size for the current thread is shown in the "info record"
command.
Bigger buffers mean longer traces, but also longer processing time.
Markus Metzger [Thu, 28 Nov 2013 14:44:13 +0000 (15:44 +0100)]
record btrace: add configuration struct
Add a struct to describe the branch trace configuration and use it for
enabling branch tracing.
The user will be able to set configuration fields for each tracing format
to be used for new threads.
The actual configuration that is active for a given thread will be shown
in the "info record" command.
At the moment, the configuration struct only contains a format field
that is set to the only available format.
The format is the only configuration option that can not be set via set
commands. It is given as argument to the "record btrace" command when
starting recording.
Markus Metzger [Fri, 17 Jan 2014 13:40:02 +0000 (14:40 +0100)]
btrace, linux: add perf event buffer abstraction
Collect perf event buffer related fields from btrace_target_info into
a new struct perf_event_buffer. Update functions that operated on the
buffer to take a struct perf_event_buffer pointer rather than a
btrace_target_info pointer.
Markus Metzger [Wed, 13 Nov 2013 14:31:07 +0000 (15:31 +0100)]
btrace: add struct btrace_data
Add a structure to hold the branch trace data and an enum to describe
the format of that data. So far, only BTS is supported. Also added
a NONE format to indicate that no branch trace data is available.
This will make it easier to support different branch trace formats in
the future.
Alan Modra [Thu, 5 Feb 2015 07:00:57 +0000 (17:30 +1030)]
elflink.c whitespace, formatting and a plugin symbol tweak
* elflink.c: Whitespace, formatting fixes.
(elf_link_input_bfd): Clarify comment.
(elf_link_output_extsym): Exclude symbols in linker created
sections when testing for plugin symbols.
H.J. Lu [Sat, 7 Feb 2015 19:01:22 +0000 (11:01 -0800)]
Update plugin_maybe_claim
This patch removes the argument of pointer to struct ld_plugin_input_file.
This is the first step to extract a plugin_object_p out of
plugin_maybe_claim for BFD.
* plugin.c: Include "libbfd.h".
(plugin_strdup): New.
(plugin_maybe_claim): Remove the argument of pointer to struct
ld_plugin_input_file. Open and handle input entry.
* plugin.h (plugin_maybe_claim): Updated.
* ldfile.c (ldfile_try_open_bfd): Call plugin_maybe_claim directly
without passing a pointer to struct ld_plugin_input_file.
* ldmain.c: Don't include "libbfd.h".
(add_archive_element): Call plugin_maybe_claim directly without
passing a pointer to struct ld_plugin_input_file.
H.J. Lu [Sat, 7 Feb 2015 13:28:06 +0000 (05:28 -0800)]
Issue relocation in RO section warning for -z text
This patch changes linker to issue a warning for relocation in readonly
section for -z text.
bfd/
PR ld/17935
* elf32-i386.c (elf_i386_readonly_dynrelocs): Also issue a
warning for relocation in readonly section for -z text.
(elf_i386_size_dynamic_sections): Likewise.
* elf64-x86-64.c (elf_x86_64_readonly_dynrelocs): Likewise.
(elf_x86_64_size_dynamic_sections): Likewise.
ld/testsuite/
PR ld/17935
* ld-i386/i386.exp: Run pr17935-1 and pr17935-2.
* ld-x86-64/x86-64.exp: Likewise.
H.J. Lu [Fri, 6 Feb 2015 12:25:36 +0000 (04:25 -0800)]
Properly mark the plugin symbol undefined
Mark the unused plugin defined symbol in elf_link_input_bfd instead of
_bfd_elf_fix_symbol_flags. Limit the PR ld/12365 test to x86 targets.
bfd/
PR ld/12365
PR ld/14272
* elflink.c (_bfd_elf_fix_symbol_flags): Revert the last change.
(elf_link_input_bfd): Mark the plugin symbol undefined if it is
referenced from a non-IR file.
ld/testsuite/
PR ld/12365
PR ld/14272
* ld-plugin/lto.exp: Run the PR ld/12365 test only for x86 targets.
* ld-plugin/plugin-7.d: Updated.
* ld-plugin/plugin-8.d: Likewise.
The buildbot shows that this test is still racy, and occasionally
fails with time outs on some machines. I'd like to get major issues
with load out of the way.
The test currently exits after 180s, which is just a random number,
that has no relation to what the .exp file considers a time out. This
commit makes the program wait a bit longer than what the .exp file
considers a time out, and, resets the timer for each iteration.
Tested on x86_64 Fedora 20, native and extended-remote gdbserver.
* gdb.threads/attach-many-short-lived-threads.c (SECONDS): New
macro.
(seconds_left, again): New globals.
(main): Wait seconds_left in a 1-second sleep loop instead of
sleeping 180 seconds. If 'again' is set, reset the seconds
counter.
* gdb.threads/attach-many-short-lived-threads.exp (test): Set
'again' in the inferior before detaching. Print the seconds left.
(options): New global.
(top level): Build program with -DTIMEOUT=$timeout.
Pedro Alves [Fri, 6 Feb 2015 10:09:42 +0000 (11:09 +0100)]
gdb.base/gdb-sigterm.exp: Fix spurious FAILs
The buildbot shows that some machines FAIL this test frequently.
E.g.: https://sourceware.org/ml/gdb-testers/2015-q1/msg00997.html
If I stress my machine, I can sometimes see it fail too.
Bumping the 200 limit and tweaking the test to show the step count, I
get:
...
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times
--> FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times <--
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 9 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times
PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times
...
Thinking that this might be a problem of SIGTERM reaching GDB, but
then the event loop taking too long to handle it, I hacked GDB to
print a debug log whenever the SIGTERM handler was called, and,
whenever the event loop finally calls the async SIGTERM handler.
Here's what I see:
infrun: 30011 [Thread 30011],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x4005de
--> infrun: got SIGTERM <--
infrun: stepping inside range [0x4005de-0x4005e0]
infrun: resume (step=1, signal=GDB_SIGNAL_0), ...
infrun: prepare_to_wait
--> infrun: handling async SIGTERM <--
Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
gdb.base/gdb-sigterm.exp: expect eof #27
FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times
So, no delay on the GDB side. It just happens that occasionally it
takes more than 200 single-steps before SIGTERM even reaches GDB.
This just looks like a kernel/scheduling issue --- some extra usage
spike in the system (e.g., an I/O spike) might cause it for me. For
the build slaves, I'm guessing they're frequently busy enough to trip
on this often. Particularly more so now that we're having them run
tests in parallel mode.
The fix is to detect failure by timeout instead of counting single
steps. This should be more reliable. Indeed for me, after this
commit, I couldn't trigger a FAIL anymore, even after letting the test
run for an hour.
By timeout is also nicer in that a board file for a slow host/target
can increase it (like, e.g., an embedded GNU/Linux board).
Tested on x86_64 Fedora 20, native, gdbserver, and extended-remote
gdbserver.
* gdb.base/gdb-sigterm.c (main): Use the TIMEOUT define to
determine how many seconds to pass to 'alarm'.
* gdb.base/gdb-sigterm.exp (top level): Build program with
-DTIMEOUT=$timeout.
(do_test): Return success/failure indication. Add more verbose
logging. Don't fail if 200 single steps are seen. Instead, fail
when the test times out.
(passes): New global.
(top level): Break the testing loop if testing fails on any
iteration. Use gdb_assert.
* dw2gencfi.c (select_cie_for_fde): Also bail on CFI_label.
(cfi_change_reg_numbers): Also do nothing for CFI_label.
(cfi_pseudo_table): Also handle .cfi_label when not supporting
CFI directives.
H.J. Lu [Thu, 5 Feb 2015 13:00:52 +0000 (05:00 -0800)]
Add plugin_input_file_t
This patchs adds plugin_input_file_t to implement get_input_file, get_view
and release_input_file. The maximum memeory overhead per IR input file
are about 40 bytes for plugin_input_file_t plus the memory to store input
IR filename. According to
http://gcc.gnu.org/wiki/whopr/driver
RELEASE_INPUT_FILE: Function pointer to the linker interface that
releases a file descriptor for a claimed input file. The plug-in library
must call this interface for each file descriptor obtained by the "get
input file" interface. It must release all such file descriptors before
returning from the WPA phase.
However, GCC plug-in library doesn't use the "get input file" interface.
It processed the IR input in the claim file handler. Since the the file
descriptor opened for the IR input was unused after the claim file
handler returns and GCC plug-in library before GCC 5 doesn't call the
RELEASE_INPUT_FILE function pointer, ld closed the file descriptor to
avoid leaking file descriptor. But this approach doesn't work with
other plug-in libraries which uses the "get input file", "get view" and
"release input file" interfaces. To avoid file descriptor leak with
GCC prior to GCC 5 and support other plug-in libraries at the same time,
we close the file descriptor only if the input IR file is a bfd_object
file. This scheme doesn't work when a plug-in library needs the file
descriptor and its IR is stored in bfd_object file.
PR ld/17878
* plugin.c: Include <errno.h>.
(errno): New. Declare if needed.
(plugin_input_file_t): New.
(get_input_file): Implemented.
(get_view): Likewise.
(release_input_file): Likewise.
(add_symbols): Updated.
(get_symbols): Likewise.
(plugin_maybe_claim): Allocate a plugin_input_file_t. Close fd
only for a bfd_object input.
Alan Modra [Wed, 4 Feb 2015 22:44:56 +0000 (09:14 +1030)]
Fix msp430 build with gcc-5
gcc-5 correctly complains "loop exit may only be reached after
undefined behavior". I was going to correct this by checking the
index before dereferencing the array rather than the other way around,
but then I noticed it is possible for extract_cmd to write the
terminating zero one past the end of "cmd". Fixing that means no
index check is needed in md_assemble.
* config/tc-msp430.c (md_assemble): Correct size passed to
extract_cmd. Remove index check.
Don Breazeal [Wed, 4 Feb 2015 21:15:06 +0000 (13:15 -0800)]
Clean up System V IPC objects allocated by test.
This commit modifies the test program gdb.base/info-os.c so that
it cleans up all allocated System V IPC objects when a fatal
error occurs. Without this, it was possible for the program
to leave IPC objects on the system, and such objects persist
until they are manually deleted or the system reboots.
I looked at changing the SysV IPC key for allocating the IPC objects to
IPC_PRIVATE. That would prevent errors due to namespace conflicts with the
key. However, the test needs to read the actual key number from the 'info
os' command output, and IPC_PRIVATE won't work for that.
gdb/testsuite/ChangeLog:
2015-02-04 Don Breazeal <[email protected]>
* gdb.base/info-os.c (shmid, semid, msqid): Make variables static
and initialize them.
(ipc_cleanup): New function.
(main): Don't declare shmid, semid, and msqid. Add a call to
atexit so that we call ipc_cleanup on exit.
Jan Kratochvil [Wed, 4 Feb 2015 19:31:17 +0000 (20:31 +0100)]
Fix Python 3 build error on 32-bit hosts
on Fedora Rawhide (==22) i686 using --with-python=/usr/bin/python3 one gets:
./python/py-value.c:1696:3: error: initialization from incompatible pointer type [-Werror]
valpy_hash, /*tp_hash*/
^
./python/py-value.c:1696:3: error: (near initialization for ‘value_object_type.tp_hash’) [-Werror]
cc1: all warnings being treated as errors
Makefile:2628: recipe for target 'py-value.o' failed
This is because in Python 2 tp_hash was:
typedef long (*hashfunc)(PyObject *);
while in Python 3 tp_hash is:
typedef Py_hash_t (*hashfunc)(PyObject *);
Py_hash_t is int for 32-bit hosts and long for 64-bit hosts. While on 32-bit
hosts sizeof(long)==sizeof(int) still the hashfunc type is formally
incompatible. As this patch should have no compiled code change it is not
really necessary for gdb-7.9, it would fix there just this non-fatal
compilation warning:
./python/py-value.c:1696:3: warning: initialization from incompatible pointer type
valpy_hash, /*tp_hash*/
^
./python/py-value.c:1696:3: warning: (near initialization for ‘value_object_type.tp_hash’)
Pedro Alves [Wed, 4 Feb 2015 18:13:28 +0000 (19:13 +0100)]
Linux: don't resume new LWPs until we've pulled all events out of the kernel
Since the starvation avoidance series
(https://sourceware.org/ml/gdb-patches/2014-12/msg00631.html), both
GDB and GDBserver pull all events out of ptrace before deciding which
event to process.
There's one problem with that though. Because we resume new threads
immediately when we see a PTRACE_EVENT_CLONE event, if the program
constantly spawns threads fast enough, new threads can spawn threads
faster we can pull events out of the kernel, and thus we'd get stuck
in an infinite loop, never returning any event to the core to process.
I occasionally see this happen with the
attach-many-short-lived-threads.exp test against gdbserver.
The fix is to delay resuming new threads until we've pulled out all
events out of the kernel.
On native, we already have the resume_stopped_resumed_lwps function
that knows to resume LWPs that are stopped with no event to report to
the core. So the patch just adds another use. GDBserver didn't have
the equivalent yet, so the patch adds one.
Tested on x86_64 Fedora 20, native and gdbserver (remote and
extended-remote).
Running the testsuite with the native-extended-gdbserver.exp board and
passing a variant spec, like
make check RUNTESTFLAGS="--target_board=native-extended-gdbserver/-m32"
results in dejagnu trying to open a rsh connection to
"native-extended-gdbserver", which of course is wrong. The point of
this board is running things locally.
The issue is that the native-extended-gdbserver board does not clear
the "isremote" flag properly.
Reported by Sergio at:
https://sourceware.org/ml/gdb-patches/2015-02/msg00067.html
* boards/native-extended-gdbserver.exp: Remove any target variant
specifications from the board name before clearing the isremote
flag from board_info.
Andreas Arnez [Thu, 15 Jan 2015 10:20:45 +0000 (10:20 +0000)]
Warn if core file register section is larger than expected
When reading a core file register section which is larger than
expected, emit a warning. Assume that a register section usually has
exactly the size specified by the regset section iterator. In some
special cases this assumption is wrong, or at least does not match the
regset supply function's logic. Thus also add a way to suppress the
warning in those cases, using a new flag REGSET_VARIABLE_SIZE.
gdb/ChangeLog:
* regset.h (struct regset): Add flags field.
(REGSET_VARIABLE_SIZE): New value for a regset's flags field.
* corelow.c (get_core_register_section): Add warning if the size
exceeds the requested size and the regset does not have the
REGSET_VARIABLE_SIZE flag set.
* alphanbsd-tdep.c (alphanbsd_gregset): Add REGSET_VARIABLE_SIZE
flag.
* armbsd-tdep.c (armbsd_gregset): Likewise.
* hppa-hpux-tdep.c (hppa_hpux_regset): Likewise.
* hppaobsd-tdep.c (hppaobsd_gregset): Likewise.
* m68kbsd-tdep.c (m68kbsd_gregset): Likewise.
* mipsnbsd-tdep.c (mipsnbsd_gregset): Likewise.
Andreas Arnez [Wed, 14 Jan 2015 17:53:23 +0000 (17:53 +0000)]
x86: Use correct .reg-xstate section size
When reading the XSAVE extended state from an i386 or AMD64 core file,
the respective regset iterator requests a minimum section size of
zero. Since the respective regset supply function does not check the
size either, this may lead to accessing data out of range if the
section is too short.
In write mode, the iterator always uses the maximum supported size for
the XSAVE extended state.
This is now changed such that the iterator always requests the
expected size of this section based on xcr0, both for reading and
writing.
gdb/ChangeLog:
* amd64-linux-tdep.c (amd64_linux_iterate_over_regset_sections):
For ".reg-xstate", explicitly specify the requested section size
via X86_XSTATE_SIZE instead of just 0 on input and
X86_XSTATE_MAX_SIZE on output.
* i386-linux-tdep.c (i386_linux_iterate_over_regset_sections):
Likewise.
projects / binutils.git / log