aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-03Automatic date update in version.inGDB Administrator1-1/+1
2020-08-02Automatic date update in version.inGDB Administrator1-1/+1
2020-08-01Automatic date update in version.inGDB Administrator1-1/+1
2020-07-31gdb.base/coremaker2.c: Fix compilation problems for x86_64 -m32 multilibKevin Buettner2-7/+14
There are compilation warnings / errors when compiling coremaker2.c for the gdb.base/corefile2.exp tests. Here's the command to use on x86_64 linux: make check RUNTESTFLAGS="--target_board unix/-m32" \ TESTS="gdb.base/corefile2.exp" These are the warnings / errors - I've shortened the paths somewhat: gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main': gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 106 | addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 108 | if (addr <= (unsigned long long) buf_ro | ^ gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 109 | || addr >= (unsigned long long) buf_ro + sizeof (buf_ro)) | ^ gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 115 | mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ, | ^ gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 130 | addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 132 | if (addr <= (unsigned long long) buf_rw | ^ gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 133 | || addr >= (unsigned long long) buf_rw + sizeof (buf_rw)) | ^ gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 139 | mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ, | ^ These were fixed by changing unsigned long long to uintptr_t. Tested on either rawhide or Fedora 32 with architectures: x86_64, x86_64/-m32, aarch64, s390x, and ppc64le. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c: Change all uses of 'unsigned long long' to 'uintptr_t' (inttypes.h): Include.
2020-07-31Fix gdb.base/corefile2.exp test case for ppc64leKevin Buettner2-12/+22
It turns out that the recently added gdb.base/corefile2.exp test won't run on ppc64le linux. The test case fails the internal checks which ensure that a mmap'd region can be placed within the statically allocated regions buf_rw[] and buf_ro[]. ppc64le linux apparently has 64k pages, which is much larger than the 24k regions originally allocated for buf_rw[] and buf_ro[]. This patch increases the size of each region to 256 KiB. Tested on either rawhide or Fedora 32 for these architectures: x86_64, x86_64/-m32, ppc64le, aarch64, and s390x. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB. (C5_24k): Delete. (C5_8k, C5_64k, C5_256k): New macros. (buf_ro): Allocate 256 KiB of initialized data.
2020-07-31ld: Add -fno-lto to linker testsH.J. Lu7-46/+100
LTO can be used to build binutils with $ CC="gcc -flto -ffat-lto-objects -Wl,--as-needed" CXX="g++ -flto -ffat-lto-objects -Wl,--as-needed" .../configure But not all linker tests are compatible with LTO. Pass -fno-lto to CC to disable LTO on linker tests by default. -flto is passed explicitly to CC in linker LTO tests. * testsuite/ld-elf/indirect.exp: Append -fno-lto to CC. * testsuite/ld-elfvers/vers.exp: Likewise. * testsuite/ld-elfweak/elfweak.exp: Likewise. * testsuite/ld-ifunc/ifunc.exp: Likewise. * testsuite/ld-plugin/lto.exp (no_lto): New. Add $no_lto to build pr15146c.so. * testsuite/lib/ld-lib.exp (at_least_gcc_version): Filter out -Wl,xxx options. (check_gcc_plugin_enabled): Likewise. (run_ld_link_exec_tests): Prepend -fno-lto to $cflags. (run_cc_link_tests): Likewise.
2020-07-31PR26314, Linking LTO objects with symbols from static and shared librariesAlan Modra2-5/+19
gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,. All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so not being found needed when loading the IR objects. That's problem number one: We exclude IR references when deciding a shared library is needed. See PR15146. Thus none of the libbfd.so symbols are loaded before libiberty.a is scanned, and libbfd.so contains copies of libiberty.a functions. We ought to be using the libbfd.so copies rather than extracting them from the archive (an object is extracted even to satisfy IR symbols). After lto recompilation, libbfd.so is of course found to be needed and loaded. But that causes more problems. The lto recompilation didn't see symbol references from libbfd.so and variables like _xexit_cleanup are made local in the recompiled objects. Oops, two copies of them. Finally, those silly undefined symbols in the lto output debug files, combined with definitions in both libbfd.so and IR objects result in IR symbols being made dynamic. The main fix here is to revert the PR15146 change to elf_link_add_object_symbols. PR 26314 * elflink.c (bfd_elf_link_record_dynamic_symbol): Don't allow IR symbols to become dynamic. (elf_link_add_object_symbols): Don't exclude IR symbols when deciding whether an as-needed shared library is needed.
2020-07-31ARC: Fix ld/pr24511 testShahab Vahedi2-8/+21
With this patch, ld/pr24511 test passes for ARC. At first glance, the test was failing because the order of "__init_array_start" and "__fini_array_start" weak symbols were reversed: $ nm -n dump.out expected output | real output 00002104 D __init_array_start | 00002104 D __fini_array_start 0000210c D __fini_array_start | 00002104 D __init_array_start The order of the symbols are different as a side effect of both symbols being mapped to the _same_ address (0x2104). Looking further into the mapping logs [1] revealed that the linker script must consider all instances of ".init_array" (in other words ".init_array.*") inside its relevant section. Same logic holds for ".fini_array". Therefore, adding "KEEP (*(SORT(.init_array.*)))" to the linker script, along with the one for ".finit_array.*", resolved the problem. While at it, I took the liberty of refactoring the script a little bit and made those pieces of script macros. [1] Linker's mapping for the relevant part of the test --------------------------------------------------------------- .init_array 0x2104 0x0 0x2104 PROVIDE (__init_array_start = .) *(.init_array) [!provide] PROVIDE (__init_array_end = .) .fini_array 0x2104 0x0 0x2104 PROVIDE (__fini_array_start = .) *(.fini_array) [!provide] PROVIDE (__fini_array_end = .) .data 0x2104 0x0 *(.data .data.* .gnu.linkonce.d.*) .data 0x2104 0x0 pr24511.o .init_array.01000 0x2104 0x8 .init_array.01000 0x2104 0x8 pr24511.o .fini_array.01000 0x210c 0x8 .fini_array.01000 0x210c 0x8 pr24511.o --------------------------------------------------------------- ld: * scripttempl/elfarc.sc (.init_array): Keep ".init_array.*". (.fini_array): Keep ".fini_array.*". Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
2020-07-31Automatic date update in version.inGDB Administrator1-1/+1
2020-07-30x86: Add {disp16} pseudo prefixH.J. Lu16-44/+252
Use Prefix_XXX for pseudo prefixes. Add {disp16} pseudo prefix and replace {disp32} pseudo prefix with {disp16} in 16-bit mode test. Check invalid {disp16}/{disp32} pseudo prefixes. gas/ PR gas/26305 * config/tc-i386.c (_i386_insn::disp_encoding): Add disp_encoding_16bit. (parse_insn): Check Prefix_XXX for pseudo prefixes. Handle {disp16}. (build_modrm_byte): Handle {disp16}. (i386_index_check): Check invalid {disp16} and {disp32} pseudo prefixes. * doc/c-i386.texi: Update {disp32} documentation and document {disp16}. * testsuite/gas/i386/i386.exp: Run x86-64-inval-pseudo. * testsuite/gas/i386/inval-pseudo.s: Add {disp32}/{disp16} tests. * testsuite/gas/i386/pseudos.s: Add {disp8}/{disp32} vmovaps tests with 128-byte displacement. Add {disp16} tests. * testsuite/gas/i386/x86-64-pseudos.s: Add {disp8}/{disp32} vmovaps test. Add (%r13)/(%r13d) tests. * testsuite/gas/i386/x86-64-inval-pseudo.l: New file. * testsuite/gas/i386/x86-64-inval-pseudo.s: Likewise. * testsuite/gas/i386/inval-pseudo.l: Updated. * testsuite/gas/i386/pseudos.d: Likewise. * testsuite/gas/i386/x86-64-pseudos.d: Likewise. opcodes/ PR gas/26305 * i386-opc.h (Prefix_Disp8): New. (Prefix_Disp16): Likewise. (Prefix_Disp32): Likewise. (Prefix_Load): Likewise. (Prefix_Store): Likewise. (Prefix_VEX): Likewise. (Prefix_VEX3): Likewise. (Prefix_EVEX): Likewise. (Prefix_REX): Likewise. (Prefix_NoOptimize): Likewise. * i386-opc.tbl: Use Prefix_XXX on pseudo prefixes. Add {disp16}. * i386-tbl.h: Regenerated.
2020-07-30gdb: handle non-const property types in ada_modulus (PR ada/26318)Simon Marchi2-1/+14
PR 26318 shows that running `maint print symbols` on an Ada binary, compiled with an Ada distribution that includes debug info for the standard library, triggers this assertion: /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed. The problem is in particular when printing type `system__object_reader__decoded_ada_name__TTdecodedSP1___XDL_0`, which has a dynamic high bound (PROP_LOCLIST kind). When printing a concrete value of this type, this type gets resolved to a type with a constant high bound, so ada_modulus can return this constant value. However, when printing the dynamic range type on its own, such as with `maint print symbols`, the high bound is still of kind PROP_LOCLIST. When ada_modulus tries to access the property as a const value, the assert triggers. There's no sensible numerical value to return in this case. Ideally, ada_modulus would return something to the caller indicating that the value is dynamic and therefore can't be returned as an integer. The callers would handle it, for example `maint print symbols` would say that the high bound of the type is dynamic. However, this patch implements the simpler fix of returning 0 in that case. It kind of restores the previous behavior of before we validated the dynamic property kind in the getters, where we would just return whatever random integer value was in `const_val`. Except now it's consistently 0. This is what we had before we added dynamic property getters: $ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1' typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 107820865988257; and this is what we have now: $ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1' typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 0; The value 107820865988257 is the `baton` field of the property's union interpreted as an integer, so a bogus value. gdb/ChangeLog: PR ada/26318 * ada-lang.c (ada_modulus): Return 0 if property is not of const kind. Change-Id: I3f6d343a9c3cd7cd62a4fc591943a43541223d50
2020-07-30gdb/breakpoint: refactor 'set_breakpoint_condition'Tankut Baris Aktemur2-20/+13
Apply minor refactoring to 'set_breakpoint_condition'. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Do minor refactoring.
2020-07-30gdb/breakpoint: set the condition exp after parsing the condition successfullyTankut Baris Aktemur4-21/+139
In 'set_breakpoint_condition', GDB resets the condition expressions before parsing the condition input by the user. This leads to the problem of losing the condition expressions if the new condition does not parse successfully and is thus rejected. For instance: $ gdb ./test Reading symbols from ./test... (gdb) start Temporary breakpoint 1 at 0x114e: file test.c, line 4. Starting program: test Temporary breakpoint 1, main () at test.c:4 4 int a = 10; (gdb) break 5 Breakpoint 2 at 0x555555555155: file test.c, line 5. Now define a condition that would evaluate to false. Next, attempt to overwrite that with an invalid condition: (gdb) cond 2 a == 999 (gdb) cond 2 gibberish No symbol "gibberish" in current context. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000555555555155 in main at test.c:5 stop only if a == 999 It appears as if the bad condition is successfully rejected. But if we resume the program, we see that we hit the breakpoint although the condition would evaluate to false. (gdb) continue Continuing. Breakpoint 2, main () at test.c:5 5 a = a + 1; /* break-here */ Fix the problem by not resetting the condition expressions before parsing the condition input. Suppose the fix is applied. A similar problem could occur if the condition is valid, but has "junk" at the end. In this case, parsing succeeds, but an error is raised immediately after. It is too late, though; the condition expression is already updated. For instance: $ gdb ./test Reading symbols from ./test... (gdb) start Temporary breakpoint 1 at 0x114e: file test.c, line 4. Starting program: test Temporary breakpoint 1, main () at test.c:4 4 int a = 10; (gdb) break 5 Breakpoint 2 at 0x555555555155: file test.c, line 5. (gdb) cond 2 a == 999 (gdb) cond 2 a == 10 if Junk at end of expression (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000555555555155 in main at test.c:5 stop only if a == 999 (gdb) c Continuing. Breakpoint 2, main () at test.c:5 5 a = a + 1; /* break-here */ (gdb) We should not have hit the breakpoint because the condition would evaluate to false. Fix this problem by updating the condition expression of the breakpoint after parsing the input successfully and checking that there is no remaining junk. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Update the condition expressions after checking that the input condition string parses successfully and does not contain junk at the end. gdb/testsuite/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/condbreak-bad.exp: Extend the test with scenarios that attempt to overwrite an existing condition with a condition that fails parsing and also with a condition that parses fine but contains junk at the end.
2020-07-30gdb/breakpoint: do not update the condition string if parsing the condition ↵Tankut Baris Aktemur5-8/+83
fails The condition of a breakpoint can be set with the 'cond' command. If the condition has errors that make it problematic to evaluate, it appears like GDB rejects the condition, but updates the breakpoint's condition string, which causes incorrect/unintuitive behavior. For instance: $ gdb ./test Reading symbols from ./test... (gdb) break 5 Breakpoint 1 at 0x1155: file test.c, line 5. (gdb) cond 1 gibberish No symbol "gibberish" in current context. At this point, it looks like the condition was rejected. But "info breakpoints" shows the following: (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000001155 in main at test.c:5 stop only if gibberish Running the code gives the following behavior, where re-insertion of the breakpoint causes failures. (gdb) run Starting program: test warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. [Inferior 1 (process 19084) exited normally] (gdb) This broken behavior occurs because GDB updates the condition string of the breakpoint *before* checking that it parses successfully. When parsing fails, the update has already taken place. Fix the problem by updating the condition string *after* parsing the condition. We get the following behavior when this patch is applied: $ gdb ./test Reading symbols from ./test... (gdb) break 5 Breakpoint 1 at 0x1155: file test.c, line 5. (gdb) cond 1 gibberish No symbol "gibberish" in current context. (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000001155 in main at test.c:5 (gdb) run Starting program: test Breakpoint 1, main () at test.c:5 5 a = a + 1; /* break-here */ (gdb) c Continuing. [Inferior 1 (process 15574) exited normally] (gdb) A side note: The problem does not occur if the condition is given at the time of breakpoint definition, as in "break 5 if gibberish", because the parsing of the condition fails during symtab-and-line creation, before the breakpoint is created. Finally, the code included the following comment: /* I don't know if it matters whether this is the string the user typed in or the decompiled expression. */ This comment did not make sense to me because the condition string is the user-typed input. The patch updates this comment, too. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Update the condition string after parsing the new condition successfully. gdb/testsuite/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/condbreak-bad.c: New test. * gdb.base/condbreak-bad.exp: New file.
2020-07-30aarch64: set sh_entsize of .plt to 0Szabolcs Nagy2-6/+12
On aarch64 the first PLT entry is 32 bytes, subsequent entries are 16 bytes by default but can be 24 bytes with BTI or with PAC-PLT. sh_entsize of .plt was set to the PLT entry size, so in some cases sh_size % sh_entsize != 0, which breaks some tools. Note that PLT0 (and the TLSDESC stub code which is also in the PLT) were historically not padded up to meet the sh_size requirement, but to ensure that PLT stub code is aligned on cache lines. Similar layout is present on other targets too which just happens to make sh_size a multiple of sh_entsize and it is not expected that sh_entsize of .plt is used for anything. This patch sets sh_entsize of .plt to 0: the section does not hold a table of fixed-size entries so other values are not conforming in principle to the ELF spec. bfd/ChangeLog: PR ld/26312 * elfnn-aarch64.c (elfNN_aarch64_init_small_plt0_entry): Set sh_entsize to 0. (elfNN_aarch64_finish_dynamic_sections): Remove sh_entsize setting.
2020-07-30[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-4.8Tom de Vries3-6/+32
When running test-case gdb.fortran/info-modules.exp with gfortran 4.8.5, I get: ... FAIL: gdb.fortran/info-modules.exp: info module functions: \ check for entry 'info-types.f90', '35', \ 'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);' FAIL: gdb.fortran/info-modules.exp: info module functions -m mod1: \ check for entry 'info-types.f90', '35', \ 'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);' FAIL: gdb.fortran/info-modules.exp: info module variables: \ check for entry 'info-types.f90', '(35)?', \ 'Type m1t1 mod1::__def_init_mod1_M1t1;' FAIL: gdb.fortran/info-modules.exp: info module variables: \ check for entry 'info-types.f90', '(35)?', \ 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;' ... With gfortran 7.5.0, we have: ... $ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1" <286> DW_AT_name : __def_init_mod1_M1t1 <29f> DW_AT_name : __vtype_mod1_M1t1 <3de> DW_AT_name : __copy_mod1_M1t1 $ ... but with gfortran 4.8.5: ... $ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1" $ ... Fix this by allowing these module functions and variables to be missing. Tested on x86_64-linux with gcc 4.8.5 and gcc 7.5.0. gdb/testsuite/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> * lib/sym-info-cmds.exp (GDBInfoModuleSymbols::check_entry_1): Factor out of ... (GDBInfoModuleSymbols::check_entry): ... here. (GDBInfoModuleSymbols::check_optional_entry): New proc. * gdb.fortran/info-modules.exp: Use check_optional_entry for entries related to __def_init_mod1_M1t1 / __vtype_mod1_M1t1 / __copy_mod1_M1t1.
2020-07-30Strange - my previous commit to as.c to set the default dwarf level to 3 ↵Nick Clifton1-2/+3
seems to have disappeared. So here is the commit again.
2020-07-30Default to DWARF level 3 for the assembler.Nick Clifton1-1/+1
* as.c (dwarf_level): Initialise to 3 in case this is not set on the command line.
2020-07-30Unify Solaris procfs and largefile handlingRainer Orth52-902/+1155
GDB currently doesn't build on 32-bit Solaris: * On Solaris 11.4/x86: In file included from /usr/include/sys/procfs.h:26, from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24: /usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment" #error "Cannot use procfs in the large file compilation environment" ^~~~~ * On Solaris 11.3/x86 there are several more instances of this. The interaction between procfs and large-file support historically has been a royal mess on Solaris: * There are two versions of the procfs interface: ** The old ioctl-based /proc, deprecated and not used any longer in either gdb or binutils. ** The `new' (introduced in Solaris 2.6, 1997) structured /proc. * There are two headers one can possibly include: ** <procfs.h> which only provides the structured /proc, definining _STRUCTURED_PROC=1 and then including ... ** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based /proc, but provides structured /proc if _STRUCTURED_PROC == 1. * procfs and the large-file environment didn't go well together: ** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit compilations when the large-file environment was active (_FILE_OFFSET_BITS == 64). ** In both Solaris 11.4 and Illumos, this restriction was lifted for structured /proc. So one has to be careful always to define _STRUCTURED_PROC=1 when testing for or using <sys/procfs.h> on Solaris. As the errors above show, this isn't always the case in binutils-gdb right now. Also one may need to disable large-file support for 32-bit compilations on Solaris. config/largefile.m4 meant to do this by wrapping the AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding ACX_LARGEFILE. Unfortunately the macro doesn't always succeed because it neglects the _STRUCTURED_PROC part. To make things even worse, since GCC 9 g++ predefines _FILE_OFFSET_BITS=64 on Solaris. So even if largefile.m4 deciced not to enable large-file support, this has no effect, breaking the gdb build. This patch addresses all this as follows: * All tests for the <sys/procfs.h> header are made with _STRUCTURED_PROC=1, the definition going into the various config.h files instead of having to make them (and sometimes failing) in the affected sources. * To cope with the g++ predefine of _FILE_OFFSET_BITS=64, -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables. It had been far easier to have just #undef _FILE_OFFSET_BITS in config.h, but unfortunately such a construct in config.in is commented by config.status irrespective of indentation and whitespace if large-file support is disabled. I found no way around this and putting the #undef in several global headers for bfd, binutils, ld, and gdb seemed way more invasive. * Last, the applicability check in largefile.m4 was modified only to disable largefile support if really needed. To do so, it checks if <sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined. If it doesn't, the disabling only happens if gdb exists in-tree and isn't disabled, otherwise (building binutils from a tarball), there's no conflict. What initially confused me was the check for $plugins here, which originally caused the disabling not to take place. Since AC_PLUGINGS does enable plugin support if <dlfcn.h> exists (which it does on Solaris), the disabling never happened. I could find no explanation why the linker plugin needs large-file support but thought it would be enough if gld and GCC's lto-plugin agreed on the _FILE_OFFSET_BITS value. Unfortunately, that's not enough: lto-plugin uses the simple-object interface from libiberty, which includes off_t arguments. So to fully disable large-file support would mean also disabling it in libiberty and its users: gcc and libstdc++-v3. This seems highly undesirable, so I decided to disable the linker plugin instead if large-file support won't work. The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to predefined _FILE_OFFSET_BITS=64). Also regtested on amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4), x86_64-pc-linux-gnu and i686-pc-linux-gnu. config: * largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>: Check for <sys/procfs.h> incompatilibity with large-file support on Solaris. Only disable large-file support and perhaps plugins if needed. Set, substitute LARGEFILE_CPPFLAGS if so. bfd: * bfd.m4 (BFD_SYS_PROCFS_H): New macro. (BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H. Don't define _STRUCTURED_PROC. (BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise. * elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define. * configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * configure, config.in: Regenerate. * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. binutils: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gas: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gdb: * proc-api.c (_STRUCTURED_PROC): Don't define. * proc-events.c: Likewise. * proc-flags.c: Likewise. * proc-why.c: Likewise. * procfs.c: Likewise. * Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * configure, config.in: Regenerate. gdbserver: * configure, config.in: Regenerate. gdbsupport: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * Makefile.in: Regenerate. * configure, config.in: Regenerate. gnulib: * configure.ac: Run ACX_LARGEFILE before gl_EARLY. * configure: Regenerate. gprof: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate. ld: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate.
2020-07-30x86: Pass --gdwarf-3 to assemblerH.J. Lu14-11/+31
Pass --gdwarf-3 to assembler for commit 4d8ee860737005517be588f4771c358593fa421c Author: Nick Clifton <nickc@redhat.com> Date: Thu Jul 30 08:39:14 2020 +0100 Prevent the generation of DWARF level 0 line number tables... binutils/ * testsuite/binutils-all/i386/compressed-1a.d: Pass --gdwarf-3 to assembler. * testsuite/binutils-all/i386/compressed-1b.d: Likewise. * testsuite/binutils-all/i386/compressed-1c.d: Likewise. * testsuite/binutils-all/x86-64/compressed-1a.d: Likewise. * testsuite/binutils-all/x86-64/compressed-1b.d: Likewise. * testsuite/binutils-all/x86-64/compressed-1c.d: Likewise. gas/ * testsuite/gas/elf/dwarf2-3.d:Pass --gdwarf-3 to assembler. * testsuite/gas/elf/dwarf2-5.d: Likewise. * testsuite/gas/i386/dw2-compress-3a.d: Likewise. * testsuite/gas/i386/dw2-compress-3b.d: Likewise. * testsuite/gas/i386/dw2-compressed-3a.d: Likewise. * testsuite/gas/i386/dw2-compressed-3b.d: Likewise.
2020-07-30elf: Add sym_cache to elf_link_hash_tableH.J. Lu31-340/+326
Since many ELF backends have sym_cache to their link hash tables, add sym_cache to elf_link_hash_table. Also use sdynbss and srelbss in elf_link_hash_table. * elf-bfd.h (sym_cache): Moved before elf_link_hash_table. (elf_link_hash_table): Add sym_cache. * elf32-arm.c (elf32_arm_link_hash_table): Remove sym_cache. (elf32_arm_check_relocs): Updated. (elf32_arm_size_dynamic_sections): Likewise. * elf32-bfin.c (bfin_link_hash_table): Removed. (bfin_link_hash_newfunc): Updated. (bfin_hash_table): Removed. * elf32-csky.c (csky_elf_link_hash_table): Remove sym_cache. (csky_elf_check_relocs): Updated. * elf32-hppa.c (elf32_hppa_link_hash_table): Remove sym_cache. (elf32_hppa_check_relocs): Updated. * elf32-i386.c (elf_i386_tls_transition): Updated. (elf_i386_convert_load_reloc): Likewise. (elf_i386_check_relocs): Likewise. * elf32-m32r.c (elf_m32r_link_hash_table): Removed. (m32r_elf_hash_table): Updated. (m32r_elf_link_hash_table_create): Likewise. (m32r_elf_create_dynamic_sections): Likewise. (m32r_elf_adjust_dynamic_symbol): Likewise. (allocate_dynrelocs): Likewise. (m32r_elf_size_dynamic_sections): Likewise. (m32r_elf_relocate_section): Likewise. (m32r_elf_finish_dynamic_symbol): Likewise. (m32r_elf_check_relocs): Likewise. * elf32-m68hc1x.h (m68hc11_elf_link_hash_table): Remove sym_cache. * elf32-m68k.c (elf_m68k_link_hash_table): Likewise. (elf_m68k_check_relocs): Updated. * elf32-metag.c (elf_metag_link_hash_table): Remove sym_cache. (elf_metag_check_relocs): Updated. * elf32-microblaze.c (elf32_mb_link_hash_table): Remove sym_sec. (microblaze_elf_check_relocs): Updated. * elf32-nds32.c (nds32_elf_link_hash_table_create): Likewise. (nds32_elf_create_dynamic_sections): Likewise. (nds32_elf_adjust_dynamic_symbol): Likewise. (nds32_elf_check_relocs): Likewise. * elf32-nds32.h (elf_nds32_link_hash_table): Remove sdynbss, srelbss and aym_cache. * elf32-nios2.c (elf32_nios2_link_hash_table): Remove sym_cache. (nios2_elf32_check_relocs): Updated. * elf32-or1k.c (elf_or1k_link_hash_table): Remove sym_sec. (or1k_elf_check_relocs): Updated. * elf32-ppc.c (ppc_elf_check_relocs): Remove sym_cache. (ppc_elf_check_relocs): Updated. * elf32-s390.c (elf_s390_link_hash_table): Remove sym_cache. (elf_s390_check_relocs): Updated. (elf_s390_finish_dynamic_sections): Likewise. * elf32-sh.c (elf_sh_link_hash_table): Remove sdynbss, srelbss and aym_cache. (sh_elf_create_dynamic_sections): Updated. (sh_elf_adjust_dynamic_symbol): Likewise. (sh_elf_size_dynamic_sections): Likewise. (sh_elf_check_relocs): Likewise. * elf32-tic6x.c (elf32_tic6x_link_hash_table): Remove sym_cache. (elf32_tic6x_check_relocs): Updated. * elf32-tilepro.c (tilepro_elf_link_hash_table): Removed. (tilepro_elf_hash_table): Updated. (tilepro_elf_link_hash_table_create): Likewise. (tilepro_elf_check_relocs): Likewise. (tilepro_elf_adjust_dynamic_symbol): Likewise. (allocate_dynrelocs): Likewise. (tilepro_elf_size_dynamic_sections): Likewise. (tilepro_elf_relocate_section): Likewise. (tilepro_elf_finish_dynamic_symbol): Likewise. (tilepro_finish_dyn): Likewise. (tilepro_elf_finish_dynamic_sections): Likewise. * elf64-ppc.c (ppc_link_hash_table): Remove sym_cache. (ppc64_elf_before_check_relocs): Updated. (ppc64_elf_check_relocs): Likewise. * elf64-s390.c (elf_s390_link_hash_table): Remove sym_cache. (elf_s390_check_relocs): Updated. (elf_s390_relocate_section): Likewise. (elf_s390_finish_dynamic_sections): Likewise. * elf64-x86-64.c (elf_x86_64_tls_transition): Likewise. (elf_x86_64_check_relocs): Likewise. * elfnn-aarch64.c (elf_aarch64_link_hash_table): Remove sym_cache. (elfNN_aarch64_check_relocs): Updated. * elfnn-riscv.c (riscv_elf_link_hash_table): Remove sym_cache. (riscv_elf_check_relocs): Updated. * elfxx-mips.c (mips_elf_link_hash_table): Remove sym_cache. (mips_elf_resolve_got_page_ref): Updated. * elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Likewise. * elfxx-sparc.h (_bfd_sparc_elf_link_hash_table): Remove sym_cache. * elfxx-tilegx.c (tilegx_elf_link_hash_table): Likewise. (tilegx_elf_check_relocs): Updated. * elfxx-x86.h (elf_x86_link_hash_table): Remove sym_cache.
2020-07-30[gdb/testsuite] Fix gdb.fortran/ptype-on-functions.exp with gcc-4.8Tom de Vries2-2/+7
When running test-case gdb.fortran/ptype-on-functions.exp with gfortran 4.8.5, we run into: ... (gdb) ptype some_module::get_number^M type = integer(kind=4) (Type __class_some_module_Number)^M (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::get_number ptype some_module::set_number^M type = void (Type __class_some_module_Number, integer(kind=4))^M (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::set_number ... The test-case pattern expects a "_t" suffix on "__class_some_module_Number". The difference is caused by a gcc commit 073afca6884 'class.c (gfc_build_class_symbol): Append "_t" to target class names to make the generated type names unique' which has been present since gcc 4.9.0. Fix the pattern by optionally matching the _t suffix. Tested on x86_64-linux, with gfortran 4.8.5 and 7.5.0. gdb/testsuite/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> * gdb.fortran/ptype-on-functions.exp: Make "_t" suffix on "__class_some_module_Number_t" optional.
2020-07-30Prevent the generation of DWARF level 0 line number tables...Nick Clifton2-1/+6
* as.c (dwarf_level): Initialise to 4 in case this is not set on the command line.
2020-07-30[gdb/build] Fix Wmaybe-uninitialized in gdb/ui-style.hTom de Vries2-2/+14
When building CFLAGS/CXXFLAGS="-O2 -g -Wall" and gcc 4.8.5, we run into: ... src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +8)' \ may be used uninitialized in this function [-Wmaybe-uninitialized] src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +9)' \ may be used uninitialized in this function [-Wmaybe-uninitialized] src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +10)' \ may be used uninitialized in this function [-Wmaybe-uninitialized] ... The root cause is that the data members of class color, nested in struct ui_file_style in gdb/ui-style.h: ... bool m_simple; int m_value; uint8_t m_red, m_green, m_blue; ... are only partially initialized by this constructor: ... color (int c) : m_simple (true), m_value (c) { gdb_assert (c >= -1 && c <= 255); } ... but the default copy constructor will copy all the fields. The member m_simple acts as a discriminant, to indicate which other members are valid: - m_value (with m_simple == true) - m_red, m_green, m_blue (with m_simple == false) So, we don't need storage for both m_value and m_red/m_green/m_blue at the same time. Fix this by wrapping the respective members in a union: ... bool m_simple; union { int m_value; struct { uint8_t m_red, m_green, m_blue; }; }; ... which also fixes the warning. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> PR build/26320 * ui-style.h (struct ui_file_style::color): Wrap m_value and m_red/m_green/m_blue in a union.
2020-07-30Automatic date update in version.inGDB Administrator1-1/+1
2020-07-29Run `autoreconf -vf` throughoutSimon Marchi12-606/+32
I ran for i in $(find . -name configure.ac); do pushd $(dirname $i); autoreconf -vf; popd; done to re-generate all automake/autoconf files throughout the repo (with upstream autoconf 2.69 and automake 1.15.1). These were the changes that came out. I am pushing this as obvious. libdecnumber/ChangeLog: * aclocal.m4, configure: Re-generate. sim/bfin/ChangeLog: * aclocal.m4, configure: Re-generate. sim/erc32/ChangeLog: * configure: Re-generate. sim/mips/ChangeLog: * configure: Re-generate. sim/testsuite/ChangeLog: * configure: Re-generate. Change-Id: I97335c09972d25cc5f6fd8da4db4ffe4a0348787
2020-07-29MIPS: Make the IRIX naming of local section symbols consistentMaciej W. Rozycki34-5/+354
Make the MIPS/IRIX naming of local section symbols consistent between files produced by generic ELF code and ELF linker code, complementing commit 174fd7f95561 ("New bfd elf hook: force naming of local section symbols"), <https://sourceware.org/ml/binutils/2004-02/msg00072.html>. Local section symbols have no names in the standard ELF gABI, however the lack of a name causes problems with IRIX's MIPSpro linker. To work around the issue we give them names, however we do that in generic ELF code only, based on what the `elf_backend_name_local_section_symbols' hook returns if present. That makes objects created by GAS or `objdump' work correctly, however not ones created by `ld -r'. That would not normally cause issues with IRIX systems using GAS and `objdump' only with the MIPSpro linker, however if GNU LD was used for whatever reason in producing objects later fed to IRIX's MIPSpro linker, then things would break. Modify ELF linker code accordingly then, using the same hook. Adjust the `ld-elf/64ksec-r' test accordingly so that it also accepts a section symbol with a name. Also modify the hook itself so that only actual ET_REL objects have names assigned to local section symbols. Other kinds of ELF files are not ever supposed to be relocated with the MIPSpro linker, so we can afford producing more standard output. Add suitable GAS, LD and `objcopy' test cases to the relevant testsuites to keep these tools consistently verified. This change also fixes: FAIL: objcopy executable (pr25662) across MIPS targets using the IRIX compatibility mode. bfd/ * elflink.c (bfd_elf_final_link): Give local symbols a name if so requested. * elfxx-mips.c (_bfd_mips_elf_name_local_section_symbols): Only return TRUE if making ET_REL output. binutils/ * testsuite/binutils-all/mips/global-local-symtab-sort-o32.d: New test. * testsuite/binutils-all/mips/global-local-symtab-sort-o32t.d: New test. * testsuite/binutils-all/mips/global-local-symtab-sort-n32.d: New test. * testsuite/binutils-all/mips/global-local-symtab-sort-n32t.d: New test. * testsuite/binutils-all/mips/global-local-symtab-sort-n64.d: New test. * testsuite/binutils-all/mips/global-local-symtab-sort-n64t.d: New test. * testsuite/binutils-all/mips/global-local-symtab-final-o32.d: New test. * testsuite/binutils-all/mips/global-local-symtab-final-n32.d: New test. * testsuite/binutils-all/mips/global-local-symtab-final-n64.d: New test. * testsuite/binutils-all/mips/mips.exp: Run the new tests. gas/ * testsuite/gas/mips/global-local-symtab-sort-o32.d: New test. * testsuite/gas/mips/global-local-symtab-sort-o32t.d: New test. * testsuite/gas/mips/global-local-symtab-sort-n32.d: New test. * testsuite/gas/mips/global-local-symtab-sort-n32t.d: New test. * testsuite/gas/mips/global-local-symtab-sort-n64.d: New test. * testsuite/gas/mips/global-local-symtab-sort-n64t.d: New test. * testsuite/gas/mips/mips.exp: Run the new tests. ld/ * testsuite/ld-elf/sec64k.exp: Also accept a section symbol with a name. * testsuite/ld-mips-elf/global-local-symtab-sort-o32.d: New test. * testsuite/ld-mips-elf/global-local-symtab-sort-o32t.d: New test. * testsuite/ld-mips-elf/global-local-symtab-sort-n32.d: New test. * testsuite/ld-mips-elf/global-local-symtab-sort-n32t.d: New test. * testsuite/ld-mips-elf/global-local-symtab-sort-n64.d: New test. * testsuite/ld-mips-elf/global-local-symtab-sort-n64t.d: New test. * testsuite/ld-mips-elf/global-local-symtab-final-o32.d: New test. * testsuite/ld-mips-elf/global-local-symtab-final-n32.d: New test. * testsuite/ld-mips-elf/global-local-symtab-final-n64.d: New test. * testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
2020-07-29MIPS/LD: Set symtab's `sh_info' correctly for IRIX emulationsMaciej W. Rozycki29-1/+250
Correct ELF linker code so as to set the `sh_info' value of the static symbol table section according to the section symbols vs other symbols split where required by the selection of the IRIX compatibility mode for MIPS target. Add a `elf_backend_elfsym_local_is_section' hook for that purpose, returning TRUE if it is only STB_LOCAL/STT_SECTION symbols that are to be considered local for the purpose of this split rather than all STB_LOCAL symbols. We do it already in generic ELF code, and have done it since 1993, with the `elf_backend_sym_is_global' hook, affecting GAS and `objcopy', so these tools produce correct ELF output in the IRIX compatibility mode, however if such output is fed as input to `ld -r', then the linker's output is no longer valid for that mode. The relevant changes to generic ELF code are: commit 062189c6eab72c7ba1bab1cf30fdb27d67a7d668 Author: Ian Lance Taylor <ian@airs.com> Date: Thu Nov 18 17:12:47 1993 +0000 and: commit 6e07e54f1b347f885cc6c021c3fd912c79bdaf55 Author: Ian Lance Taylor <ian@airs.com> Date: Thu Jan 6 20:01:42 1994 +0000 (split across two GIT commits likely due to repository conversion peculiarities). The `elf_backend_sym_is_global' hook however operates on BFD rather than ELF symbols, making it unsuitable for the ELF linker as the linker does not convert any symbol tables processed into the BFD format. Converting the hook to operate on ELF symbols would in principle be possible, but it would still require a considerable rewrite of `bfd_elf_final_link' to adapt to the interface. Therefore, especially given that no new use for the IRIX compatibility mode is expected, minimize changes made to the ELF linker code and just add an entirely new hook, and wire it in the o32 and n32 MIPS backends accordingly; the n64 backend never uses the IRIX compatibility mode. Since we have no coverage here at all add suitable GAS, LD and `objcopy' test cases to the relevant testsuites to keep these tools consistently verified. bfd/ * elf-bfd.h (elf_backend_data): Add `elf_backend_elfsym_local_is_section' member. * elfxx-target.h (elf_backend_elfsym_local_is_section): New macro. (elfNN_bed): Add `elf_backend_elfsym_local_is_section' member. * elflink.c (bfd_elf_final_link): Use it to determine whether set the `.symtab' section's `sh_info' value to the index of the first non-local or non-section symbol. * elf32-mips.c (mips_elf32_elfsym_local_is_section): New function. (elf_backend_elfsym_local_is_section): New macro. * elfn32-mips.c (mips_elf_n32_elfsym_local_is_section): New function. (elf_backend_elfsym_local_is_section): New macro. binutils/ * testsuite/binutils-all/mips/global-local-symtab-o32.d: New test. * testsuite/binutils-all/mips/global-local-symtab-o32t.d: New test. * testsuite/binutils-all/mips/global-local-symtab-n32.d: New test. * testsuite/binutils-all/mips/global-local-symtab-n32t.d: New test. * testsuite/binutils-all/mips/global-local-symtab-n64.d: New test. * testsuite/binutils-all/mips/mips.exp: Run the new tests. gas/ * testsuite/gas/mips/global-local-symtab-o32.d: New test. * testsuite/gas/mips/global-local-symtab-o32t.d: New test. * testsuite/gas/mips/global-local-symtab-n32.d: New test. * testsuite/gas/mips/global-local-symtab-n32t.d: New test. * testsuite/gas/mips/global-local-symtab-n64.d: New test. * testsuite/gas/mips/global-local-symtab.s: New test source. * testsuite/gas/mips/mips.exp: Run the new tests. ld/ * testsuite/ld-mips-elf/global-local-symtab-o32.d: New test. * testsuite/ld-mips-elf/global-local-symtab-o32t.d: New test. * testsuite/ld-mips-elf/global-local-symtab-n32.d: New test. * testsuite/ld-mips-elf/global-local-symtab-n32t.d: New test. * testsuite/ld-mips-elf/global-local-symtab-n64.d: New test. * testsuite/ld-mips-elf/global-local-symtab.ld: New test linker script. * testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
2020-07-29PR26279 Work around maybe-uninitialized warning in s390-mkopc.cAndreas Arnez2-1/+8
In s390-mkopc.c, the function insertExpandedMnemonic() searches for the first occurrence of '*' or '$' in the given mnemonic, and, if a match is found, chooses an extension table using a switch() on that character. The switch statement contains a default case that prints an error message and does not set the extension table. Although this case cannot occur, some GCC versions obviously conclude that the extension table might have been left uninitialized after the switch statement and consequently emit maybe-uninitialized warnings for the variables 'ext_table' and 'ext_table_length'. Circumvent the warning by handling the unreachable default case with abort(). opcodes/ * s390-mkopc.c (insertExpandedMnemonic): Handle unreachable default case with abort() instead of printing an error message and continuing, to avoid a maybe-uninitialized warning.
2020-07-29[gdb/testsuite] Fix captured_command_loop breakpoint in selftestsTom de Vries2-2/+8
When building gcc with CFLAGS/CXXFLAGS="-O2 -g", and running the regression tests, I run into the following FAILs: ... FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop FAIL: gdb.gdb/python-interrupts.exp: breakpoint in captured_command_loop FAIL: gdb.gdb/python-selftest.exp: breakpoint in captured_command_loop ... The problem is that when setting the breakpoint at captured_command_loop: ... (gdb) break captured_command_loop^M Breakpoint 1 at 0x4230ed: captured_command_loop. (2 locations)^M (gdb) FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop ... there are two breakpoint locations instead of one. This is due to PR26096 - "gdb sets breakpoint at cold clone": ... $ nm gdb | grep captured_command_loop| c++filt 0000000000659f20 t captured_command_loop() 00000000004230ed t captured_command_loop() [clone .cold] ... Work around this by allowing multiple breakpoint locations for captured_command_loop. Reg-tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * lib/selftest-support.exp (selftest_setup): Allow breakpoint at multiple locations.
2020-07-29For DWARF v5 Dwarf Package Files (.dwp files), the section identifier ↵Caroline Tice2-12/+34
encodings have changed. This patch updates dwarf2.h to contain the new encodings. (see http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5). * dwarf2.h (enum dwarf_sect_v5): A new enum section for the sections in a DWARF 5 DWP file (DWP version 5).
2020-07-29Don't segfault on discarded section dynsymsAlan Modra2-1/+9
We get lots of errors before we get to this code, but let's not segfault. * elflink.c (bfd_elf_final_link): Don't segfault on local dynsyms defined in excluded sections.
2020-07-29Don't assert at ldwrite.c:212Alan Modra2-0/+6
When excluding SHF_LINK_ORDER sections that happen to have SEC_KEEP set, we need to set SEC_EXCLUDE here to avoid a problem later. * ldelf.c (ldelf_before_place_orphans): Set SEC_EXCLUDE for discarded sections.
2020-07-29[tdep/s390] Fix Wmaybe-uninitialized in s390_displaced_step_fixupTom de Vries2-2/+8
When building gdb with CFLAGS/CXXFLAGS="-O2 -g -Wall", I see: ... src/gdb/s390-tdep.c: In function 'void s390_displaced_step_fixup(gdbarch*, \ displaced_step_closure*, CORE_ADDR, CORE_ADDR, regcache*)': src/gdb/s390-tdep.c:528:30: warning: 'r2' may be used uninitialized in this \ function [-Wmaybe-uninitialized] 528 | if (insn[0] == op_basr && r2 == 0) | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ ... The problem is that the compiler is unaware that 'is_rr (insn, op_basr, &r1, &r2) == 1' ensures that 'insn[0] == op_basr': ... if (is_rr (insn, op_basr, &r1, &r2) || is_rx (insn, op_bas, &r1, &d2, &x2, &b2)) { /* Recompute saved return address in R1. */ regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1, amode | (from + insnlen)); /* Update PC iff the instruction doesn't actually branch. */ if (insn[0] == op_basr && r2 == 0) regcache_write_pc (regs, from + insnlen); } ... Fix this by storing the result of the call, and using it instead of 'insn[0] ==op_basr'. Build on x86_64-linux with --enable-targets=s390-suse-linux,s390x-suse-linux. gdb/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> PR tdep/26280 * s390-tdep.c (s390_displaced_step_fixup): Fix Wmaybe-uninitialized.
2020-07-29[gdb/testsuite] Make gdb.dwarf2/dw2-line-number-zero.exp more robustTom de Vries2-2/+7
On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to problems in the prologue analyzer (filed as PR26310). Make the test-case more robust by avoiding to use the prologue analyzer: ... -gdb_breakpoint "bar1" +gdb_breakpoint "$srcfile:27" ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines rather than function name.
2020-07-29Automatic date update in version.inGDB Administrator1-1/+1
2020-07-28Demangle function names when disassemblingAndrew Burgess7-11/+160
Andrew Burgess pointed out a regression, which he described in PR symtab/26270: ================ After commit: commit bcfe6157ca288efed127c5efe21ad7924e0d98cf (refs/bisect/bad) Date: Fri Apr 24 15:35:01 2020 -0600 Use the linkage name if it exists The disassembler no longer demangles function names in its output. So we see things like this: (gdb) disassemble tree_insert Dump of assembler code for function _Z11tree_insertP4nodei: .... Instead of this: (gdb) disassemble tree_insert Dump of assembler code for function tree_insert(node*, int): .... This is because find_pc_partial_function now returns the linkage name rather than the demangled name. ================ This patch fixes the problem by introducing a new "overload" of find_pc_partial_function, which returns the general_symbol_info rather than simply the name. This lets the disassemble command choose which name to show. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> PR symtab/26270: * symtab.h (find_pc_partial_function_sym): Declare. * cli/cli-cmds.c (disassemble_command): Use find_pc_partial_function_sym. Check asm_demangle. * blockframe.c (cache_pc_function_sym): New global. (cache_pc_function_name): Remove. (clear_pc_function_cache): Update. (find_pc_partial_function_sym): New function, from find_pc_partial_function. (find_pc_partial_function): Rewrite using find_pc_partial_function_sym. gdb/testsuite/ChangeLog 2020-07-28 Andrew Burgess <andrew.burgess@embecosm.com> PR symtab/26270: * gdb.cp/disasm-func-name.cc: New file. * gdb.cp/disasm-func-name.exp: New file.
2020-07-28Update "disassemble" helpTom Tromey2-5/+10
Pedro pointed out that disassemble/m should be documented after disassemble/s, because /m is deprecated. This patch does so, and adds a usage line. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * cli/cli-cmds.c (_initialize_cli_cmds): Rearrange "disassemble" help. Add usage.
2020-07-28Fix bug in DW_OP_GNU_variable_value evaluationTom Tromey4-1/+14
A modified version of the gnat compiler (TBH I don't know if the modifications are relevant to this bug or not, but I figured I'd mention it) can generate a DWARF location expression like: <1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure) <1202> DW_AT_location : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13 (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop) <2><1279>: Abbrev Number: 9 (DW_TAG_structure_type) <127a> DW_AT_name : (indirect string, offset: 0x1a5a): p__logical_channel_t <127e> DW_AT_byte_size : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and) When evaluated, this gives: Incompatible types on DWARF stack In Jakub's original message about DW_OP_GNU_variable_value: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html .. it says: The intended behavior is that the debug info consumer computes the value of that referenced variable at the current PC, and if it can compute it and pushes the value as a generic type integer into the DWARF stack Instead, gdb is using the variable's type -- but this fails with some operations, like DW_OP_and, which expect the types to match. I believe what was intended was for the value to be cast to the DWARF "untyped" type, which is what this patch implements. This patch also updates varval.exp to exhibit the bug. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * dwarf2/expr.c (dwarf_expr_context::execute_stack_op) <DW_OP_GNU_variable_value>: Cast to address type. gdb/testsuite/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to 'varval' location.
2020-07-28Implement xfer_partial TARGET_OBJECT_SIGNAL_INFO for NetBSDKamil Rytarowski4-0/+217
NetBSD implements reading and overwriting siginfo_t received by the tracee. With TARGET_OBJECT_SIGNAL_INFO signal information can be examined and modified through the special variable $_siginfo. Implement the "get_siginfo_type" gdbarch method for NetBSD architectures. As with Linux architectures, cache the created type in the gdbarch when it is first created. Currently NetBSD uses an identical siginfo type on all architectures, so there is no support for architecture-specific fields. gdb/ChangeLog: * nbsd-nat.h (nbsd_nat_target::xfer_partial): New declaration. * nbsd-nat.c (nbsd_nat_target::xfer_partial): New function. * nbsd-tdep.c (nbsd_gdbarch_data_handle, struct nbsd_gdbarch_data) (init_nbsd_gdbarch_data, get_nbsd_gdbarch_data) (nbsd_get_siginfo_type): New. (nbsd_init_abi): Install gdbarch "get_siginfo_type" method. (_initialize_nbsd_tdep): New
2020-07-28PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS worksH.J. Lu6-16/+38
There is no need to check $pkg_cv_[]$1[]_LIBS works if package check failed. config/ PR binutils/26301 * pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if $pkg_failed = no. binutils/ PR binutils/26301 * configure: Regenerated. gdb/ PR binutils/26301 * configure: Regenerated.
2020-07-28[gdb/build] Fix Wmaybe-uninitialized in gdb_optional.hTom de Vries2-0/+8
When building with CFLAGS/CXXFLAGS="-O2 -g -Wall", we run into: ... In file included from src/gdb/exceptions.h:23, from src/gdb/utils.h:24, from src/gdb/defs.h:630, from src/gdb/record-btrace.c:22: src/gdb/ui-out.h: In function 'void btrace_insn_history(ui_out*, \ const btrace_thread_info*, const btrace_insn_iterator*, \ const btrace_insn_iterator*, gdb_disassembly_flags)': src/gdb/ui-out.h:352:18: warning: \ 'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' may be used \ uninitialized in this function [-Wmaybe-uninitialized] 352 | m_uiout->end (Type); | ~~~~~~~~~~~~~^~~~~~ src/gdb/record-btrace.c:795:35: note: \ 'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' was declared here 795 | gdb::optional<ui_out_emit_list> asm_list; | ^~~~~~~~ ... This is reported as PR gcc/80635 - "[8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning". Silence the warning by using the workaround suggested here ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635#c53 ): ... union { struct { } m_dummy; T m_item; + volatile char dont_use; // Silences -Wmaybe-uninitialized warning. }; ... Build on x86_64-linux. gdbsupport/ChangeLog: 2020-07-28 Tom de Vries <tdevries@suse.de> PR build/26281 * gdb_optional.h (class optional): Add volatile member to union contaning m_dummy and m_item.
2020-07-28PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS worksH.J. Lu7-2/+71
It is quite normal to have headers without library on multilib OSes. Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS works. config/ PR binutils/26301 * pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if $pkg_cv_[]$1[]_LIBS works. binutils/ PR binutils/26301 * configure: Regenerated. gdb/ PR binutils/26301 * configure: Regenerated.
2020-07-28x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)H.J. Lu7-3/+92
Since (%bp)/(%ebp)/(%rbp) are encoded as 0(%bp)/0(%ebp)/0(%rbp), use disp32/disp16 on 0(%bp)/0(%ebp)/0(%rbp) for {disp32}. Note: Since there is no disp32 on 0(%bp), use disp16 instead. PR gas/26305 * config/tc-i386.c (build_modrm_byte): Use disp32/disp16 on (%bp)/(%ebp)/(%rbp) for {disp32}. * doc/c-i386.texi: Update {disp32} documentation. * testsuite/gas/i386/pseudos.s: Add (%bp)/(%ebp) tests. * testsuite/gas/i386/x86-64-pseudos.s: Add (%ebp)/(%rbp) tests. * testsuite/gas/i386/pseudos.d: Updated. * testsuite/gas/i386/x86-64-pseudos.d: Likewise.
2020-07-28gdb/python: make more use of RegisterDescriptorsAndrew Burgess9-57/+153
This commit unifies all of the Python register lookup code (used by Frame.read_register, PendingFrame.read_register, and gdb.UnwindInfo.add_saved_register), and adds support for using a gdb.RegisterDescriptor for register lookup. Currently the register unwind code (PendingFrame and UnwindInfo) allow registers to be looked up either by name, or by GDB's internal number. I suspect the number was added for performance reasons, when unwinding we don't want to repeatedly map from name to number for every unwind. However, this kind-of sucks, it means Python scripts could include GDB's internal register numbers, and if we ever change this numbering in the future users scripts will break in unexpected ways. Meanwhile, the Frame.read_register method only supports accessing registers using a string, the register name. This commit unifies all of the register to register-number lookup code in our Python bindings, and adds a third choice into the mix, the use of gdb.RegisterDescriptor. The register descriptors can be looked up by name, but once looked up, they contain GDB's register number, and so provide all of the performance benefits of using a register number directly. However, as they are looked up by name we are no longer tightly binding the Python API to GDB's internal numbering scheme. As we may already have scripts in the wild that are using the register numbers directly I have kept support for this in the API, but I have listed this method last in the manual, and I have tried to stress that this is NOT a good method to use and that users should use either a string or register descriptor approach. After this commit all existing Python code should function as before, but users now have new options for how to identify registers. gdb/ChangeLog: * python/py-frame.c: Remove 'user-regs.h' include. (frapy_read_register): Rewrite to make use of gdbpy_parse_register_id. * python/py-registers.c (gdbpy_parse_register_id): New function, moved here from python/py-unwind.c. Updated the return type, and also accepts register descriptor objects. * python/py-unwind.c: Remove 'user-regs.h' include. (pyuw_parse_register_id): Moved to python/py-registers.c. (unwind_infopy_add_saved_register): Update to use gdbpy_parse_register_id. (pending_framepy_read_register): Likewise. * python/python-internal.h (gdbpy_parse_register_id): Declare. gdb/testsuite/ChangeLog: * gdb.python/py-unwind.py: Update to make use of a register descriptor. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Update descriptions for PendingFrame.read_register and gdb.UnwindInfo.add_saved_register. (Frames In Python): Update description of Frame.read_register.
2020-07-28gdb: Add a find method for RegisterDescriptorIteratorAndrew Burgess6-1/+84
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class, this allows gdb.RegisterDescriptor objects to be looked up directly by register name rather than having to iterate over all registers. This will be of use for a later commit. I've documented the new function in the manual, but I don't think a NEWS entry is required here, as, since the last release, the whole register descriptor mechanism is new, and is already mentioned in the NEWS file. gdb/ChangeLog: * python/py-registers.c: Add 'user-regs.h' include. (register_descriptor_iter_find): New function. (register_descriptor_iterator_object_methods): New static global methods array. (register_descriptor_iterator_object_type): Add pointer to methods array. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: Add additional tests. gdb/doc/ChangeLog: * python.texi (Registers In Python): Document new find function.
2020-07-28PR25022 testcase segfault for generic ELF linker targetsAlan Modra3-39/+36
Even a testcase that is expected to fail shouldn't segfault. * elf.c (assign_section_numbers): Comment. Don't segfault on discarded sections when setting linked-to section for generic ELF linker. * elflink.c (bfd_elf_match_symbols_in_sections): Allow NULL info.
2020-07-28More just-syms changesAlan Modra3-7/+22
* ldlang.c (lang_check): Don't complain about relocs or merge attributes from --just-symbols input. * testsuite/ld-misc/just-symbols.exp: Just dump .data section. Don't run test on a number of targets.
2020-07-28Re: Allow new just-symbols test to run on XCOFF and PEAlan Modra2-1/+9
This ensures we don't match random data *before* the line we want to see, ie. that --just-symbols has excluded section contents from just-symbols-0.o. Oops, missed the ChangeLog entry before too. * testsuite/ld-misc/just-symbols-1.dd: Revert last change.
2020-07-28Automatic date update in version.inGDB Administrator1-1/+1