aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-12-18[GOLD] Tweak keep_text_section_prefix test for PowerPC64 ELFv1Alan Modra3-2/+8
This test checks code layout by function symbol ordering, but that doesn't work on powerpc64 ELFv1 where the function symbol is on a descriptor. A simple work-around is to have nm emit synthetic symbols marking the code entry point of functions. Since the text segment is laid out before the data segment, the synthetic symbols will have lower addresses than function descriptor symbols and be seen first in nm -n output. On other targets, nm --synthetic typically emits symbols on plt entries. Since the testcase doesn't call any of the functions of interest there shouldn't be plt entries for those functions, so there should be no potentially confusing extra symbols. * testsuite/Makefile.am (keep_text_section_prefix_nm.stdout): Pass --synthetic to nm. * testsuite/Makefile.in: Regenerate.
2018-12-18PR23980, assertion failAlan Modra9-7/+55
All of the backend relocate_section functions that interpret reloc numbers assuming the input file is of the expected type (ie. same as output or very similar) really ought to be checking input file type. Not many do, and those that do currently just assert. This patch replaces the assertion with a more graceful exit. PR 23980 * elf32-i386.c (elf_i386_relocate_section): Exit with wrong format error rather than asserting input file is as expected. * elf32-s390.c (elf_s390_relocate_section): Likewise. * elf32-sh.c (sh_elf_relocate_section): Likewise. * elf32-xtensa.c (elf_xtensa_relocate_section): Likewise. * elf64-ppc.c (ppc64_elf_relocate_section): Likewise. * elf64-s390.c (elf_s390_relocate_section): Likewise. * elf64-x86-64.c (elf_x86_64_relocate_section): Likewise. * elf32-ppc.c (ppc_elf_relocate_section): Exit with wrong format error if input file is not ppc32 ELF.
2018-12-18sim: Don't overwrite stored errno in sim_syscall_multiAndrew Burgess2-5/+5
The host syscall callback mechanism should take care of updating the errcode within the CB_SYSCALL struct, and we should not be adjusting the error code once the syscall has completed. We especially, should not be rewriting the syscall errcode based on the value of errno some time after running the host syscall, as there is no guarantee that errno has not be overwritten. To perform a syscall we call cb_syscall (in syscall.c). To return from cb_syscall control passes through one of two exit paths these are labeled FinishSyscall and ErrorFinish and are reached using goto statements scattered throughout the cb_syscall function. In FinishSyscall we store the syscall result in 'sc->result', and the error code is transated to target encoding, and stored in 'sc->errcode'. In ErrorFinish, we again store the syscall result in 'sc->result', and fill in 'sc->errcode' by fetching the actual errno from the host with the 'cb->get_errno' callback. In both cases 'sc->errcode' will have been filled in with an appropriate value. Further, if we look at a specific syscall example, CB_SYS_open, in this case the first thing we do is fetch the path to open from the target with 'get_path', if this fails then the errcode is returned, and we jump to FinishSyscall. Notice that in this case, no host syscall may have been performed, for example a failure to read the path to open out of simulated memory can return EINVAL without performing any host syscall. Given that no host syscall has been performed, reading the host errno makes absolutely no sense. This commit removes from sim_syscall_multi the rewriting of sc->errcode based on the value of errno, and instead relies on the value stored in the cb_syscall. sim/common/ChangeLog: * sim-syscall.c (sim_syscall_multi): Don't update sc->errcode at this point, it should have already been set in cb_syscall.
2018-12-18Automatic date update in version.inGDB Administrator1-1/+1
2018-12-17gdb/dwarf: Convert some predicates from int to boolAndrew Burgess2-29/+49
In the dwarf reader we have a set of predicates, these include the different producer predicates and also some control predicates. The older ones are declared as integers, while newer ones (added since the C++ conversion) are bool. This commit makes them all bool for consistency. There should be no user visible change after this commit. gdb/ChangeLog: * dwarf2read.c (struct dwarf2_cu): Convert the fields 'mark', 'has_loclist', 'checked_producer', 'producer_is_gxx_lt_4_6', 'producer_is_gcc_lt_4_3', 'producer_is_icc_lt_14', 'processing_has_namespace_info' from unsigned int to bool. Update comments. (producer_is_icc_lt_14): Update return type. (producer_is_gcc_lt_4_3): Likewise. (producer_is_gxx_lt_4_6): Likewise. (process_die): Write true instead of 1 into predicate fields. (dwarf2_start_symtab): Likewise. (var_decode_location): Likewise. (dwarf2_mark_helper): Likewise. (dwarf2_mark): Likewise. (dwarf2_clear_marks): Write false instead of 0 into predicate field. (dwarf2_cu::dwarf2_cu): Initialise predicate fields to false, not 0.
2018-12-18PR23980, powerpc64 ld segfaultAlan Modra2-0/+9
PR 23980 * elf64-ppc.c (ppc64_elf_hide_symbol): Check hash table type before referencing ppc64-only fields of hash entries.
2018-12-17AArch64: Fix the gdb build with musl libcSzabolcs Nagy2-1/+6
Including asm/sigcontext.h together with libc headers is not valid. In general linux headers may not work with libc headers, so mixing them should be avoided, especially when the linux header defines types that are also exposed in libc headers. In case of asm/sigcontext.h glibc happens to work because glibc signal.h directly includes it, but e.g. in musl libc signal.h replicates the sigcontext.h definitions in an abi compatible way which are in conflict with the linux definitions when both headers are included. Since old linux headers or old libc headers may not have the necessary definitions, gdb has to replicate the definitions it relies on anyway. Which is fine since all definitions must be ABI stable. For linux apis that are not available via libc headers, replicating the definitions in gdb is the most reliable way to use them. Note: asm/ptrace.h includes asm/sigcontext.h in some versions of linux headers, which is just as problematic and should be fixed in linux. gdb/ChangeLog: * nat/aarch64-sve-linux-ptrace.h: Include signal.h instead of asm/sigcontext.h.
2018-12-17OBVIOUS: Fix ARI warning by removing warning trailing new linePhilippe Waroquiers2-1/+6
2018-12-17 Philippe Waroquiers <philippe.waroquiers@skynet.be> * nat/linux-ptrace.c (kill_child): Fix ARI warning by removing warning trailing new line.
2018-12-17PR23994, libbfd integer overflowAlan Modra3-27/+57
PR 23994 * aoutx.h: Include limits.h. (get_reloc_upper_bound): Detect long overflow and return a file too big error if it occurs. * elf.c: Include limits.h. (_bfd_elf_get_symtab_upper_bound): Detect long overflow and return a file too big error if it occurs. (_bfd_elf_get_dynamic_symtab_upper_bound): Likewise. (_bfd_elf_get_dynamic_reloc_upper_bound): Likewise.
2018-12-17Automatic date update in version.inGDB Administrator1-1/+1
2018-12-16Factorize killing the children in linux-ptrace.c, and fix a 'process leak'.Philippe Waroquiers2-37/+48
Running the gdb testsuite under Valgrind started to fail after 100+ tests, due to out of memory caused by lingering processes. The lingering processes are caused by the combination of a limitation in Valgrind signal handling when using PTRACE_TRACEME and a (minor) bug in GDB. The Valgrind limitation is : when a process is ptraced and raises a signal, Valgrind will replace the raised signal by SIGSTOP as other signals are masked by Valgrind when executing a system call. Removing this limitation seems far to be trivial, valgrind signal handling is very complex. Due to this valgrind limitation, GDB linux_ptrace_test_ret_to_nx gets a SIGSTOP signal instead of the expected SIGTRAP or SIGSEGV. In such a case, linux_ptrace_test_ret_to_nx does an early return, but does not kill the child (running under valgrind), child stays in a STOP-ped state. These lingering processes then eat the available system memory, till launching a new process starts to fail. This patch fixes the GDB minor bug by killing the child in case linux_ptrace_test_ret_to_nx does an early return. nat/linux-ptrace.c has 3 different logics to kill a child process. So, this patch factorizes killing a child in the function kill_child. The 3 different logics are: * linux_ptrace_test_ret_to_nx is calling both kill (child, SIGKILL) and ptrace (PTRACE_KILL, child, ...), and then is calling once waitpid. * linux_check_ptrace_features is calling ptrace (PTRACE_KILL, child, ...) + my_waitpid in a loop, as long as the waitpid status was WIFSTOPPED. * linux_test_for_tracefork is calling once ptrace (PTRACE_KILL, child, ...) + my_waitpid. The linux ptrace documentation indicates that PTRACE_KILL is deprecated, and tells to not use it, as it might return success but not kill the tracee. The documentation indicates to send SIGKILL directly. I suspect that linux_ptrace_test_ret_to_nx calls both kill and ptrace just to be sure ... I suspect that linux_check_ptrace_features calls ptrace in a loop to bypass the PTRACE_KILL limitation. And it looks like linux_test_for_tracefork does not handle the PTRACE_KILL limitation. Also, 2 of the 3 logics are calling my_waitpid, which seems better, as this is protecting the waitpid syscall against EINTR. So, the logic in kill_child is just using kill (child, SIGKILL) + my_waitpid, and then does a few verifications to see everything worked accordingly to the plan. Tested on Debian/x86_64. 2018-12-16 Philippe Waroquiers <philippe.waroquiers@skynet.be> * nat/linux-ptrace.c (kill_child): New function. (linux_ptrace_test_ret_to_nx): Use kill_child instead of local code. Add a call to kill_child in case of early return after fork. (linux_check_ptrace_features): Use kill_child instead of local code. (linux_test_for_tracefork): Likewise.
2018-12-16Automatic date update in version.inGDB Administrator1-1/+1
2018-12-14Minor gdb/Makefile.in cleanupsTom Tromey2-7/+7
This removes an IMO not very useful comment in gdb/Makefile.in about "alloca". It also removes INFOFILES, which I think probably has not been useful since whenever the manual was moved into a subdirectory. gdb/ChangeLog 2018-12-14 Tom Tromey <tom@tromey.com> * Makefile.in: Remove "alloca" comment. (INFOFILES): Remove. (local-maintainer-clean): Don't use INFOFILES.
2018-12-15Automatic date update in version.inGDB Administrator1-1/+1
2018-12-14elf: Add PT_GNU_PROPERTY segment typeH.J. Lu43-191/+411
Linkers group input note sections with the same name into one output note section with the same name. One output note section is placed in one PT_NOTE segment. New linkers merge all input .note.gnu.property sections into one output .note.gnu.property section with a single NT_GNU_PROPERTY_TYPE_0 note in a single PT_NOTE segment. Since older linkers treat input .note.gnu.property section as a generic note section and just concatenate all input .note.gnu.property sections into one output .note.gnu.property section without merging them, we may see one or more NT_GNU_PROPERTY_TYPE_0 notes in PT_NOTE segment, which are invalid. GNU_PROPERTY_X86_UINT32_VALID was defined to address this issue such that linker sets the bit for non-relocatable outputs. But it isn't sufficient: 1. It doesn't cover generic properties. 2. When -mx86-used-note=yes is passed to x86 assembler, the GNU_PROPERTY_X86_UINT32_VALID bit is set in GNU_PROPERTY_X86_ISA_1_USED property in object file and older linkers generate invalid NT_GNU_PROPERTY_TYPE_0 notes with the GNU_PROPERTY_X86_UINT32_VALID bit set. I am proposing the following changes: 1. Add PT_GNU_PROPERTY segment type: # define PT_GNU_PROPERTY (PT_LOOS + 0x474e553) which covers .note.gnu.property section. 2. Remove GNU_PROPERTY_X86_UINT32_VALID. bfd/ PR ld/23900 * elf.c (get_program_header_size): Add a PT_GNU_PROPERTY segment for NOTE_GNU_PROPERTY_SECTION_NAME. (_bfd_elf_map_sections_to_segments): Create a PT_GNU_PROPERTY segment for NOTE_GNU_PROPERTY_SECTION_NAME. * elfxx-x86.c (_bfd_elf_link_setup_gnu_properties): Don't set GNU_PROPERTY_X86_UINT32_VALID. binutils/ PR ld/23900 * readelf.c (get_segment_type): Support PT_GNU_PROPERTY. (decode_x86_isa): Don't check GNU_PROPERTY_X86_UINT32_VALID. (decode_x86_feature_1): Likewise. (decode_x86_feature_2): Likewise. (print_gnu_property_note): Remove GNU_PROPERTY_X86_UINT32_VALID check. * testsuite/binutils-all/i386/empty.d: Updated. * testsuite/binutils-all/x86-64/empty-x32.d: Likewise. * testsuite/binutils-all/x86-64/empty.d: Likewise. * testsuite/binutils-all/i386/pr21231b.s: Change GNU_PROPERTY_X86_ISA_1_USED bits to 0x7fffffff. * testsuite/binutils-all/x86-64/pr21231b.s: Likewise. gas/ PR ld/23900 * config/tc-i386.c (x86_cleanup): Don't set GNU_PROPERTY_X86_UINT32_VALID. * testsuite/gas/i386/property-1.s: Change GNU_PROPERTY_X86_ISA_1_USED bits to 0. include/ PR ld/23900 * elf/common.h (PT_GNU_PROPERTY): New. (GNU_PROPERTY_X86_UINT32_VALID): Removed. ld/ PR ld/23900 * testsuite/ld-elf/elf.exp: Run PR ld/23900 test. * testsuite/ld-elf/pr23900-1-32.rd: New file. * testsuite/ld-elf/pr23900-1-64.rd: Likewise. * testsuite/ld-elf/pr23900-1.d: Likewise. * testsuite/ld-elf/pr23900-1.s: Likewise. * testsuite/ld-elf/pr23900-2.s: Likewise. * testsuite/ld-elf/pr23900-2a.d: Likewise. * testsuite/ld-elf/pr23900-2b.d: Likewise. * testsuite/ld-i386/ibt-plt-1.d: Adjusted. * testsuite/ld-i386/ibt-plt-2c.d: Likewise. * testsuite/ld-i386/ibt-plt-2d.d: Likewise. * testsuite/ld-i386/ibt-plt-3d.d: Likewise. * testsuite/ld-x86-64/ibt-plt-1-x32.d: Likewise. * testsuite/ld-x86-64/ibt-plt-1.d: Likewise. * testsuite/ld-x86-64/ibt-plt-2c-x32.d: Likewise. * testsuite/ld-x86-64/ibt-plt-2c.d: Likewise. * testsuite/ld-x86-64/ibt-plt-2d-x32.d: Likewise. * testsuite/ld-x86-64/ibt-plt-2c.d: Likewise. * testsuite/ld-x86-64/ibt-plt-3c-x32.d: Likewise. * testsuite/ld-x86-64/ibt-plt-3c.d: Likewise. * testsuite/ld-x86-64/ibt-plt-3d-x32.d: Likewise. * testsuite/ld-x86-64/ibt-plt-3d.d: Likewise. * testsuite/ld-i386/pr23372c.d: Expect <None> for GNU_PROPERTY_X86_ISA_1_USED. * testsuite/ld-x86-64/pr23372c-x32.d: Likewise. * testsuite/ld-x86-64/pr23372c.d: Likewise. * testsuite/ld-x86-64/pr23372d-x32.d: Likewise. * testsuite/ld-x86-64/pr23372d.d: Likewise. * testsuite/ld-x86-64/property-x86-5a.s: Change GNU_PROPERTY_X86_ISA_1_USED bits to 0. * testsuite/ld-x86-64/property-x86-5b.s: Likewise.
2018-12-14Automatic date update in version.inGDB Administrator1-1/+1
2018-12-13Fix typo/thinko in last change.Jeff Law2-1/+6
* dw2gencfi.c (output_cie): Add missing semicolon in last change.
2018-12-13Update the FreeBSD system call table to match FreeBSD 12.0.John Baldwin3-23/+170
Add a script to generate the FreeBSD XML system call table from the sys/sys/syscall.h file in the kernel source tree. For ABI compatiblity system calls used by older binaries (such as freebsd11_kevent()), the original system call name is used as an alias. Run this script against the current syscall.h file in FreeBSD's head branch which is expected to be the file used in 12.0 (head is currently in code freeze as part of the 12.0 release process). gdb/ChangeLog: * syscalls/update-freebsd.sh: New file. * syscalls/freebsd.xml: Regenerate.
2018-12-13Add an optional "alias" attribute to syscall entries.John Baldwin10-44/+112
When setting a syscall catchpoint by name, catch syscalls whose name or alias matches the requested string. When the ABI of a system call is changed in the FreeBSD kernel, this is implemented by leaving a compatibility system call using the old ABI at the existing "slot" and allocating a new system call for the version using the new ABI. For example, new fields were added to the 'struct kevent' used by the kevent() system call in FreeBSD 12. The previous kevent() system call in FreeBSD 12 kernels is now called freebsd11_kevent() and is still used by older binaries compiled against the older ABI. The freebsd11_kevent() system call can be tagged with an "alias" attribute of "kevent" permitting 'catch syscall kevent' to catch both system calls and providing the expected user behavior for both old and new binaries. It also provides the expected behavior if GDB is compiled on an older host (such as a FreeBSD 11 host). gdb/ChangeLog: * NEWS: Add entry documenting system call aliases. * break-catch-syscall.c (catch_syscall_split_args): Pass 'result' to get_syscalls_by_name. * gdbarch.sh (UNKNOWN_SYSCALL): Remove. * gdbarch.h: Regenerate. * syscalls/gdb-syscalls.dtd (syscall): Add alias attribute. * xml-syscall.c [!HAVE_LIBEXPAT] (get_syscalls_by_name): Rename from get_syscall_by_name. Now accepts a pointer to a vector of integers and returns a bool. [HAVE_LIBEXPAT] (struct syscall_desc): Add alias member. (syscall_create_syscall_desc): Add alias parameter and pass it to syscall_desc constructor. (syscall_start_syscall): Handle alias attribute. (syscall_attr): Add alias attribute. (xml_get_syscalls_by_name): Rename from xml_get_syscall_number. Now accepts a pointer to a vector of integers and returns a bool. Add syscalls whose alias or name matches the requested name. (get_syscalls_by_name): Rename from get_syscall_by_name. Now accepts a pointer to a vector of integers and returns a bool. * xml-syscall.h (get_syscalls_by_name): Likewise. gdb/doc/ChangeLog: * gdb.texinfo (Set Catchpoints): Add an anchor for 'catch syscall'. (Native): Add a FreeBSD subsection. (FreeBSD): Document use of system call aliases for compatibility system calls.
2018-12-13Change get_syscalls_by_group to append to an existing vector of integers.John Baldwin4-49/+36
This removes the need for the caller to explicitly manage the memory for the returned system call list. The sole caller only needed the system call numbers rather than the full syscall structures. get_syscalls_by_group now uses a boolean return value to indicate if the requested group exists. gdb/ChangeLog: * break-catch-syscall.c (catch_syscall_split_args): Pass 'result' to get_syscalls_by_group. * xml-syscall.c [!HAVE_LIBEXPAT] (get_syscalls_by_group): Return false. [HAVE_LIBEXPAT] (xml_list_syscalls_by_group): Append syscall numbers to an existing vector of integers and return a bool. (get_syscalls_by_group): Accept pointer to vector of integers and change return type to bool. * xml-syscall.h (get_syscalls_by_group): Likewise.
2018-12-13RISC-V: Correct printing of MSTATUS and MISA.Jim Wilson2-2/+15
* riscv-tdep.c (riscv_print_one_register_info): For MSTATUS, add comment for SD field, and correct xlen calculation. For MISA, add comment for MXL field, add call to register_size, and correct base calculation.
2018-12-13Move aarch64 CIE code to aarch64 backendSam Tebbs6-13/+76
This commit moves all aarch64-specific code to deal with CIE structure introduced in 3a67e1a6b4430374f3073e51bb19347d4c421cfe from target-independent files to the aarch64 backend. 2018-12-13 Sam Tebbs <sam.tebbs@arm.com> binutils/ * dwarf.c (read_cie): Add check for 'B'. gas/ * config/tc-aarch64.h (enum pointer_auth_key, tc_fde_entry_extras, tc_cie_entry_extras, tc_fde_entry_init_extra, tc_output_cie_extra, tc_cie_fde_equivalent_extra, tc_cie_entry_init_extra): Define. * dw2gencfi.c (struct cie_entry): Add tc_cie_entry_extras invocation. (alloc_fde_entry, select_cie_for_fde): Add tc_fde_entry_init_extra invocation. (output_cie): Add tc_output_cie_extra invocation. (select_cie_for_fde): Add tc_cie_fde_equivalent_extra invocation. * dw2gencfi.h (enum pointer_auth_key): Move to config/tc-aarch64.h. (struct fde_entry): Add tc_fde_entry_extras invocation
2018-12-13Automatic date update in version.inusers/ARM/embedded-gdb-master-2018q4users/ARM/embedded-binutils-master-2018q4GDB Administrator1-1/+1
2018-12-13gdb: Update NEWS for OpenRISC Linux supportStafford Horne2-0/+5
gdb/ChangeLog: * NEWS(New targets): Add or1k*-*-linux*.
2018-12-12OBVIOUS: Forward declare linux_xfer_osdata_info_os_types on one line to fix ↵Philippe Waroquiers2-2/+6
ARI warning. 2018-12-12 Philippe Waroquiers <philippe.waroquiers@skynet.be> * nat/linux-osdata.c (linux_xfer_osdata_info_os_types): Forward declare on one line to fix ARI warning.
2018-12-12gdb: Update test pattern to deal with native-extended-gdbserverAndrew Burgess2-2/+25
When running the test gdb.base/annota1.exp with: make check-gdb RUNTESTFLAGS="--target_board=native-extended-gdbserver gdb.base/annota1.exp" I would see a failure due to some unexpected lines in GDB's output. The extra lines (when compared with a native run) were about file transfer from the remote back to GDB. This commit extends the regexp for this test to allow for these extra lines, and also splits the rather long regexp up into a list of parts. With this change in place I see no failures for gdb.base/annota1.exp when using the native-extended-gdbserver target board, nor with a native run on X86-64/Linux. gdb/testsuite/ChangeLog: * gdb.base/annota1.exp: Update a test regexp.
2018-12-12gdb/infcall: Make infcall_suspend_state into a classAndrew Burgess2-53/+101
I ran into a situation where attempting to make an inferior function call would trigger an assertion, like this: (gdb) call some_inferior_function () ../../src/gdb/regcache.c:310: internal-error: void regcache::restore(readonly_detached_regcache*): Assertion `src != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The problem that triggers the assertion is that in the function save_infcall_suspend_state, we basically did this: 1. Create empty infcall_suspend_state object. 2. Fill fields of infcall_suspend_state object. The problem is causes is that if filling any of the fields triggered an exception then the infcall_suspend_state object would be deleted while in a partially filled in state. In the specific case I encountered, I had a remote RISC-V target that claimed in its target description to support floating point registers. However, this was not true, and when GDB tried to read a floating point register the remote sent back an error. This error would cause an exception to be thrown while creating the readonly_detached_regcache, which in turn caused GDB to try and delete an infcall_suspend_state which didn't have any register state, and this triggered the assertion. To prevent this problem we have two possibilities, either, rewrite the restore code the handle partially initialised infcall_suspend_state objects, or, prevent partially initialised infcall_suspend_state objects from existing. The second of these seems like a better solution. So, in this patch, I move the filling in of the different infcall_suspend_state fields within a new constructor for infcall_suspend_state. Now, if generating one of those fields fails the destructor for infcall_suspend_state will not be executed and GDB will not try to restore the partially saved state. With this patch in place GDB now behaves like this: (gdb) call some_inferior_function () Could not fetch register "ft0"; remote failure reply 'E99' (gdb) The inferior function call is aborted due to the error. This has been tested against x86-64/Linux native, native-gdbserver, and native-extended-gdbserver with no regressions. I've manually tested this against my baddly behaving target and confirmed the inferior function call is aborted as described above. gdb/ChangeLog: * infrun.c (infcall_suspend_state::infcall_suspend_state): New. (infcall_suspend_state::registers): New. (infcall_suspend_state::restore): New. (infcall_suspend_state::thread_suspend): Rename to... (infcall_suspend_state::m_thread_suspend): ...this. (infcall_suspend_state::registers): Rename to... (infcall_suspend_state::m_registers): ...this. (infcall_suspend_state::siginfo_gdbarch): Rename to... (infcall_suspend_state::m_siginfo_gdbarch): ...this. (infcall_suspend_state::siginfo_data): Rename to... (infcall_suspend_state::m_siginfo_data): ...this. (save_infcall_suspend_state): Rewrite to use infcall_suspend_state constructor. (restore_infcall_suspend_state): Rewrite to use infcall_suspend_state::restore method. (get_infcall_suspend_state_regcache): Use infcall_suspend_state::registers method.
2018-12-12gdb/riscv: Handle passing variadic floating point argumentsAndrew Burgess2-2/+9
This commit fixes some test failures in gdb.base/varargs.exp when running on targets with floating point hardware. Floating point unnamed (variadic) arguments should be passed in integer registers according to the abi. After this commit I see no failures in gdb.base/varargs.exp on 32 or 64 bit targets with floating point hardware. gdb/ChangeLog: * riscv-tdep.c (riscv_call_arg_scalar_float): Unnamed (variadic) arguments are passed in integer registers. (riscv_call_arg_complex_float): Likewise.
2018-12-12[GAS][Arm] Skip Local BLX Thumb tests for arm-netbsdelf and arm-ntoAndre Vieira2-1/+6
gas/ChangeLog 2018-12-12 Andre Vieira <andre.simoesdiasvieira@arm.com> * testsuite/gas/arm/blx-local-thumb.d: Skip arm-nto and arm-netbsdelf.
2018-12-12Automatic date update in version.inGDB Administrator1-1/+1
2018-12-11bfd: xtensa: ignore overflow in hight part of const16 relocationMax Filippov2-2/+8
32-bit constants loaded by two const16 opcodes that involve relocation (e.g. calculated as a sum of a symbol and a constant) may overflow, resulting in linking error with the following message: dangerous relocation: const16: cannot encode: (_start+0x70000000) They should wrap around instead. Limit const16 opcode immediate field to 16 least significant bits to implement this wrap around. bfd/ 2018-12-11 Max Filippov <jcmvbkbc@gmail.com> * elf32-xtensa.c (elf_xtensa_do_reloc): Limit const16 opcode immediate field to 16 least significant bits.
2018-12-11Fix leaks in all the linux osdata annex transfers + code factorization.Philippe Waroquiers2-929/+662
Valgrind reports leaks in all linux osdata annex transfers of linux-osdata.c. A typical leak (this one is of gdb.base/info-os) is: ==10592== VALGRIND_GDB_ERROR_BEGIN ==10592== 65,536 bytes in 1 blocks are definitely lost in loss record 3,175 of 3,208 ==10592== at 0x4C2E273: realloc (vg_replace_malloc.c:826) ==10592== by 0x409B0C: xrealloc (common-utils.c:62) ==10592== by 0x408BC3: buffer_grow(buffer*, char const*, unsigned long) [clone .part.1] (buffer.c:40) ==10592== by 0x5263DF: linux_xfer_osdata_processes(unsigned char*, unsigned long, unsigned long) (linux-osdata.c:370) ==10592== by 0x520875: linux_nat_xfer_osdata (linux-nat.c:4214) ... The leaks are created because the linux_xfer_osdata_* functions transfer the ownership of their 'static struct buffer' memory to their 'static char *buf' local var, but then call buffer_free instead of xfree-ing buf. I see no reason why the ownership of the memory has to be transferred from a local var to another local var, so the fix consists in dropping the 'static char *buf' and accessing the struct buffer memory where needed. Also, because this bug was replicated in all functions, and there was a non neglectible amount of duplicated code, the setup and usage of the 'static struct buffer' is factorized in a new function common_getter. The buffer for a specific annex is now a member of the struct osdata_type instead of being a static var of each linux_xfer_osdata_* function. Thanks to this, all the linux_xfer_osdata_* do not have anymore any logic related to the partial transfer of data: they now only build the xml data in a struct buffer. This all removes about 300 SLOC. Note: git diff/git format-patch shows a lot of differences only due to space changes/indentation changes. So, git diff -w helps to look only at the relevant differences. gdb/ChangeLog 2018-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * nat/linux-osdata.c (common_getter): New function. (struct osdata_type): Change getter to take_snapshot. Add LONGEST len_avail and struct buffer buffer. Change all elements in the initializer. Add an element for the list of types. (linux_xfer_osdata_info_os_types): New function. (linux_common_xfer_osdata): Use common_getter for the list of types. Replace getter call by common_getter. (linux_xfer_osdata_cpus): Remove args READBUF, OFFSET, LEN. Add arg BUFFER. Only keep the code that adds data in BUFFER. (linux_xfer_osdata_fds): Likewise. (linux_xfer_osdata_modules): Likewise. (linux_xfer_osdata_msg): Likewise. (linux_xfer_osdata_processes): Likewise. (linux_xfer_osdata_processgroups): Likewise. (linux_xfer_osdata_sem): Likewise. (linux_xfer_osdata_shm): Likewise. (linux_xfer_osdata_isockets): Likewise. (linux_xfer_osdata_threads): Likewise.
2018-12-11Fix the date in the ChangeLogPhilippe Waroquiers1-1/+1
2018-12-11PATCH/OBVIOUS Remove various trailing spaces in linux-osdata.cPhilippe Waroquiers2-46/+50
2018-12-11Fix a typo in scripttempl/elf32xc16x.scH.J. Lu2-1/+5
* scripttempl/elf32xc16x.sc: Fix a typo.
2018-12-11xc16x: Add elf32_xc16x_rtype_to_howtoH.J. Lu2-1/+16
Add elf32_xc16x_rtype_to_howto to get reloc_howto_type pointer from ELF32_R_TYPE. * elf32-xc16x.c (elf32_xc16x_rtype_to_howto): New function. (elf32_xc16x_relocate_section): Call elf32_xc16x_rtype_to_howto instead of xc16x_reloc_type_lookup to get reloc_howto_type.
2018-12-11Fix a failure in the libiberty testsuite by increasing the recursion limit ↵Nick Clifton5-6/+16
to 2048. PR 88409 include * demangle.h (DEMANGLE_RECURSION_LIMIT): Increase to 2048. binutils* NEWS: Note that recursion limit has increased to 2048. * doc/binutils.texi: Likewise.
2018-12-11gdb/riscv: Update test to handle targets without an fpuAndrew Burgess2-1/+13
The FPU is optional on RISC-V. The gdb.base/float.exp test currently assumes that an fpu is always available on RISC-V. Update the test so that this is not the case. gdb/testsuite/ChangeLog: * gdb.base/float.exp: Handle RISC-V targets without an FPU.
2018-12-10RISC-V: Don't segfault for two regs in auipc or lui.Jim Wilson5-1/+27
gas/ PR gas/23954 * config/tc-riscv.c (my_getSmallExpression): Expand comment for register support. Set expr_end if parse a register. (riscv_ip) <'u'>: Break if imm_expr is not a symbol or constant. * testsuite/gas/riscv/auipc-parsing.d: New. * testsuite/gas/riscv/auipc-parsing.l: New. * testsuite/gas/riscv/auipc-parsing.s: New.
2018-12-11Automatic date update in version.inGDB Administrator1-1/+1
2018-12-10Correct gas/ChangeLog entry for PR gas/23968H.J. Lu1-1/+1
2018-12-10gdb/riscv: Remove whitespace before #include lineAndrew Burgess2-1/+6
This fixes an ARI warning in riscv-tdep.c that whitespace before a gdb/ChangeLog: * riscv-tdep.c (riscv_register_name): Fix ARI warning by removing leading whitespace before #include line.
2018-12-10Automatic date update in version.inGDB Administrator1-1/+1
2018-12-09x86: Put back BFD_RELOC_X86_64_GOTPCRELH.J. Lu6-0/+39
Put back BFD_RELOC_X86_64_GOTPCREL in TC_FORCE_RELOCATION_LOCAL, which was removed by commit 56ceb5b5405af23eddd12e12d8ba849010120324 Author: H.J. Lu <hjl.tools@gmail.com> Date: Thu Oct 22 04:49:20 2015 -0700 Add R_X86_64_[REX_]GOTPCRELX support to gas and ld by accident.
2018-12-09Fix tid-reuse sometimes blocks for a very long (infinite?) time.Philippe Waroquiers2-7/+31
A failure that seems to cause a long/infinite time is the following: For a not clear reason, tid-reuse.c spawner thread sometimes gets an error: tid-reuse: /bd/home/philippe/gdb/git/build_moreaa/gdb/testsuite/../../../moreaa/gdb/testsuite/gdb.threads/tid-reuse.c:58: spawner_thread_func: Assertion `rc == 0' failed. which causes a SIGABRT to be trapped by gdb, and tid-reuse does not reach the after_count breakpoint: Thread 2 "tid-reuse" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff7518700 (LWP 10368)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_count After that, tid-reuse.exp gets the value of reuse_time, but this one kept its initial value of -1 (as unsigned) : print reuse_time $1 = 4294967295 (gdb) PASS: gdb.threads/tid-reuse.exp: get reuse_time tid-reuse then dies, and the .exp script continues (with some FAIL) till it executes: set timeout [expr $reuse_time * 2] leading to the error: (gdb) ERROR: integer value too large to represent as non-long integer while executing "expect { -i exp8 -timeout 8589934590 -re ".*A problem internal to GDB has been detected" { fail "$message (GDB internal error)" gdb_intern..." ("uplevel" body line 1) invoked from within "uplevel $body" ARITH IOVERFLOW {integer value too large to represent as non-long integer} integer value too large to represent as non-long integer ERROR: GDB process no longer exists and then everything blocks. This last 'GDB process no longer exists' is strange, as I still see the gdb when this all blocks, e.g. philippe 16058 31085 0 20:30 pts/15 00:00:00 /bin/bash -c rootme=`pwd`; export rootme; srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ; EXPECT=`if [ philippe 16386 16058 0 20:30 pts/15 00:00:00 expect -- /usr/share/dejagnu/runtest.exp --status GDB_PARALLEL=yes --outdir=outputs/gdb.threads/tid-reuse gdb.thre philippe 24848 16386 0 20:30 pts/20 00:00:00 /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /bd/home/philip This patch gives a default value of 60, so that if ever something wrong happens in tid-reuse, then the value retrieved by the .exp script stays in a reasonable range. Simon verified the patch by: "I replaced the pthread_create call with the value 1 to simulate a failure, and the test succeeds to fail quickly with your patch applied. Without your patch, I get the infinite hang that you describe." Compared to V1: As suggested by Pedro, this version checks the pthread calls return code (in particular of pthread_create) and reports the failure reason, instead of just aborting. gdb/testsuite/ChangeLog 2018-12-09 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.threads/tid-reuse.c (REUSE_TIME_CAP): Declare as 60. (reuse_time): Initialize to REUSE_TIME_CAP. (check_rc): New function. (main): Use REUSE_TIME_CAP instead of hardcoded 60. Check pthread_create rc. (spawner_thread_func): Check pthread_create and pthread_join rc.
2018-12-08Look for tgetent in libtinfowSimon Marchi3-2/+9
On some systems where ncurses is only available in the "wide" version (compiled with --with-widec), there might be no libtinfo.so, only a libtinfow.so. Look for libtinfow in addition to libtinfo. gdb/ChangeLog: YYYY-MM-DD Simon Marchi <simon.marchi@ericsson.com> Дилян Палаузов <dilyan.palauzov@aegee.org> PR gdb/23950 * configure.ac: Search for tgetent in libtinfow. * configure: Re-generate.
2018-12-09Automatic date update in version.inGDB Administrator1-1/+1
2018-12-08Fix leak by using td_ta_delete() to deregister target process and deallocate ↵Philippe Waroquiers3-0/+23
internal process handle. Valgrind reports the below leak: ==25327== VALGRIND_GDB_ERROR_BEGIN ==25327== 672 bytes in 1 blocks are definitely lost in loss record 2,759 of 3,251 ==25327== at 0x4C2E07C: calloc (vg_replace_malloc.c:752) ==25327== by 0x7FDCB3E: ??? ==25327== by 0x532A7A: try_thread_db_load_1 (linux-thread-db.c:828) ==25327== by 0x532A7A: try_thread_db_load(char const*, int) (linux-thread-db.c:997) ==25327== by 0x53354D: try_thread_db_load_from_sdir (linux-thread-db.c:1074) ==25327== by 0x53354D: thread_db_load_search (linux-thread-db.c:1129) ==25327== by 0x53354D: thread_db_load() (linux-thread-db.c:1187) ==25327== by 0x611AF1: operator() (functional:2127) ==25327== by 0x611AF1: notify (observable.h:106) ==25327== by 0x611AF1: symbol_file_add_with_addrs(bfd*, char const*, enum_flags<symfile_add_flag>, std::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>, objfile*) (symfile.c:1158) ==25327== by 0x5F5C4A: solib_read_symbols(so_list*, enum_flags<symfile_add_flag>) (solib.c:691) ==25327== by 0x5F6A8B: solib_add(char const*, int, int) (solib.c:1003) ==25327== by 0x5F6BF7: handle_solib_event() (solib.c:1281) ==25327== by 0x3D0A94: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5417) ==25327== by 0x4FF133: handle_signal_stop(execution_control_state*) (infrun.c:5874) ==25327== by 0x502C29: handle_inferior_event_1 (infrun.c:5300) ==25327== by 0x502C29: handle_inferior_event(execution_control_state*) (infrun.c:5335) ==25327== by 0x5041DB: fetch_inferior_event(void*) (infrun.c:3868) ==25327== by 0x4A1E7C: gdb_wait_for_event(int) (event-loop.c:859) ... This leak is created because a call to td_ta_new allocates some resources that must be freed with td_ta_delete, and that was missing. With this patch, the nr of GDB executions leaking during regression tests decreases further from 566 to 380. Note that the gdbserver equivalent code is properly calling td_ta_delete: see thread_db_mourn in thread-db.c. Tests run natively on debian/amd64, and run under valgrind. gdb/ChangeLog 2018-12-08 Philippe Waroquiers <philippe.waroquiers@skynet.be> * linux-thread-db.c (struct thread_db_info): Add td_ta_delete_p. (thread_db_err_str): Forward declare. (delete_thread_db_info): Call td_ta_delete_p if available. (try_thread_db_load_1): Acquire td_ta_delete address. * nat/gdb_thread_db.h (td_ta_delete_ftype): Declare.
2018-12-08Merge forward-search/reverse-search, use gdb::def_vector, remove limitPedro Alves4-107/+74
Back in: commit 85ae1317add94adef4817927e89cff80b92813dd Author: Stan Shebs <shebs@codesourcery.com> AuthorDate: Thu Dec 8 02:27:47 1994 +0000 * source.c: Various cosmetic changes. (forward_search_command): Handle very long source lines correctly. a buffer with a hard limit was converted to a heap buffer: @@ -1228,15 +1284,26 @@ forward_search_command (regex, from_tty) stream = fdopen (desc, FOPEN_RT); clearerr (stream); while (1) { -/* FIXME!!! We walk right off the end of buf if we get a long line!!! */ - char buf[4096]; /* Should be reasonable??? */ - register char *p = buf; + static char *buf = NULL; + register char *p; + int cursize, newsize; + + cursize = 256; + buf = xmalloc (cursize); + p = buf; However, reverse_search_command has the exact same problem, and that wasn't fixed. We still have that "we walk right off" comment... Recently, the xmalloc above was replaced with a xrealloc, because as can be seen above, that 'buf' variable above was a static local, otherwise we'd be leaking. This commit replaces that and the associated manual buffer growing with a gdb::def_vector<char>. I don't think there's much point in reusing the buffer across command invocations. While doing this, I realized that reverse_search_command is almost identical to forward_search_command. So this commit factors out a common helper function instead of duplicating a lot of code. There are some tests for "forward-search" in gdb.base/list.exp, but since they use the "search" alias, they were a bit harder to find than expected. That's now fixed, both by testing both variants, and by adding some commentary. Also, there are no tests for the "reverse-search" command, so this commit adds some for that too. gdb/ChangeLog: 2018-12-08 Pedro Alves <palves@redhat.com> * source.c (forward_search_command): Rename to ... (search_command_helper): ... this. Add 'forward' parameter. Tweak to use a gdb::def_vector<char> instead of a xrealloc'ed buffer. Handle backward searches too. (forward_search_command, reverse_search_command): Reimplement by calling search_command_helper. gdb/testsuite/ChangeLog: 2018-12-08 Pedro Alves <palves@redhat.com> * gdb.base/list.exp (test_forward_search): Rename to ... (test_forward_reverse_search): ... this. Also test reverse-search and the forward-search alias.
2018-12-08[GOLD] icf_safe_so_testAlan Modra2-24/+38
PR 21128 * testsuite/icf_safe_so_test.sh (check_fold): Rewrite to check multiple symbols at once. (arch_specific_safe_fold): Likewise, and call with the four foo* symbols expected to fold.
generated by cgit v1.1 at 2024-11-25 22:01:28 +0000