aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-11-03Automatic date update in version.inGDB Administrator1-1/+1
2018-11-02binutils: Add AC_FUNC_MMAP to configure.acH.J. Lu4-2/+220
Add AC_FUNC_MMAP to configure.ac so that HAVE_MMAP will be checked in objdump.c and mmap is used if available. * configure.ac (AC_FUNC_MMAP): New. * config.in: Regenerated. * configure: Likewise.
2018-11-02(Ada) Add ravenscar tasking support on AArch64Joel Brobecker7-1/+266
This patch adds support for debugging Ravenscar tasks, similar to what is done for ppc and sparc. gdb/ChangeLog: * aarch64-ravenscar-thread.h, aarch64-ravenscar-thread.c: New files. * aarch64-tdep.c: #include "aarch64-ravenscar-thread.h". (aarch64_gdbarch_init): Add call to register_aarch64_ravenscar_ops. * Makefile.in (ALL_64_TARGET_OBS): Add aarch64-ravenscar-thread.o. (HFILES_NO_SRCDIR): Add aarch64-ravenscar-thread.h. (ALLDEPFILES): Add aarch64-ravenscar-thread.c. * configure.tgt (cpu_obs) [aarch64*-*-*]: Add ravenscar-thread.o and aarch64-ravenscar-thread.o. * NEWS: Add entry documenting Ravenscar tasking support on AArch64 ELF.
2018-11-02QUIET flag initialization missing in 2 places.Philippe Waroquiers3-2/+7
Fix by Matthew Malcomson <matthew.malcomson@arm.com> Pushed as obvious.
2018-11-02[GOLD] make cleanAlan Modra5-3/+24
Cleans a few more test files. * Makefile.am (MOSTLYCLEANFILES): Define. * Makefile.in: Regnerate. * testsuite/Makefile.am (MOSTLYCLEANFILES): Add ver_test_14 and gnu_property_test. * testsuite/Makefile.in: Regnerate.
2018-11-02Squash readelf warning on zero sh_link reloc sectionAlan Modra2-20/+26
On readelf examining a static executable built with current glibc, we get a silly warning. Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .note.ABI-tag NOTE 0000000000400190 000190 000020 00 A 0 0 4 [ 2] .note.gnu.build-id NOTE 00000000004001b0 0001b0 000024 00 A 0 0 4 readelf: Warning: [ 3]: Link field (0) should index a symtab section. [ 3] .rela.plt RELA 00000000004001d8 0001d8 000228 18 AI 0 20 8 This .rela.plt section contains only IRELATIVE relocations (which have symbol index zero), so it isn't appropriate to warn. A zero sh_link section is deliberately chosen for such a section (see PR10337 and PR23850). So this patch disables the SHT_REL* sh_link warning. I've also removed the .rel.dyn/.rela.dyn section name test to disable the sh_info warning for SHT_REL* sections. While relocation sections in an executable need not specify the section they relocate (the relocation sh_offset field is an address, not a section offset), that isn't true in a relocatable file where sh_offset is relative to a section. If .rela.dyn happens to exist in an ET_REL object it must specify a valid section. * readelf.c (process_section_headers): Don't warn on a zero sh_info or sh_link for any reloc section in an executable or shared library. Do warn for .rel.dyn/.rela.dyn in ET_REL.
2018-11-02PR23850, strip should not discard/move .rela.plt in executableAlan Modra2-8/+17
strip/objcopy can't deal with alloc reloc sections, not .rela.dyn or .rela.plt in a dynamic executable, or .rela.plt/.rela.iplt in a static executable. So, don't have BFD treat them as side-channel data associated with the section they are relocating. PR 23850 * elf.c (bfd_section_from_shdr): Treat SHF_ALLOC SHT_REL* sections in an executable or shared library as normal sections.
2018-11-01RISC-V: Don't allow unaligned breakpoints.Jim Wilson2-8/+30
Some hardware doesn't support unaligned accesses, and a bare metal target may not have an unaligned access trap handler. So if the PC is 2-byte aligned, then use a 2-byte breakpoint to avoid unaligned accesses. Tested on native RV64GC Linux with gdb testsuite and cross on spike simulator and openocd with riscv-tests/debug. gdb/ * riscv-tdep.c (riscv_breakpoint_kind_from_pc): New local unaligned_p. Set if pcptr if unaligned. Return 2 if unaligned_p true. Update debugging messages.
2018-11-02Automatic date update in version.inGDB Administrator1-1/+1
2018-11-01(Ada) fix "error in expression" when using watch -location commandJoel Brobecker7-1/+129
The "watch -l EXPR" command with the language set to Ada currently fails with the following error: (gdb) watch -l global_var Error in expression, near ` 0x000000000062d2d8'. The error occurs because GDB internally translate the request into a watchpoint on a different expression: "* (TYPE *) ADDR" where TYPE and ADDR are the type and the address of the object returned by the expression's evaluation (resp.). So, in the example above, global_var being an integer stored at 0x000000000062d2d8, GDB tries to set a watchpoint on "* (integer *) 0x000000000062d2d8", which fails, because we try to parse this expression with Ada, when in fact it is not valid. This patch fixes the issue by implementing the la_watch_location_expression language method, using a syntax that the Ada parser recognizes ("{TYPE} ADDR"). gdb/ChangeLog: * ada-lang.c (ada_watch_location_expression): New function. (ada_language_defn): Set la_watch_location_expression to ada_watch_location_expression. gdb/testsuite/ChangeLog: * gdb.ada/watch_minus_l: New testcase.
2018-11-01remove trailing spaces in print-utils.c ("int_string" function)Joel Brobecker2-3/+7
gdb/ChangeLog: * print-utils.c (int_string): Remove unnecessary trailing spaces.
2018-11-01gdb.texinfo: Fix the output of the "info tasks 2" exampleJoel Brobecker2-1/+7
gdb/doc/ChangeLog: * gdb.texinfo (Ada Tasks): Update the "info task 2" example output to match the current implementation.
2018-11-01rs6000-tdep.c:skip_prologue avoid negative left shiftJoel Brobecker2-4/+12
the rs6000-tdep.c::skip_prologue function has the following code: unsigned int all_mask = ~((1U << fdata->saved_gpr) - 1); /* Not a recognized prologue instruction. Handle optimizer code motions into the prologue by continuing the search if we have no valid frame yet or if the return address is not yet saved in the frame. Also skip instructions if some of the GPRs expected to be saved are not yet saved. */ if (fdata->frameless == 0 && fdata->nosavedpc == 0 && (fdata->gpr_mask & all_mask) == all_mask) break; The problem is that fdata->saved_gpr is initialized to -1, and so, if no instruction is found in the function's prologue that causes us to set that field to a non-negative value, the sanitizer crashes with the following message: rs6000-tdep.c:1965:34: runtime error: shift exponent -1 is negative This patch fixes the issue the by only doing the shift if saved_gpr is not negative. When saved_gpr is negative, we actually don't need the shift. gdb/ChangeLog: * rs6000-tdep.c (skip_prologue): Fix potential negative left shifting. Tested on ppc-linux native. Also tested on ppc-elf (baremetal) using AdaCore's testsuite.
2018-11-01arm-pikeos: software single stepJerome Guitton6-0/+106
On ARM, PikeOS does not support hardware single step, causing various semi-random errors when trying to next/step over some user code. So this patch changes this target to use software-single-step instead. The challenge is that, up to now, the PikeOS target was in all respects identical to a baremetal target as far as GDB was concerned, meaning we were using the baremetal osabi for this target too. This is no longer possible, and we need to introduce a new OSABI variant. Unfortunately, there isn't anything in the object file that would allow us to differentiate between the two platforms. So we have to rely on a heuristic instead, where we look for some known symbols that are required in a PikeOS application (these symbols are expected to be defined by the default linker script, and correspond to routines used to allocate the application stack). For the long run, the hope is that the stub implementation provided by PikeOS is enhanced so that it includes vContSupported+ to the $qSupported query, and then that the reply to the "vCont?" query only return support for "continue" operations (thus exclusing "step" operations). We could then use that information to reliably determine at connection time that the target does not support single-stepping and therefore automatically turn software single-stepping automatically based on it. gdb/ChangeLog: * defs.h (enum gdb_osabi): Add GDB_OSABI_PIKEOS. * osabi.c (gdb_osabi_names): Add name for GDB_OSABI_PIKEOS. * arm-pikeos-tdep.c: New file. * configure.tgt: Add arm-pikeos-tdep.o to the case of ARM embedded system. * Makefile.in (ALL_TARGET_OBS): Add arm-pikeos-tdep.o. Tested on arm-pikeos and arm-elf using AdaCore's testsuite. We also evaluated it on armhf-linux as a cross platform.
2018-11-01Import mkdtemp gnulib module, fix mingw buildSimon Marchi19-27/+217
Building with mingw currently fails: CXX unittests/mkdir-recursive-selftests.o /home/emaisin/src/binutils-gdb/gdb/unittests/mkdir-recursive-selftests.c: In function ‘void selftests::mkdir_recursive::test()’: /home/emaisin/src/binutils-gdb/gdb/unittests/mkdir-recursive-selftests.c:49:20: error: ‘mkdtemp’ was not declared in this scope if (mkdtemp (base) == NULL) ^ Commit e418a61a67a ("Move mkdir_recursive to common/filestuff.c") moved this code, but also removed the HAVE_MKDTEMP guard which prevented the mkdtemp call to be compiled on mingw. We can either put back the HAVE_MKDTEMP ifdef, or import the gnulib mkdtemp module, which provides the function for mingw. Since the mkdir_recursive is susceptible to be used on mingw at some point, I think it would be nice to have it tested on mingw, so I did the latter. Once built, I tested it on Windows (copied the resulting gdb.exe on a Windows machine, ran it, and ran "maint selftest mkdir_recursive"). It failed, because the temporary directory is hardcoded to "/tmp/...". I therefore added and used a new get_standard_temp_dir function, which returns an appropriate temporary directory for the host platform. gdb/ChangeLog: * common/pathstuff.c (get_standard_temp_dir): New. * common/pathstuff.h (get_standard_temp_dir): New. * config.in: Re-generate. * configure: Re-generate. * configure.ac: Don't check for mkdtemp. * gnulib/aclocal-m4-deps.mk: Re-generate. * gnulib/aclocal.m4: Re-generate. * gnulib/config.in: Re-generate. * gnulib/configure: Re-generate. * gnulib/import/Makefile.am: Re-generate. * gnulib/import/Makefile.in: Re-generate. * gnulib/import/m4/gnulib-cache.m4: Re-generate. * gnulib/import/m4/gnulib-comp.m4: Re-generate. * gnulib/import/m4/mkdtemp.m4: New file. * gnulib/import/mkdtemp.c: New file. * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add mkdtemp module. * unittests/mkdir-recursive-selftests.c (test): Use get_standard_temp_dir. (_initialize_mkdir_recursive_selftests): Remove HAVE_MKDTEMP ifdef. * compile/compile.c (get_compile_file_tempdir): Likewise.
2018-11-01Fix ld action in run_dump_testThomas Preud'homme7-17/+53
run_dump_test proposes an ld action but when trying to make use of it in a gas test it gave me some Tcl error. It turns out that it references the check_shared_lib_support procedure and ld_elf_shared_opt variable both only available in ld-lib.exp. I've thus moved the procedure in binutils-common.exp and defined the variable needed in the various default.exp of testsuite that seem to be using run_dump_test. Since check_shared_lib_support itself references the ld variable not defined in binutils-common I've defined it from LD in run_dump_test and fixed LD and LDFLAGS to be defined as expected by run_dump_test in the various default.exp of testsuite using run_dump_test. 2018-11-01 Thomas Preud'homme <thomas.preudhomme@linaro.org> binutils/ * testsuite/config/default.exp: Define LD, LDFLAGS and ld_elf_shared_opt. * testsuite/lib/binutils-common.exp (check_shared_lib_support): Moved from ld-lib.exp. (run_dump_test): Set ld to $LD. gas/ * testsuite/config/default.exp: Define LD, LDFLAGS and ld_elf_shared_opt. ld/ * testsuite/lib/ld-lib.exp (check_shared_lib_support): Moved to binutils-common.exp.
2018-11-01Reading signal handler frame in AIXSangamesh Mallayya5-1/+210
In AIX if gdb is debugging an application which has a signal handler and reaches the signal handler frame, then we need to read the back chain address from sigcontext saved on the stack, similarly the LR. As backchain at an offset 0 will be 0, because we will have a sigconext saved after the minimum stack size. So the correct backchain will be at an offset after minimum stack and the LR at an offset 8 will be of the signal millicode address. If the back chain pointer is NULL and the LR field is in the kernel segment(ex. 0x00004a14) then we can probably assume we are in a signal handler. sample output (gdb) bt 0 sig_handle_aix (signo=11) at aix-sighandle.c:7 1 0x0000000000004a94 in ?? () (gdb) expected output (gdb) bt 0 sig_handle_aix (signo=11) at aix-sighandle.c:7 1 <signal handler called> 2 0x0000000100000748 in foo () at aix-sighandle.c:14 3 0x000000010000079c in main () at aix-sighandle.c:19 gdb/ChangeLog: 2018-11-01 Sangamesh Mallayya <sangamesh.swamy@in.ibm.com> * rs6000-aix-tdep.c: Include "trad-frame.h" and "frame-unwind.h". (SIG_FRAME_LR_OFFSET64): New define. (SIG_FRAME_FP_OFFSET64): New define. (aix_sighandle_frame_cache): New Function. (aix_sighandle_frame_this_id): New Function. (aix_sighandle_frame_prev_register): New Function. (aix_sighandle_frame_sniffer): New Function. (aix_sighandle_frame_unwind): New global variable. (rs6000_aix_init_osabi): Install new frame unwinder. gdb/testsuite/ChangeLog: 2018-11-01 Sangamesh Mallayya <sangamesh.swamy@in.ibm.com> * gdb.arch/aix-sighandle.c: New file. * gdb.arch/aix-sighandle.exp: New file.
2018-11-01Automatic date update in version.inGDB Administrator1-1/+1
2018-10-31Fix PR gdb/23835: Don't redefine _FORTIFY_SOURCE if it's already definedSergio Durigan Junior2-2/+9
Gentoo has a local GCC patch which always defines _FORTIFY_SOURCE=2. This causes a build problem when building GDB there, because "common/common-defs.h" also defines _FORTIFY_SOURCE=2: CXX gdb.o In file included from ../../gdb/defs.h:28:0, from ../../gdb/gdb.c:19: ../../gdb/common/common-defs.h:71:0: error: "_FORTIFY_SOURCE" redefined [-Werror] #define _FORTIFY_SOURCE 2 <built-in>: note: this is the location of the previous definition cc1plus: all warnings being treated as errors make[2]: *** [Makefile:1619: gdb.o] Error 1 Even though it is questionable whether Gentoo's approach is the correct one: https://jira.mongodb.org/browse/SERVER-29982 https://bugs.gentoo.org/621036 it is still possible for GDB to be a bit more robust here and make sure it just defines _FORTIFY_SOURCE if it hasn't been defined already. This patch does that. Tested by rebuilding and making sure the macro was defined. gdb/ChangeLog: 2018-10-31 Sergio Durigan Junior <sergiodj@redhat.com> PR gdb/23835 * common/common-defs.h: Don't redefine _FORTIFY_SOURCE if it's already defined.
2018-10-31gdb/riscv: Fix failures on rv64 in gdb.arch/riscv-reg-aliases.exp testAndrew Burgess2-66/+121
The gdb.arch/riscv-reg-aliases.exp test didn't take into account that on RV64 (and RV128) the floating point registers are represented as a union. This patch updates the test to handle this. Tested against RV32 and RV64. gdb/testsuite/ChangeLog: * gdb.arch/riscv-reg-aliases.exp: Rewrite to take account of float registers being unions.
2018-10-31[gdb/testsuite] Factor out lib/valgrind.expTom de Vries5-204/+125
Factor out common code related to vgdb setup and cleanup in valgrind-bt.exp, valgrind-disp-step.exp and gdb.base/valgrind-infcall.exp. Tested on x86_64-linux with and without --target_board=native-gdbserver. 2018-10-31 Tom de Vries <tdevries@suse.de> * lib/valgrind.exp: New file. (vgdb_start, vgdb_stop): New procs, factored out of ... * gdb.base/valgrind-bt.exp: ... here, ... * gdb.base/valgrind-disp-step.exp: ... here and ... * gdb.base/valgrind-infcall.exp: ... here.
2018-10-31Merge config/ changes from GCC.Joseph Myers7-3/+21
config: Merge from GCC: 2018-10-28 Iain Buclaw <ibuclaw@gdcproject.org> * multi.m4: Set GDC. 2018-07-05 James Clarke <jrtc27@jrtc27.com> * dfp.m4 (enable_decimal_float): Enable for x86_64*-*-gnu* to catch x86_64 kFreeBSD and Hurd. libdecnumber: * configure: Regenerate. zlib: * configure: Regenerate.
2018-10-31Merge autoconf / automake update changes from GCC.Joseph Myers8-30/+134
Top level: Merge from GCC: PR bootstrap/82856 * multilib.am: New file. From automake. config: Merge from GCC: PR bootstrap/82856 * math.m4, tls.m4: Use AC_LANG_SOURCE. zlib: Merge from GCC. PR bootstrap/82856 * Makefile.am: Include multilib.am. * Makefile.in: Regenerate.
2018-10-31[gdb/testsuite] get_valueof: Don't output value in test nameTom de Vries2-1/+5
The get_valueof outputs the value it has read as part of the test name. This causes test names to vary from run to run, and adds some noise when diffing test results. e.g.: -PASS: gdb.guile/scm-ports.exp: buffered: get valueof "$sp" (140737488343920) +PASS: gdb.guile/scm-ports.exp: buffered: get valueof "$sp" (140737488343968) -PASS: gdb.guile/scm-ports.exp: unbuffered: get valueof "$sp" (140737488343920) +PASS: gdb.guile/scm-ports.exp: unbuffered: get valueof "$sp" (140737488343968) This patch removes that, since it's probably not very useful. Tested on x86_64-linux. 2018-10-31 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (get_valueof): Don't output read value in test name.
2018-10-31Don't create got section while processing TLS Local Exec relocations.Renlin Li2-3/+5
For Local Exec TLS model, the offset of the variable from the thread pointer can be computed at static link time. This doesn't require GOT indirection. The initial change is a bad fix for a problem during TLS GD -> LE relaxation. The proper fix is to check whether _GLOBAL_OFFSET_TABLE_ is referenced, create got section if yes. And the fix is already in the repository. bfd/ 2018-10-31 Renlin Li <renlin.li@arm.com> * elfnn-aarch64.c (elfNN_aarch64_check_relocs): Don't create got section for Local Exec TLS model.
2018-10-31[PowerPC] Include nat/linux-ptrace.h in native targetsPedro Franco de Carvalho4-0/+10
Patch "[PowerPC] Add support for PPR and DSCR" used PTRACE_GETREGSET/SETREGSET without including the fallback definitions from "nat/linux-ptrace.h". Include this header to avoid breaking builds in systems that don't define them. gdb/ChangeLog: 2018-10-31 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * ppc-linux-nat.c: Include nat/linux-ptrace.h. gdb/gdbserver/ChangeLog: 2018-10-31 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * linux-ppc-low.c: Include nat/linux-ptrace.h.
2018-10-31gdb: Handle ICC's unexpected void return typeAndrew Burgess6-6/+222
I encountered a binary compiled with Intel's C Compiler (ICC) version 14.0.5.212, which seemed to contain some non-standard DWARF. The DWARF spec (V5 3.3.2) says: Debugging information entries for C void functions should not have an attribute for the return type. However, what I observed in the DWARF from this ICC compiled binary was this: ... <0><857>: Abbrev Number: 1 (DW_TAG_compile_unit) <858> DW_AT_comp_dir : (indirect string, offset: 0x48d): /tmp/ <85c> DW_AT_language : 1 (ANSI C) <85d> DW_AT_name : (indirect string, offset: 0x77c): filename.c <861> DW_AT_producer : (indirect string, offset: 0x520): Intel(R) C Intel(R) 64 Compiler ... <865> DW_AT_low_pc : 0x4378d0 <86d> DW_AT_high_pc : 0x4378f0 <875> DW_AT_stmt_list : 0xa37 ... <1><7ea>: Abbrev Number: 2 (DW_TAG_base_type) <7eb> DW_AT_byte_size : 0 <7ec> DW_AT_encoding : 5 (signed) <7ed> DW_AT_name : (indirect string, offset: 0x58f): void ... <1><7f1>: Abbrev Number: 3 (DW_TAG_subprogram) <7f2> DW_AT_decl_line : 268 <7f4> DW_AT_decl_column : 30 <7f5> DW_AT_decl_file : 1 <7f6> DW_AT_type : <0x7ea> <7fa> DW_AT_prototyped : 1 <7fb> DW_AT_name : (indirect string, offset: 0x761): function_foo <7ff> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x761): function_foo <803> DW_AT_low_pc : 0x4378a0 <80b> DW_AT_high_pc : 0x4378d0 <813> DW_AT_external : 1 ... So function 'function_foo' has void return type, but still has a DW_AT_type attribute for a 0 sized type called void. What was found was that when the 'finish' command was used to leave 'function_foo', GDB would crash. The problem is that in infcmd.c:print_return_value GDB tries to filter out void return types, by looking for the TYPE_CODE_VOID, this fails for the 'void' type as it has code TYPE_CODE_INT and GDB then tries to print the 'void' type. This eventually ends in a call to valprint.c:maybe_negate_by_bytes, however, the len (length) of the value being negated is 0, which is not detected or expected by this code, and invalid memory accesses occur, some of which might cause GDB to crash. The above DWARF was seen on version 14.0.5.212 of ICC. I have also tested ICC versions 18.0.2.199 and 17.0.7.259, on both of these versions, the DW_AT_type on the DW_TAG_subprogram has been removed, bringing ICC inline with the DWARF standard, and with the DWARF produced by GCC. I only have limited access to these specific versions of ICC so I am unable to get more specific details for when the generated DWARF became non-standard or when it was changed to be more inline with the DWARF standard. Further testing revealed additional places where ICC produced 'void' related DWARF that GDB struggles with. When I compiled code that contained a function with this signature: void funcx (void *arg); on ICC 17/18, I got the following DWARF (notice the void return type is now gone): ... <1><32>: Abbrev Number: 2 (DW_TAG_subprogram) <33> DW_AT_decl_line : 2 <34> DW_AT_decl_file : 1 <35> DW_AT_prototyped : 1 <36> DW_AT_name : (indirect string, offset: 0xc5): funcx <3a> DW_AT_MIPS_linkage_name: (indirect string, offset: 0xc5): funcx <3e> DW_AT_low_pc : 0x6dc <46> DW_AT_high_pc : 0x703 <4e> DW_AT_external : 1 <2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter) <50> DW_AT_decl_line : 2 <51> DW_AT_decl_file : 1 <52> DW_AT_type : <0x6a> <56> DW_AT_name : arg <5a> DW_AT_location : 2 byte block: 76 70 (DW_OP_breg6 (rbp): -16) ... <1><6a>: Abbrev Number: 5 (DW_TAG_pointer_type) <6b> DW_AT_type : <0x6f> <1><6f>: Abbrev Number: 6 (DW_TAG_base_type) <70> DW_AT_byte_size : 0 <71> DW_AT_encoding : 5 (signed) <72> DW_AT_name : (indirect string, offset: 0xcb): void ... However, the function argument 'arg' does still reference a 'void' type. This case doesn't seem as obviously non-standard as the previous one, but I think that the DWARF standard (V5 5.2) does suggest that the above is not the recommended approach. If we compare to the DWARF generated by GCC 7.3.1: ... <1><68>: Abbrev Number: 5 (DW_TAG_subprogram) <69> DW_AT_external : 1 <69> DW_AT_name : (indirect string, offset: 0x221): funcx <6d> DW_AT_decl_file : 1 <6e> DW_AT_decl_line : 2 <6f> DW_AT_prototyped : 1 <6f> DW_AT_low_pc : 0x400487 <77> DW_AT_high_pc : 0x22 <7f> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <81> DW_AT_GNU_all_call_sites: 1 <81> DW_AT_sibling : <0xa0> <2><85>: Abbrev Number: 6 (DW_TAG_formal_parameter) <86> DW_AT_name : arg <8a> DW_AT_decl_file : 1 <8b> DW_AT_decl_line : 2 <8c> DW_AT_type : <0xa0> <90> DW_AT_location : 2 byte block: 91 58 (DW_OP_fbreg: -40) ... <1><a0>: Abbrev Number: 7 (DW_TAG_pointer_type) <a1> DW_AT_byte_size : 8 ... Here we see that the DW_TAG_pointer_type doesn't reference any further type. This also seems out of line with the DWARF standard (which I think recommends using a DW_TAG_unspecified_type entry), however GDB does handle the GCC generated DWARF better. If we look at how GDB handles the DWARF from GCC, then we see this: (gdb) print *arg Attempt to dereference a generic pointer. While on the current HEAD of master dereferencing arg causes undefined behaviour which will likely crash GDB (for the same reason as was described above for the 'finish' case). On earlier versions of GDB the ICC DWARF would cause this: (gdb) print *arg $1 = 0 In this patch both the return type, and general variable/parameter type handling is fixed by transforming the synthetic void entries in the DWARF, the ones that look like this: <1><6f>: Abbrev Number: 6 (DW_TAG_base_type) <70> DW_AT_byte_size : 0 <71> DW_AT_encoding : 5 (signed) <72> DW_AT_name : (indirect string, offset: 0xcb): void into GDB's builtin void type. My criteria for performing the fix are: 1. Binary produced by any version of ICC, 2. We're producing an integer type, 3. The size is 0, and 4. The name is "void". I ignore the signed / unsigned nature of the integer. Potentially we could drop the ICC detection too, this should be a reasonably safe transformation to perform, however, I'm generally pretty nervous when it comes to modifying how the DWARF is parsed so, for now, I have restricted this to ICC only. I also added an assertion to maybe_negate_by_bytes. This is nothing to do with the actual fix, but should detect incorrect use of this function in the future, without relying on undefined behaviour to crash GDB. I added a new test that makes use the of the testsuite's DWARF generator. As it is tricky to create target independent tests that pass function parameters using the DWARF generator (as specifying the argument location is target specific) I have instead made use of a global variable void*. This still shows the issue. We already have a predicate in the DWARF parser to detect versions of ICC prior to 14, however, this issue was spotted on a later version. As a result I've added a new predicate that is true for any version of ICC. gdb/ChangeLog: * dwarf2read.c (struct dwarf2_cu): Add producer_is_icc field. (producer_is_icc): New function. (check_producer): Set producer_is_icc field on dwarf2_cu. (dwarf2_init_integer_type): New function. (read_base_type): Call dwarf2_init_integer_type instead of init_integer_type in all cases. (dwarf2_cu::dwarf2_cu): Initialise producer_is_icc field. * valprint.c (maybe_negate_by_bytes): Add an assertion that the LEN is greater than 0. gdb/testsuite/ChangeLog: * gdb.dwarf2/void-type.c: New file. * gdb.dwarf2/void-type.exp: New file.
2018-10-31[GAS][ARM] Fix ARMv8.1 AdvSIMD testismAndre Vieira2-1/+4
This test never used to test the output of objdump as the old 'error-output' check would exit after verifying the output in stdout and stderr from the assembler. Given the use of warning_output now, the objdump runs and expects its output to be verified. Assuming the correct disassembly of these instructions is tested elsewhere given we never tested them here, this patch removes the objdump run. gas/ChangeLog 2018-10-31 Andre Vieira <andre.simoesdiasvieira@arm.com> * testsuite/gas/arm/armv8-a+rdma-warning.d: Remove objdump execution.
2018-10-31[GAS][ARM] Fix UDF testismAndre Vieira2-23/+23
The old test never checked the objdump output since the 'error-output' directive would exit and thus never run objdump. When this test was changed to adhere to use the new warning_output we started to run objdump. The expected objdump output was old and had bitrotten, this fixes the layout, as the "disassembly" itself did not change. gas/ChangeLog 2018-10-31 Andre Vieira <andre.simoesdiasvieira@arm.com> * testsuite/gas/arm/udf.d: Update expected output.
2018-10-31[GAS][ARM] Fix failing Armv1 testAndre Vieira2-18/+23
This test has been failing for a while and it could be argued that since we started testing 'arm7t' here (and not Armv1) the test itself was wrong. So I changed the assembly to Armv1. Given the changes to objdump when "disassembling all" it seemed like a good idea to force the disassembly to 'armv2' instead and actually accept the disassembly of the 26-bit Architecture variants of tst, teq, cmn and cmp. gas/ChangeLog 2018-10-31 Andre Vieira <andre.simoesdiasvieira@arm.com> * testsuite/gas/arm/armv1.d: Assemble for Armv1 and disassemble for Armv2.
2018-10-31Automatic date update in version.inGDB Administrator1-1/+1
2018-10-30[src/erc32] Use ncurses instead of termcap on Cygwin tooJoel Sherrill3-10/+15
This removes a Cygwin-specific libtermcap hack that was dependent on the presence of one of the multiple alternative libraries. The one it was hard-coded to pick isn't included with Cygwin anymore. According to Corinna, libtermcap was removed from Cygwin a long time ago, and libncurses is used in Cygwin for a long time too. The fix is to make Cygwin use the same autoconf code to figure out the correct lib as any other target. sim/erc32/Changelog: 2018-10-30 Joel Sherrill <joel@rtems.org> * configure.ac: Remove the Cygwin-specific libtermcap.a hack and use the standard logic to determine which library to use. * configure: Regenerate.
2018-10-30Check return value of bfd_initTom Tromey2-1/+9
Alan recently added a way for BFD library users to check whether they were in fact loading a compatible version of BFD: https://sourceware.org/ml/binutils/2018-10/msg00198.html It seemed reasonable to me that gdb should do this check as well, in case someone is dynamically linking against BFD. Simon pointed out that an earlier version of the patch would cause a gdb crash if the test failed. This version works around this by lowering the call to bfd_init and adding a comment explaining where 'error' can safely be called in captured_main_1. gdb/ChangeLog 2018-10-30 Tom Tromey <tom@tromey.com> * main.c (captured_main_1): Check return value of bfd_init.
2018-10-29Remove relational operators from common/offset-type.hSergio Durigan Junior2-17/+6
This patch is a follow-up of: https://sourceware.org/ml/gdb-patches/2018-10/msg00601.html It removes the declaration of the relational operators for common/offset-type.h. As it turns out, these overloads are not being used when a new offset type is declared, because, according to Pedro Alves: I think the functions aren't called because they are templates, and thus the built-in (non-template) versions take precedence. If you make them non-templates, then they should be called. But, the built-ins are fine, so yeah, we can just remove the custom definitions. The patch also adjusts the comments on the code. No regressions introduced. gdb/ChangeLog: 2018-10-29 Sergio Durigan Junior <sergiodj@redhat.com> * common/offset-type.h (DEFINE_OFFSET_REL_OP): Delete. Adjust comments.
2018-10-30Automatic date update in version.inGDB Administrator1-1/+1
2018-10-29Revert "GDBSERVER: Listen on a unix domain (instead of TCP) socket if ↵Simon Marchi4-126/+47
requested." This reverts commit f19c7ff839d7a32ebb48482ae7d318fb46ca823d.
2018-10-29Revert "GDB: Document the unix::/path/to/socket of remote connection."Simon Marchi1-23/+1
This reverts commit 6d0f8100c1a3053c967bec716e34b65dd054cc39.
2018-10-29Revert "GDB: Fix documentation for invoking GDBSERVER"Simon Marchi1-44/+16
This reverts commit 0a163825df5e98ad55de13eb3d3534d875943047.
2018-10-29Revert "GDB: Remote target can now accept the form unix::/path/to/socket."Simon Marchi2-19/+4
This reverts commit 88f5cc8cf8606478832c7d0d7b74755f3f625015.
2018-10-29Revert "GDB: Only build for "unix:" connections if AF_LOCAL is supported."Simon Marchi5-44/+0
This reverts commit 98a17ece013cb94cd602496b9efb92b8816b3953.
2018-10-29Provide get_shell declaration in procfs.cRainer Orth2-4/+9
The Solaris build is currently broken: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual void procfs_target::create_inferior(const char*, const string&, char**, int)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3038:28: error: ‘get_shell’ was not declared in this scope const char *shell_file = get_shell (); ^~~~~~~~~ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3038:28: note: suggested alternative: ‘getusershell’ const char *shell_file = get_shell (); ^~~~~~~~~ getusershell The following patch fixes this. Tested on amd64-pc-solaris2.11. 2018-10-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> * procfs.c: Include common/pathstuff.h.
2018-10-29Report scripts and libraries searched for ld --traceAlan Modra6-14/+27
The idea of this change is to make -t output useful for users wanting to package all the object files involved in linking for a bug report. Something like the following should do the trick. gcc hello.c -save-temps -Wl,-t | xargs realpath | sort | uniq > files tar cJf test.tar.xz `cat files` * ldlang.c (load_symbols): When -t, print file names for script files and archives. * ldmain.c (trace_files): Make an int. (add_archive_element): Print archive elements only with multiple -t options, or when archive is thin. * ldmain.h (trace_files): Update. * ldmisc.c (vfinfo): Don't print both original path and path in sysroot. * lexsup.c (parse_args <t>): Increment trace_files.
2018-10-29Remove some ld --trace outputAlan Modra2-3/+9
This output really belongs in ld --verbose. * ldmain.c (main): Print emulation mode and "deleting executable" for --verbose, not --trace. (add_archive_element): Only print "no new IR symbols" for --verbose.
2018-10-29Simplify --sysroot=/Alan Modra2-9/+17
Prepending '/' to absolute paths doesn't gain us much, and results in the current implementation of --trace emitting silly path-in-sysroot output, eg. /lib/ld-linux-x86-64.so.2 (//lib/ld-linux-x86-64.so.2) * ldmain.c (get_sysroot): Return "" for "--sysroot=/".
2018-10-29Move struc-symbol.h to symbols.cAlan Modra31-326/+353
This file was never supposed to be widely used. The fact that it has found its way into many gas files led to bugs, typically when code expecting a symbolS* to point at a struct symbol is presented with a struct local_symbol. Also, commit 158184ac9e changed these structs in 2012 but didn't catch all places where symbol bsym was being used to test for a local_symbol. * Makefile.am (HFILES): Delete struc-symbol.h. * doc/internals.texi: Delete struc-symbol.h reference and out of date local symbol description. * struc-symbol.h: Delete. Move contents to.. * symbols.c: ..here. (symbol_on_chain, symbol_symbolS): New functions. * symbols.h (symbol_on_chain, symbol_symbolS): Declare. * cgen.c: Don't #include struc-symbol.h. (gas_cgen_parse_operand): Don't test for local_symbol using bsym, instead call symbol_symbolS. Use symbol_get_bfdsym. (weak_operand_overflow_check, make_right_shifted_expr): Use symbol accessors. * config/obj-coff.c: Don't #include struc-symbol.h. (GET_FILENAME_STRING): Delete. * config/obj-elf.c: Don't #include struc-symbol.h. (elf_file_symbol): Use symbol accessors. (elf_adjust_symtab): Call symbol_on_chain. * config/obj-evax.c: Don't #include struc-symbol.h. * config/tc-nds32.c: Likewise. * config/tc-rl78.c: Likewise. * config/tc-rx.c: Likewise. * config/tc-alpha.c: Likewise. (add_to_link_pool, s_alpha_comm): Use symbol accessors. * config/tc-arc.c: Don't #include struc-symbol.h. (arc_check_relocs): Use symbol accessors, testing gas symbol section rather than bfd symbol section. * config/tc-avr.c: Don't #include struc-symbol.h. (avr_patch_gccisr_frag): Use symbol accessors. * config/tc-bfin.c: Don't #include struc-symbol.h. (bfin_loop_beginend): Use symbol accessors. * config/tc-csky.c: Don't #include struc-symbol.h. (v2_work_movih, v2_work_ori): Use symbol accessors. Check for absolute symbol as well as O_constant. * config/tc-riscv.c: Don't #include struc-symbol.h. (riscv_pre_output_hook): Use symbol accessors. * config/tc-s390.c: Don't #include struc-symbol.h. (s390_literals): Use symbol accessors. * config/tc-score.c (s3_build_la_pic, s3_build_lwst_pic): Use symbol accessors. (s3_relax_branch_inst16, s3_relax_cmpbranch_inst32): Don't test symbol bsym. * config/tc-score7.c: Don't #include struc-symbol.h. (s7_build_la_pic, s7_build_lwst_pic): Use symbol accessors. (s7_b32_relax_to_b16): Don't test symbol bsym. * config/tc-sh.c: Don't #include struc-symbol.h. (insert_loop_bounds): Use symbol accessors. (sh_frob_section): Remove bogus symbol canonicalization. * config/tc-tic54x.c: Don't #include struc-symbol.h. (tic54x_bss): Use symbol accessors. * config/tc-tilegx.c: Don't #include struc-symbol.h. (emit_tilegx_instruction, tilegx_parse_name): Use symbol accessors. * config/tc-tilepro.c: Don't #include struc-symbol.h. (emit_tilepro_instruction, tilepro_parse_name): Use accessors. * config/tc-xtensa.c: Don't #include struc-symbol.h. (xg_assemble_vliw_tokens): Use symbol accessors. (xg_order_trampoline_chain): Likewise. * ehopt.c: Don't #include struc-symbol.h. (check_eh_frame): Correct local symbol test. Use symbol accessors. * write.c: Don't #include struc-symbol.h. (create_note_reloc, maybe_generate_build_notes): Use symbol accessors. * Makefile.in: Regenerate. * po/POTFILES.in: Regenerate.
2018-10-29ld -r script fixesAlan Modra16-35/+58
For ld -r, we generally set the VMA of sections to zero. This is done to make the output of ld -r most similar to that output by the assembler, which generally has sections starting at VMA zero. In some cases that covers for backend bugs which would mis-handle relocatable object files with non-zero section VMAs. This patch fixes a few sections that didn't have zero VMAs for ld -r. A missing zero on .note.gnu.build-id and .eh_frame_hdr doesn't matter much since these are linker generated symbols only output on final link, but it's good to be consistent. * Makefile.am (ei386beos.c, ei386go32.c): Correct dependencies. * Makefile.in: Regenerate. * scripttempl/elf.sc (.note.gnu.build-id, .eh_frame_hdr): Set address with ${RELOCATING-0}. * scripttempl/arclinux.sc: Likewise. * scripttempl/armbpabi.sc: Likewise. * scripttempl/avr.sc: Likewise. * scripttempl/elf64hppa.sc: Likewise. * scripttempl/elf_chaos.sc: Likewise. * scripttempl/elfarc.sc: Likewise. * scripttempl/elfxtensa.sc: Likewise. * scripttempl/mep.sc: Likewise. * scripttempl/nds32elf.sc: Likewise. * scripttempl/pru.sc: Likewise. * scripttempl/elf32msp430.sc: Likewise, and for other sections. * scripttempl/epiphany_4x4.sc: Similarly.
2018-10-29GDB: Only build for "unix:" connections if AF_LOCAL is supported.John Darrington5-0/+44
Commit f19c7ff839d7a32ebb48482ae7d318fb46ca823d added a new member to the prefixes array which included a use of the symbol AF_LOCAL. Unfortunately, not all systems declare this symbol. This change only compiles the "unix:" member if the system knows about AF_LOCAL. gdb/ChangeLog: * configure.ac: New test HAVE_AF_LOCAL * common/netstuff.c (parse_connection_spec) [prefixes]: Only compile "unix:" if HAVE_AF_LOCAL is true. * configure: regenerate. * config.in: regenerate.
2018-10-29Automatic date update in version.inGDB Administrator1-1/+1
2018-10-28gdb/riscv: Add back missing braces in riscv-linux-nat.cAndrew Burgess2-2/+9
In this commit: commit ee67fd7f3f6ca78eede2862e309c0bcf266bbd7e Date: Thu Oct 25 12:03:31 2018 +0100 gdb/riscv: Use correct regnum in riscv_linux_nat_target::fetch_registers I incorrectly removed a set of braces in violation of the GDB coding standard. This commit adds them back. gdb/ChangeLog: * riscv-linux-nat.c (riscv_linux_nat_target::fetch_registers): Add missing braces. No functional change.
2018-10-28Correct ChangeLogAlan Modra1-1/+1
generated by cgit v1.1 at 2024-12-28 16:58:17 +0000