aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-17Improve Ada support in .gdb_indexTom Tromey3-13/+41
The cooked index work changed how .gdb_index is constructed, and in the process broke .gdb_index support. This is PR symtab/29179. This patch partially fixes the problem. It arranges for Ada names to be encoded in the form expected by the index code. In particular, linkage names for Ada are emitted, including the "main" name; names are Ada-encoded; and names are no longer case-folded, something that prevented operator names from round-tripping correctly. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
2022-10-17Don't add type linkage names to cooked indexTom Tromey1-5/+0
The compiler will sometimes emit a linkage name for a type, like: <1d3> DW_AT_linkage_name: (indirect string, offset: 0x106f): 11__mbstate_t These names aren't very useful, and this patch changes the DWARF reader so that they are ignored by the cooked index.
2022-10-17Fix regression in c-linkage-name.exp with gdb indexTom Tromey1-3/+4
c-linkage-name.exp started failing with the gdb-index target board due to an earlier patch. The problem here is that some linkage names must be in the index -- but, based on inspection, not C++ linkage names. This patch updates the code to exclude only these.
2022-10-17Fix null pointer representationsTaiseiIto1-9/+9
Since "NULL" and "0" are used to represent invalid address in function "gdbarch_find_by_info" in "binutils-gdb/gdb/arch-utils.c", I modified them to "nullptr".
2022-10-17gdb: silence unused-but-set-variable warning about yynerrs in cp-name-parser.ySimon Marchi1-1/+6
When building with clang 15 on Ubuntu 20.04, I get: CXX cp-name-parser.o cp-name-parser.c.tmp:1777:9: error: variable 'cpnameyynerrs' set but not used [-Werror,-Wunused-but-set-variable] int yynerrs; ^ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:58:18: note: expanded from macro 'yynerrs' #define yynerrs GDB_YY_REMAP (yynerrs) ^ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:40:29: note: expanded from macro 'GDB_YY_REMAP' #define GDB_YY_REMAP(YYSYM) GDB_YY_REMAP_1 (GDB_YY_REMAP_PREFIX, YYSYM) ^ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:39:39: note: expanded from macro 'GDB_YY_REMAP_1' #define GDB_YY_REMAP_1(PREFIX, YYSYM) GDB_YY_REMAP_2 (PREFIX, YYSYM) ^ /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:38:39: note: expanded from macro 'GDB_YY_REMAP_2' #define GDB_YY_REMAP_2(PREFIX, YYSYM) PREFIX ## YYSYM ^ <scratch space>:45:1: note: expanded from here cpnameyynerrs ^ This is because clang 15 warns for something like this: int n; n = 0; ++n; whereas previous versions do not. yynerrs is defined in yyparse and is there for actions to use. Since the actions in cp-name-parser.y don't use it, we get a warning. We see this problem on this particular .y file because it uses `%pure-parser` [1], which makes yynerrs a local rather than a global. I initially fixed this by using DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE (like in commit f7aa1a5acc5 ("gold: Suppress "unused" variable warning on Clang")), but then I realized we could suppress the warning in a more fine-grained way using this in a rule: (void) yynerrs; [1] https://www.gnu.org/software/bison/manual/html_node/Error-Reporting-Function.html Change-Id: I6cae7a4207c19fe1b719e2ac19be69122ebe3af1
2022-10-17ld/testsuite: consistently add board_ldflags when linking with GCCClément Chigot2-5/+25
Currently, the functions checking if the compiler is available or if a feature is available add both board_cflags and board_ldflags. However, functions running the tests only retrieve board_cflags. This can lead to unexpected errors when mandaratory flags are defined in board_ldflags and not board_cflags. ld/ChangeLog: * testsuite/ld-unique/unique.exp: Add board_ldflags when linking with GCC. * testsuite/lib/ld-lib.exp: Likewise.
2022-10-17Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp}CaiJingtao7-212/+583
Omitting predicate size specifier in vector form of {sq, uq, }{decp, incp} is deprecated and will be prohibited in a future release of the aarch64, see https://developer.arm.com/documentation/ddi0602/2021-09/SVE-Instructions/DECP--vector---Decrement-vector-by-count-of-true-predicate-elements-. This allows explicit size specifier, e.g. `decp z0.h, p0.h`, for predicate operand of these SVE instructions. The existing behaviour of not requiring the specifier is preserved. And the disasembly is with the specifier with this patch. The GAS tests passed under our local tests. opcodes/ * aarch64-asm.c: Modify `sve_size_hsd` encoding. * aarch64-tbl.h (aarch64_opcode_table): Add QUALS's type OP_SVE_Vv_HSD for decp, incp, sqdecp, sqincp, uqdecp and uqincp. gas/ * testsuite/gas/aarch64/sve-movprfx_23.s: Update movprfx_23 testcase's test_sametwo macro, where take the predicate size specifier. * testsuite/gas/aarch64/sve-movprfx_23.d: Update movprfx_23 testcase's expected disassembly. * testsuite/gas/aarch64/sve-movprfx_23.l: Update movprfx_23 testcase's expected assembler messages. * testsuite/gas/aarch64/sve.s: Add sve testcase's instructions for decp, incp, sqdecp, sqincp, uqdecp and uqincp, which take the predicate size specifier. * testsuite/gas/aarch64/sve.d: Update sve testcase's expected disassembly. Signed-off-by: CaiJingtao <caijingtao@huawei.com>
2022-10-17aarch64: Tweak handling of F_STRICTRichard Sandiford1-17/+8
Current F_STRICT qualifier checking is enforced after the fact rather than as part of the match. This makes it impossible to have, e.g.: QLF2(S_D, S_D) QLF2(S_D, NIL) in the same list. opcodes/ * aarch64-opc.c (aarch64_find_best_match): Handle F_STRICT here rather than... (match_operands_qualifier): ...here.
2022-10-17x86: properly decode EVEX.W for AVX512_4{FMAPS,VNNIW} insnsJan Beulich1-6/+6
These require EVEX.W=0. Use %XS to facilitate the checking, even if for the AVX512_4VNNIW ones this is kind of an abuse (as 's' there stands for "signed", not "single"). While there also correct the 3rd operand for the AVX512_4VNNIW entries: Only the memory form is allowed (just like for AVX512_4FMAPS, where the correct type is already in use).
2022-10-17x86: fold AVX512-VNNI disassembler entries with AVX-VNNI onesJan Beulich3-15/+22
Make %XV also print the separating blank in the VEX case, while making it do nothing for EVEX-encoded insns. This way the AVX-VNNI entries can be re-used for AVX512-VNNI, at the same time fixing the lack of EVEX.W decoding. For the AVX-VNNI ones further make sure only VEX.66 forms are actually decoded.
2022-10-17Automatic date update in version.inGDB Administrator1-1/+1
2022-10-16More uses of checked_static_castTom Tromey1-10/+10
This patch changes a few more uses of static_cast to use checked_static_cast. In this patch, cast-to-references are converted by moving the dereference outside of the cast, as checked_static_cast only handles pointers.
2022-10-16Use checked_static_cast in more placesTom Tromey9-24/+27
I looked through all the uses of static_cast<... *> in gdb and converted many of them to checked_static_cast. I couldn't test a few of these changes.
2022-10-16PowerPC se_rfmci and VLE, SPE2 and LSP insns with -manyAlan Modra7-57/+64
I noticed recently that se_rfmci, a VLE mode instruction, was being accepted by non-VLE cpus, and also that se_rfmci by itself in a section did not cause SHF_PPC_VLE to be set. ie. both testcases added by this patch fail without the changes to tc-ppc.c here. Also, VLE, SPE2 and LSP insns were not accepted by the assembler with -many nor were SPE2 and LSP being disassembled with -Many. gas/ * config/tc-ppc.c (ppc_setup_opcodes): Wrap long lines. Add vle_opcodes when PPC_OPCODE_VLE or PPC_OPCODE_ANY. Simplify disassembler index segment checks. Add LSP and SPE2 opcodes when PPC_OPCODE_ANY too. (md_assemble): Correct logic adding PPC_APUINFO_VLE and SHF_PPC_VLE. * testsuite/gas/ppc/se_rfmci.s * testsuite/gas/ppc/se_rfmci.d, * testsuite/gas/ppc/se_rfmci_bad.d: New tests. * testsuite/gas/ppc/ppc.exp: Run them. opcodes/ * ppc-dis.c (print_insn_powerpc): Disassemble SPE2 and LSP insn when -Many. * ppc-opc.c (vle_opcodes <se_rfmci>): Comment.
2022-10-16zlib-gabi to zstd woesAlan Modra4-31/+11
So we had a zlib-gabi .debug_info section that increased in size with zstd, so much so that it was better to leave the section uncompressed. Things went horribly wrong when the section was read again later. The section was read again off disk using the uncompressed size. So you get the zlib section again with some garbage at the end. Fix that particular problem by setting the section flag SEC_IN_MEMORY. Any future read will get sec->contents. Also, if the section is to be left uncompressed, the input SHF_COMPRESSED flag needs to be reset otherwise objcopy will copy it to output. Finally, bfd_convert_section_contents needed a small update to handle zstd compressed sections, and I've deleted bfd_cache_section_contents. * bfd.c (bfd_convert_section_contents): Handle zstd. * compress.c (bfd_compress_section_contents): When section contents are uncompressed set SEC_IN_MEMORY flag, compress_status to COMRESS_SECTION_NONE, and clear SHF_COMPRESSED. Set SEC_IN_MEMORY for compressed contents. (bfd_get_full_section_contents): Don't check section size against file size when SEC_IN_MEMORY. (bfd_cache_section_contents): Delete function. * elf32-arm.c (elf32_arm_get_synthetic_symtab): Expand bfd_cache_section_contents here. * bfd-in2.h: Regenerate.
2022-10-16Automatic date update in version.inGDB Administrator1-1/+1
2022-10-15gdb/arm: Don't rely on loop detection to stop unwindingTorbjörn SVENSSON1-7/+6
Setting SP of the next frame to the same address as the current frame is an ugly way to stop the unwinding. A cleaner way is to rely on the frame_unwind_stop_reason function to return UNWIND_OUTERMOST. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-10-15Automatic date update in version.inGDB Administrator1-1/+1
2022-10-14[gdb/testsuite] Add boards/READMETom de Vries1-0/+88
Add a file gdb/testsuite/boards/README, to make it easier to get a high-level overview of the various boards.
2022-10-14[gdb/contrib] Handle STRIP_ARGS_{STRIP,KEEP}_DEBUG in cc-with-tweaks.shTom de Vries1-2/+7
Handle new environment variable STRIP_ARGS_STRIP_DEBUG, defaulting to --strip-debug in gdb/contrib/cc-with-tweaks.sh, such that we can easily reproduce the PR29277 assert using: ... $ export STRIP_ARGS_STRIP_DEBUG=--strip-all $ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \ --target_board cc-with-gnu-debuglink" ... For completeness sake and to avoid confusion about which of the two used strip invocations the passed args apply to, likewise add STRIP_ARGS_KEEP_DEBUG, defaulting to --only-keep-debug. Script checked with shellcheck, no new warnings added. Tested on x86_64-linux.
2022-10-14[gdb] Fix heap-buffer-overflow in find_program_interpreterTom de Vries4-4/+79
With the test-case included in this patch, we run into: ... (gdb) target remote localhost:2347^M `target:twice-connect' has disappeared; keeping its symbols.^M Remote debugging using localhost:2347^M warning: Unable to find dynamic linker breakpoint function.^M GDB will be unable to debug shared library initializers^M and track explicitly loaded dynamic code.^M Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M 0x00007ffff7dd4550 in ?? ()^M (gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started FAIL: gdb.server/twice-connect.exp: found interpreter ... The problem originates in find_program_interpreter, where bfd_get_section_contents is called to read .interp, but fails. The function returns false but the result is ignored, so find_program_interpreter returns some random string. Fix this by checking the result of the call to bfd_get_section_contents. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652
2022-10-14[gdb/testsuite] Fix gdb.server/unittest.exp with host board ↵Tom de Vries1-1/+1
local-remote-host.exp With test-case gdb.server/unittest.exp and host board local-remote-host.exp I run into: ... builtin_spawn build/gdbserver/gdbserver --selftest^M ERROR: : spawn id exp7 not open while executing "expect { -i exp7 -timeout 10 -i $server_spawn_id -re "Ran ($decimal) unit tests, 0 failed" { set num_ran $expect_out(1,string) gdb_assert "..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE : spawn id exp7 not open UNRESOLVED: gdb.server/unittest.exp: unit tests ... The problem is (as fixed for avr in commit df5b8876083 ("gdb/testsuite: better handle failures in simavr board, reap simavr process")), that gdb_expect through remote_expect adds a "-i <gdb spawn id> -timeout 10", which is the one causing the error. As in aforementioned commit, fix this by using expect instead. Tested on x86_64-linux.
2022-10-14[gdb/testsuite] Fix host board local-remote-host-notty.exp timeoutsTom de Vries2-32/+43
With test-case gdb.server/stop-reply-no-thread-multi.exp and host board local-remote-host-notty.exp we occasionally run into a silent out, due to getting: ... (gdb) kill^M (gdb) The program is not being run.^M ... instead of the expected: ... (gdb) kill^M The program is not being run.^M (gdb) ... Likewise, we occasionally run into a nonsilent timeout: ... (gdb) disconnect^M (gdb) You can't do that when your target is `exec'^M FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=Tthread: t_nonstop=on: \ disconnect (timeout) ... Typically, this results in the test-case taking more than two minutes to run. The problem can be reproduced using just: ... $ ssh -l $USER 127.0.0.1 gdb -q -ex kill ... Note that ssh by default uses -T which disables pseudo-tty allocation (as opposed to -t which forces pseudo-tty allocation): ... $ ssh -l $USER 127.0.0.1 -T tty not a tty $ ssh -l $USER 127.0.0.1 -t tty /dev/pts/5 Connection to 127.0.0.1 closed. ... and according to https://stackoverflow.com/a/63241102 the behaviour we're seeing is specific to using '-T'. The related host board local-remote-host.exp does use '-t', and the only difference between the two boards mentioned is whether editing is on or off. Fix this by: - moving the content of local-remote-host-notty.exp into local-remote-host.exp - consequently, extending the copyright years in local-remote-host.exp - including local-remote-host.exp in local-remote-host-notty.exp (making local-remote-host-notty.exp use '-t') - adding -iex "set editing off" to GDBFLAGS in local-remote-host-notty.exp This results in the test-case taking just 6 seconds to run. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29669
2022-10-14[gdb/testsuite] Disable styling in host board local-remote-host.expTom de Vries1-0/+2
With test-case gdb.server/stop-reply-no-thread.exp and host board local-remote-host.exp, I run into: ... Breakpoint 1, ^[[33mmain^[[m () at ^[[32mstop-reply-no-thread.c^[[m:21^M 21 ^[[01;34mreturn^[[m ^[[35m0^[[m^[[31m;^[[m^M (gdb) FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=: t_nonstop=off: \ continue to main ... The problem is that styling is enabled, and that is causing a regexp mismatch. With native, styling is disabled in default_gdb_init by doing 'setenv TERM "dumb"', but that only has effect because the build (where we execute runtest, and consequently the setenv) and the host (where we execute gdb) are the same. For this host board however, gdb executes on a remote host, and the setenv has no effect. We could try to make some generic way to set TERM on the host, but for the purposes of this test-case it seems sufficient to just add: ... set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\"" ... so let's go with that for now. Tested on x86_64-linux.
2022-10-14Use scoped_value_mark in more placesTom Tromey8-54/+37
I looked at all the spots using value_mark, and converted all the straightforward ones to use scoped_value_mark instead. Regression tested on x86-64 Fedora 34.
2022-10-14gdb/arm: Stop unwinding on error, but do not assertTorbjörn SVENSSON1-7/+40
When it's impossible to read the FPCCR and XPSR, the unwinding is unpredictable as the it's not possible to determine the correct frame size or padding. The only sane thing to do in this condition is to stop the unwinding. Example session without this patch: (gdb) bt #0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112 .../gdb/arm-tdep.c:3594: internal-error: arm_m_exception_cache: Assertion `safe_read_memory_unsigned_integer (FPCCR, ARM_INT_REGISTER_SIZE, byte_order, &fpccr)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x5583bfb2a157 gdb_internal_backtrace_1 ... --------------------- This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Aborted (core dumped) Example session with this patch: (gdb) bt #0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112 warning: Could not fetch required FPCCR content. Further unwind is impossible. #1 <signal handler called> (gdb) Reviewed-by: Pedro Alves <pedro@palves.net> Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-10-14PowerPC SPE disassembly and testsAlan Modra5-16/+13
Where sub and subf forms of an instruction exist we generally disassemble to the extended insn sub form rather than the underlying machine subf instruction. Do so for SPE evsubw and evsubiw too. spe_ambiguous.d always was a bit too optimistic. There is no sensible way to disassemble identical bytes back to different and original source. Instead change the test to check -Mraw results. gas/ * testsuite/gas/ppc/ppc.exp: Run spe_ambiguous test. * testsuite/gas/ppc/spe.d: Expect evsubw and evsubiw rather than evsubfw and evsubifw. * testsuite/gas/ppc/spe_ambiguous.s: Test evnor form equivalent to evnot. * testsuite/gas/ppc/spe_ambiguous.d: Test Mraw. opcodes/ * ppc-opc.c (powerpc_opcodes): Move evsubw before evsubfw and evsubiw before evsubifw and mark EXT.
2022-10-14e200 LSP supportAlan Modra9-353/+459
It has bothered me for a long time that we have disabled LSP (and SPE) tests. Also the LSP test comment indicating there is something wrong with get_powerpc_dialect. I don't think there is. Decoding of a VLE instruction depends on whether the processor is in VLE mode (some processors support both VLE and standard PPC) which we flag per section with SHF_PPC_VLE for decoding when disassembling. Background: Some versions of powerpc e200 have "Lightweight Signal Processing" support, examples being e200z215 and e200z425. As far as I can tell, LSP and SPE are mutually exclusive. This seems to be borne out by insn encoding, for example LSP "zvaddih" and SPE "evaddw" have the same encoding. So none of the processor descriptions in ppc_opts ought to have both PPC_OPCODE_LSP and PPC_OPCODE_SPE/2, if we want disassembly to work. I also could not find anything to suggest that the LSP insns are enabled only in VLE mode, which means the LSP insns should not be in vle_opcodes. Fix all this by moving the LSP insns to their own table, and add a new e200z2 cpu entry with LSP support, removing LSP from -me200z4 and from -mvle. (Yes, I know, as I said above some of the e200z4 processors have LSP. Others have SPE. It's hard to choose good options. Think of z2 as meaning earlier, z4 as later.) Also add -mlsp to allow adding the LSP insn set. include/ * opcode/ppc.h (lsp_opcodes, lsp_num_opcodes): Declare. (LSP_OP_TO_SEG): Define. binutils/ * doc/binutils.texi: Update ppc docs. gas/ * config/tc-ppc.c (ppc_setup_opcodes): Add lsp opcodes to ppc_hash. * doc/c-ppc.texi: Document e200 and lsp. * testsuite/gas/ppc/lsp-checks.d: Assemble with -me200z2. * testsuite/gas/ppc/lsp.d: Likewise, disassembly too. * testsuite/gas/ppc/ppc.exp: Don't xfail lsp test. opcodes/ * ppc-dis.c (ppc_opts): Add e200z2 and lsp. Don't set PPC_OPCODE_LSP for e200z4 or vle. (ppc_parse_cpu): Mutually exclude LSP and SPE. (LSP_OPCD_SEGS): Define. (lsp_opcd_indices): New array. (disassemble_init_powerpc): Init lsp_opcd_indices. (lookup_lsp): New function. (print_insn_powerpc): Call it. * ppc-opc.c: Include libiberty.h for ARRAY_SIZE and use throughout. (vle_opcodes): Move LSP opcodes to.. (lsp_opcodes): ..here, and sort. (lsp_num_opcodes): New.
2022-10-14PR29677, Field `the_bfd` of `asymbol` is uninitialisedAlan Modra1-41/+31
Besides not initialising the_bfd of synthetic symbols, counting symbols when sizing didn't match symbols created if there were any dynsyms named "". We don't want synthetic symbols without names anyway, so get rid of them. Also, simplify and correct sanity checks. PR 29677 * mach-o.c (bfd_mach_o_get_synthetic_symtab): Rewrite.
2022-10-14[gdb/testsuite] Drop unnecessary -Wl,-soname in gdb.base/skip-solib.expTom de Vries1-1/+1
I noticed in gdb.base/skip-solib.exp: ... if {[gdb_compile_shlib ${srcdir}/${subdir}/${srcfile_lib} ${binfile_lib} \ [list debug -Wl,-soname,${libname}.so]] != ""} { return -1 } ... that the -Wl,-soname argument is missing an ldflags= prefix, but adding it gives us a duplicate: ... Executing on host: gcc -fno-stack-protector \ outputs/gdb.base/skip-solib/skip-solib-lib.c.o -fdiagnostics-color=never \ -shared -g -Wl,-soname,libskip-solib.so -Wl,-soname,libskip-solib.so -lm \ -o outputs/gdb.base/skip-solib/libskip-solib.so (timeout = 300) ... so apparently it's taken care of by gdb_compile_shlib. Drop the inactive and also unnecessary -Wl,-soname,${libname}.so from the flags list for the gdb_compile_shlib call. Tested on x86_64-linux.
2022-10-14[gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with PIETom de Vries1-0/+1
With test-case gdb.base/infoline-reloc-main-from-zero.exp and target board unix/-fPIE/-pie I run into: ... gdb compile failed, ld: infoline-reloc-main-from-zero: error: \ PHDR segment not covered by LOAD segment collect2: error: ld returned 1 exit status ... When running with native, I find that the executable is static: ... $ file infoline-reloc-main-from-zero infoline-reloc-main-from-zero: ELF 64-bit LSB executable, x86-64, \ version 1 (SYSV), statically linked, BuildID[sha1]=$hex, with debug_info, \ not stripped ... despite not having been compiled with -static. Fix the compilation by adding -static to the compilation flags. Tested on x86_64-linux.
2022-10-14[gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with clangTom de Vries16-26/+26
With test-case gdb.base/infoline-reloc-main-from-zero.exp and clang I run into: ... gdb compile failed, clang-13.0: warning: -e main: 'linker' input unused \ [-Wunused-command-line-argument] clang-13.0: warning: -Wl,-Ttext=0x00: 'linker' input unused \ [-Wunused-command-line-argument] clang-13.0: warning: -Wl,-N: 'linker' input unused \ [-Wunused-command-line-argument] UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \ infoline-reloc-main-from-zero.exp UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile ... Fix this by using ldflags instead of additional_flags. Likewise, fix all occurrences of: ... $ find gdb/testsuite -name *.exp | xargs grep additional_flags.*Wl ... Tested on x86_64-linux.
2022-10-14[gdb/testsuite] Fix nopie test-cases with target board unix/-fPIE/-pieTom de Vries1-1/+4
Compilers default to either PIE or no-PIE executables. In order to test PIE executables with a compiler that produces non-PIE by default, we can use target board unix/-fPIE/-pie, which set the multilib_flags of the target board to "-fPIE -pie". Likewise, we can use target board unix/-fno-PIE/-no-pie with a compiler that produces PIE by default. The target board unix/-fno-PIE/-no-pie has a potential problem when compiling shared libs, because the multilib_flags will override the attempts of gdb_compile_shlib to compile with -fPIC. This is taken care of by running the body of gdb_compile_shlib wrapped in with_PIE_multilib_flags_filtered. The target board unix/-fPIE/-pie has a problem with nopie compilations. The current approach is to do the compilation hoping for the best, and if we find out that the resulting executable is PIE despite specifying nopie, we error out with the standard error message "nopie failed to prevent PIE executable". That however does not work for hard-coded assembly nopie test-cases, which will just noisily refuse to compile: ... ld: amd64-disp-step0.o: relocation R_X86_64_32S against `.text' can not be \ used when making a PIE object; recompile with -fPIE^M ... Fix this in gdb_compile by filtering out the PIE settings in the target board multilib_flags when pie or nopie is specified. Tested on x86_64-linux.
2022-10-14[gdb/testsuite] Factor out with_PIE_multilib_flags_filteredTom de Vries1-7/+22
Factor out new procs with_PIE_multilib_flags_filtered and with_multilib_flags_filtered from proc gdb_compile_shlib. Tested on x86_64-linux.
2022-10-14[gdb/testsuite] Add cond_wrap procTom de Vries2-0/+63
Add a new proc cond_wrap, that can be used to replace the repetitive: ... if { $cond } { wrap { <body> } } else { <body> } ... with the shorter: ... cond_wrap $cond wrap { <body> } ... Tested on x86_64-linux.
2022-10-14gdb: add Torbjörn Svensson to gdb/MAINTAINERSTorbjörn SVENSSON1-0/+1
2022-10-14RISC-V: Zicbo{m,p,z} adjustments to riscv_multi_subset_supports_ext()Jan Beulich1-0/+6
The lack thereof did caused gas to issue "internal: unreachable INSN_CLASS_*" errors when trying to assemble respective insns without the feature(s) enabled via e.g. ".option arch, ...". Of course a proper hint towards the missing extension then wasn't given either.
2022-10-14RISC-V: Imply 'Zicsr' from privileged extensions with CSRsTsukasa OI2-0/+11
'H', 'Smstateen', 'Sscofpmf' and 'Sstc' are four privileged extensions with their CSR definitions and 'Smepmp' is a privileged extension with additional CSR bits. Volume II: Privileged Architecture of the RISC-V ISA Manual states that the privileged architecture requires the 'Zicsr' extension. However, current GNU Binutils has no direct way whether the program has dependency to the privileged architecture itself. As a workaround, we should add implications from privileged extensions that either add new CSRs, extend existing CSRs or depends on using CSRs. This commit adds such implications for existing privileged extensions that satisfy this condition. gas/ChangeLog: * testsuite/gas/riscv/march-imply-h.d: New test, at least for 'H'. bfd/ChangeLog: * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zicsr' implicications for privileged extensions 'H', 'Smstateen', 'Sscofpmf', 'Sstc' and 'Smepmp'.
2022-10-14opcodes/riscv-dis.c: Remove last_map_stateTsukasa OI1-3/+0
Before changing the core disassembler, we take care of minor code clarity issues and improve readability. This commit removes unused variable last_map_state (set by the print_insn_riscv function but not read anywhere else). opcodes/ChangeLog: * riscv-dis.c (last_map_state): Remove. (print_insn_riscv): Remove setting last_map_state.
2022-10-14opcodes/riscv-dis.c: Make XLEN variable staticTsukasa OI1-1/+1
Before changing the core disassembler, we take care of minor code clarity issues and improve readability. Since xlen variable is not (and should not) used outside riscv-dis.c, this commit makes this variable static. opcodes/ChangeLog: * riscv-dis.c (xlen): Make this variable static.
2022-10-14opcodes/riscv-dis.c: Use bool type whenever possibleTsukasa OI1-5/+5
Before changing the core disassembler, we take care of minor code clarity issues and improve readability. This commit replaces uses of int with bool whenever possible. opcodes/ChangeLog: * riscv-dis.c (no_aliases) Change type to bool. (set_default_riscv_dis_options): Use boolean. (parse_riscv_dis_option_without_args): Likewise. (riscv_disassemble_insn): Use boolean keywords.
2022-10-14opcodes/riscv-dis.c: Tidying with spacingTsukasa OI1-1/+1
Before changing the core disassembler, we take care of minor code clarity issues and improve readability. This commit takes care of improper spacing for code clarity. opcodes/ChangeLog: * riscv-dis.c (riscv_disassemble_insn): Tidying with spacing.
2022-10-14opcodes/riscv-dis.c: Tidying with comments/clarityTsukasa OI1-4/+21
Before changing the core disassembler, we take care of minor code clarity issues and improve readability. First, we need to clarify the roles of variables and code portions. opcodes/ChangeLog: * riscv-dis.c (xlen): Move before default_isa_spec. Add comment. (default_isa_spec, default_priv_spec): Add comment. (riscv_gpr_names, riscv_fpr_names): Likewise. (parse_riscv_dis_option_without_args): Likewise. (parse_riscv_dis_option, parse_riscv_dis_options): Likewise. (maybe_print_address): Likewise. (riscv_disassemble_insn): Fix comment about the Zfinx "extension". Add comment about the riscv_multi_subset_supports call.
2022-10-14RISC-V: Test DWARF register number for "fp"Tsukasa OI2-0/+4
This commit adds "fp" (x8 or s0) to dw-regnums.{s,d}. gas/ChangeLog: * testsuite/gas/riscv/dw-regnums.s: Add "fp". * testsuite/gas/riscv/dw-regnums.d: Likewise.
2022-10-14RISC-V: Move standard hints before all instructionsTsukasa OI1-4/+8
Because all standard hints must be placed before corresponding instruction for the disassembler, they may taint basic RVI instruction section. This commit moves all standard hints before all basic RVI instructions to improve maintainability. opcodes/ChangeLog: * riscv-opc.c (riscv_opcodes): Move all standard hints before all standard instructions.
2022-10-14RISC-V: Move certain arrays to riscv-opc.cTsukasa OI2-11/+15
This is a part of small tidying (declare tables in riscv-opc.c). include/ChangeLog: * opcode/riscv.h (riscv_rm, riscv_pred_succ): Move declarations to opcodes/riscv-opc.c. New non-static definitions. opcodes/ChangeLog: * riscv-opc.c (riscv_rm, riscv_pred_succ): Move from include/opcode/riscv.h. Add description.
2022-10-13ld: Add --undefined-versionFangrui Song2-0/+6
This cancels a previous --no-undefined-version. gold has had --undefined-version for a long time.
2022-10-14Automatic date update in version.inGDB Administrator1-1/+1
2022-10-13PowerPC, fix gdb.base/watchpoint.exp on Power 9Carl Love1-7/+19
Test gdb.base/watchpoint.exp generates 4 test errors on Power 9. The test uses the test [target_info exists gdb,no_hardware_watchpoints] to determine if the processor supports hardware watchpoints. The check only examines the processor type to determine if it supports hardware watchpoints. The PowerPC processors support hardware watchpoints with the exception of Power 9. The hardware watchpoint support is disabled on Power 9. The test skip_hw_watchpoint_tests must be used to correctly determine if the PowerPC processor supports hardware watchpoints. This patch replaces the [target_info exists gdb,no_hardware_watchpoints] with the skip_hw_watchpoint_tests_p check. With the patch, the test runs on Power 9 with hardware watchpoint force-disabled. The test runs on all other PowerPC processors with and without hardware watchpoints enabled. The patch has been tested on Power 9 to verify the test only runs with hardware breakpoints disabled. The patch has been tested on X86-64 with no regression failures. The test fails on Power 10 due to an internal GDB error due to resource management. The resource management issue will be addressed in another patch.
2022-10-13[gdb/testsuite] Fix gdb.dwarf2/macro-source-path.exp with -m32Tom de Vries1-5/+2
With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I run into: ... as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \ unsupported relocation type: 0x1^M ... The problem is that we have 64-bit dwarf so the debug_line offset in the .debug_macro section is an 8-byte entity, emitted using ".8byte": ... .section .debug_macro .Lcu_macros4: .2byte 5 /* version */ .byte 3 /* flags */ .8byte .LLlines3 /* debug_line offset */ ... but the linker doesn't support 8-byte relocation types on a 32-bit architecture. This is similar to what was fixed in commit a5ac8e7fa3b ("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance .debug_abbrev. Fix this in the same way, by using _op_offset to emit the debug_line offset. Tested on x86_64-linux with native and target board unix/-m32.