* 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.
When plugin isn't active or there is no thing more to claim, we don't
need to call bfd_check_format.
* ldfile.c (ldfile_try_open_bfd): Don't call bfd_check_format
if plugin isn't active or there is no thing more to claim.
There is no need to call bfd_check_format. We should just check format
against bfd_object directly.
* plugin.c (plugin_maybe_claim): Check format against bfd_object
directly.
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.
This patch uses mmap if it is available and works. It also caches the
view buffer for get_view.
* configure.ac: Add AC_FUNC_MMAP.
* config.in: Regenerated.
* configure: Likewise.
* plugin.c: Include <sys/mman.h>.
(MAP_FAILED): New. Defined if not defined.
(PROT_READ): Likewise.
(MAP_PRIVATE): Likewise.
(view_buffer_t): New.
(plugin_input_file_t): Add view_buffer.
(get_view): Try mmap and cache the view buffer.
(plugin_maybe_claim): Initialize view_buffer.
Add a bit of debug output that made things a bit easier for me before.
gdb/
2015-02-06 Pedro Alves <palves@redhat.com>
* linux-thread-db.c (find_new_threads_callback): Add debug output.
gdb/gdbserver/
2015-02-06 Pedro Alves <palves@redhat.com>
* thread-db.c (find_new_threads_callback): Add debug output.
Typing "enable count" by itself crashes GDB. Also, if you omit the
breakpoint number/range, the error message is not very clear:
(gdb) enable count 2
warning: bad breakpoint number at or near ''
(gdb) enable count
Segmentation fault (core dumped)
With this patch, the error messages are slightly more helpful:
(gdb) enable count 2
Argument required (one or more breakpoint numbers).
(gdb) enable count
Argument required (hit count).
gdb/ChangeLog:
PR gdb/15678
* breakpoint.c (map_breakpoint_numbers): Check for empty args
string.
(enable_count_command): Check args for NULL value.
gdb/testsuite/ChangeLog:
PR gdb/15678
* gdb.base/ena-dis-br.exp: Test "enable count" for bad user input.
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/testsuite/
2015-02-06 Pedro Alves <palves@redhat.com>
* 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.
PR binutils/17512
* dwarf.c (display_debug_frames): Fix range checks to work on
32-bit binaries complied on a 64-bit host.
* peXXigen.c (rsrc_print_resource_entries): Add range check for
addresses that wrap around the address space.
(rsrc_parse_entry): Likewise.
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/testsuite/
2015-02-06 Pedro Alves <palves@redhat.com>
* 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.
While actually starting to use that new directive, I noticed a few
oversights of the original commit.
gas/
2015-02-06 Jan Beulich <jbeulich@suse.com>
* 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.
This patch closes fd only if fd != -1.
* plugin.c (release_input_file): Set fd to -1 after closing it.
(plugin_maybe_claim): Close fd only if fd != -1.
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.
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.
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 <donb@codesourcery.com>
* 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.
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’)
gdb/ChangeLog
2015-02-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* python/python-internal.h (Py_hash_t): Define it for Python <3.2.
* python/py-value.c (valpy_fetch_lazy): Use it. Remove cast to the
return type.
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).
gdb/gdbserver/ChangeLog:
2015-02-04 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Don't resume LWPs here.
(resume_stopped_resumed_lwps): New function.
(linux_wait_for_event_filtered): Use it.
gdb/ChangeLog:
2015-02-04 Pedro Alves <palves@redhat.com>
* linux-nat.c (handle_extended_wait): Don't resume LWPs here.
(wait_lwp): Don't call wait_lwp if linux_handle_extended_wait
returns true.
(resume_stopped_resumed_lwps): Don't check whether the thread is
marked as executing.
(linux_nat_wait_1): Use resume_stopped_resumed_lwps.
2015-02-04 Peter Collingbourne <pcc@google.com>
* plugin.cc (Pluginobj::get_symbol_resolution_info): Resolve
forwarding symbols when computing symbol resolution info for plugins.
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
testsuite/
2015-02-04 Pedro Alves <palves@redhat.com>
* boards/native-extended-gdbserver.exp: Remove any target variant
specifications from the board name before clearing the isremote
flag from board_info.
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.
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.
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.
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, or 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.
PR binutils/17531
* dwarf.c (read_and_display_attr_value): Test for a block length
being so long that it wraps around to before the start of the block.
(process_debug_info): Test for section_begin wrapping around to
before the start of the section.
(display_gdb_index): Test for num_cus being so large that the end
address wraps around to before the start of the section.
(process_cu_tu_index): Test for j being so large that the section
index pool wraps around to before the start of the section.
commit 70b66289 (Simplify event-loop core, remove two-step event
processing) causes a build failure when compiling GDB with gcc/-O2:
gdb/event-loop.c: In function ‘gdb_do_one_event’:
gdb/event-loop.c:296:10: error: ‘res’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
if (res > 0)
^
GCC isn't realizing that event_source_head can never be > 2 and that
therefore 'res' is always initialized in all possible paths. Adding a
default case that internal_error's makes GCC realize that.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-02-04 Pedro Alves <palves@redhat.com>
Fix build breakage.
* event-loop.c (gdb_do_one_event): Add default switch case.
When an LTO linker plugin claims an external member of a thin archive, gold
does not properly unlock the file and make its file descriptor available for
reuse. This patch fixes the problem by modifying Archive::include_member to
unlock the object file via an RAII class instance, ensuring that it will be
unlocked no matter what path is taken through the function.
gold/
PR gold/15660
* archive.cc (Thin_archive_object_unlocker): New class.
(Archive::include_member): Unlock external members of thin archives.
* testsuite/Makefile.am (plugin_test_1): Rename .syms files.
(plugin_test_2): Likewise.
(plugin_test_3): Likewise.
(plugin_test_4): Likewise.
(plugin_test_5): Likewise.
(plugin_test_6): Likewise.
(plugin_test_7): Likewise.
(plugin_test_8): Likewise.
(plugin_test_9): Likewise.
(plugin_test_10): Likewise.
(plugin_test_11): New test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/plugin_test.c (claim_file_hook): Check for parallel .syms
file to decide whether to claim file.
(all_symbols_read_hook): Likewise.
* testsuite/plugin_test_1.sh: Adjust expected output.
* testsuite/plugin_test_2.sh: Likewise.
* testsuite/plugin_test_3.sh: Likewise.
* testsuite/plugin_test_6.sh: Likewise.
* testsuite/plugin_test_tls.sh: Likewise.
* testsuite/plugin_test_11.sh: New testcase.
