aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-22RISC-V: Add support for literal instruction argumentsChristoph Müllner2-0/+19
This patch introduces support for arbitrary literal instruction arguments, that are not encoded in the opcode. A typical use case for this feature would be an instruction that applies an implicit shift by a constant value on an immediate (that is a real operand). With this patch it is possible to make this shift visible in the dissasembly and support such artificial parameter as part of the asssembly code. Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head MemIdx vendor extensionChristoph Müllner10-0/+337
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadMemIdx extension, a collection of T-Head specific GPR memory access instructions. The 'th' prefix and the "XTheadMemIdx" extension are documented in a PR for the RISC-V toolchain conventions ([1]). In total XTheadCmo introduces the following 44 instructions (BU,HU,WU only for loads (zero-extend instead of sign-extend)): * {L,S}{D,W,WU,H,HU,B,BU}{IA,IB} rd, rs1, imm5, imm2 * {L,S}R{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2 * {L,S}UR{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head FMemIdx vendor extensionChristoph Müllner10-0/+127
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadFMemIdx extension, a collection of T-Head-specific floating-point memory access instructions. The 'th' prefix and the "XTheadFMemIdx" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head MAC vendor extensionChristoph Müllner7-0/+61
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadMac extension, a collection of T-Head-specific multiply-accumulate instructions. The 'th' prefix and the "XTheadMac" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head CondMov vendor extensionChristoph Müllner7-0/+37
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadCondMov extension, a collection of T-Head-specific conditional move instructions. The 'th' prefix and the "XTheadCondMov" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head Bitmanip vendor extensionChristoph Müllner20-0/+215
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XThead{Ba,Bb,Bs} extensions, a collection of T-Head-specific bitmanipulation instructions. The 'th' prefix and the "XThead{Ba,Bb,Bs}" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add support for arbitrary immediate encoding formatsChristoph Müllner3-0/+125
This patch introduces support for arbitrary signed or unsigned immediate encoding formats. The formats have the form "XsN@S" and "XuN@S" with N being the number of bits and S the LSB position. For example an immediate field of 5 bytes that encodes a signed value and is stored in the bits 24-20 of the instruction word can use the format specifier "Xs5@20". Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head SYNC vendor extensionChristoph Müllner10-0/+70
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadSync extension, a collection of T-Head-specific multi-processor synchronization instructions. The 'th' prefix and the "XTheadSync" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head CMO vendor extensionChristoph Müllner10-0/+199
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadCmo extension, a collection of T-Head specific cache management operations. The 'th' prefix and the "XTheadCmo" extension are documented in a PR for the RISC-V toolchain conventions ([1]). In total XTheadCmo introduces the following 21 instructions: * DCACHE.{C,CI,I}ALL * DCACHE.{C,CI,I}{PA,VA,SW} rs1 * DCACHE.C{PAL1,VAL1} rs1 * ICACHE.I{ALL,ALLS} * ICACHE.I{PA,VA} rs1 * L2CACHE.{C,CI,I}ALL Contrary to Zicbom, the XTheadCmo instructions don't have a constant displacement, therefore we have a different syntax for the arguments. To clarify this is intended behaviour, there is a set of negative test for Zicbom-style arguments in x-thead-cmo-fail.s. [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 v2: - Add missing DECLARE_INSN() list - Fix ordering Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add generic support for vendor extensionsChristoph Müllner2-2/+21
This patch introduces changes that allow the integration of vendor ISA extensions: * Define a list of vendor extensions (riscv_supported_vendor_x_ext) where vendor extensions can be added * Introduce a section with a table in the documentation where vendor extensions can be added To add a vendor extension that consists of instructions only, the following things need to be done: * Add the extension to the riscv_supported_vendor_x_ext list * Add lookup entry in riscv_multi_subset_supports * Documenting the extension in c-riscv.texti * Add test cases for all instructions * Add MATCH*/MASK* constants and DECLARE_INSN() for all instructions * Add new instruction class to enum riscv_insn_class * Define the instructions in riscv_opcodes * Additional changes if necessary (depending on the instructions) Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22[gdb/symtab] Add all_comp_units/all_type_units views on all_unitsTom de Vries3-11/+32
Add all_comp_units/all_type_units views on all_units. Having the views allows us to: - easily get the number of CUs or TUs in all_units, and - easily access the nth CU or TU. This minimizes the use of tu_stats.nr_tus. Tested on x86_64-linux.
2022-09-22[gdb/symtab] Rename all_comp_units to all_unitsTom de Vries3-87/+87
Mechanically rename all_comp_units to all_units: ... $ sed -i 's/all_comp_units/all_units/' gdb/dwarf2/* ... Tested on x86_64-linux.
2022-09-22opcodes: SH fix bank register disassemble.Yoshinori Sato2-0/+7
* sh-dis.c (print_insn_sh): Enforce bit7 of LDC Rm,Rn_BANK and STC Rm_BANK,Rn is always 1.
2022-09-22include: Add macro to ignore -Wunused-but-set-variableTsukasa OI1-0/+14
"-Wunused-but-set-variable" warning option can be helpful to track variables that are written but not read thereafter. But it can be harmful if some of the code is auto-generated and we have no ways to deal with it. The particular example is Bison-generated code. The new DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro can be helpful on such cases. A typical use of this macro is to place this macro before the end of user prologues on Bison (.y) files. include/ChangeLog: * diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE): New.
2022-09-22include: Add macro to ignore -Wuser-defined-warningsTsukasa OI1-0/+9
User-defined warnings (on Clang, "-Wuser-defined-warnings") can be harmful if we have specified "-Werror" and we have no control to disable the warning ourself. The particular example is Gnulib. Gnulib generates a warning if the system version of certain functions are used (to redirect the developer to use Gnulib version). However, it can be harmful if we cannot easily replace them (e.g. the target is in the standard C++ library). The new DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS macro can be helpful on such cases. A typical use of this macro is to place this macro before including certain system headers. include/ChangeLog: * diagnostics.h (DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS): New.
2022-09-22gdb/python: restrict the names accepted by gdb.register_window_typeAndrew Burgess4-1/+105
I noticed that, from Python, I could register a new TUI window that had whitespace in its name, like this: gdb.register_window_type('my window', MyWindowType) however, it is not possible to then use this window in a new TUI layout, e.g.: (gdb) tui new-layout foo my window 1 cmd 1 Unknown window "my" (gdb) tui new-layout foo "my window" 1 cmd 1 Unknown window ""my" (gdb) tui new-layout foo my\ window 1 cmd 1 Unknown window "my\" GDB clearly uses the whitespace to split the incoming command line. I could fix this by trying to add a mechanism by which we can use whitespace within a window name, but it seems like an easier solution if we just forbid whitespace within a window name. Not only is this easier, but I think this is probably the better solution, identifier names with spaces in would mean we'd need to audit all the places a window name could be printed and ensure that the use of a space didn't make the output ambiguous. So, having decided to disallow whitespace, I then thought about other special characters. We currently accept anything as a window name, and I wondered if this was a good idea. My concerns were about how special characters used in a window name might cause confusion, for example, we allow '$' in window names, which is maybe fine now, but what if one day we wanted to allow variable expansion when creating new layouts? Or what about starting a window name with '-'? We already support a '-horizontal' option, what if we want to add more in the future? Or use of the special character '{' which has special meaning within a new layout? In the end I figured it might make sense to place some restrictive rules in place, and then relax the rules later if/when users complain, we can consider each relaxation as its requested. So, I propose that window names should match this regular expression: [a-zA-Z][-_.a-zA-Z0-9]* There is a chance that there is user code in the wild which will break with the addition of this change, but hopefully adapting to the new restrictions shouldn't be too difficult.
2022-09-22gdb/testsuite: Add test to step through function epilogueBruno Larsen2-0/+136
The testsuite implicitly tests GDB's ability to step through epilogues in multiple tests, without doing it explicitly anywhere. This is unfortunate, as clang does not emit epilogue information, so using clang on our testsuite makes many tests fail. This patch adds a central, explicit test for walking through the epilogue so we can safely remove this from other tests and have them working with clang. The test created attempts to step through a simple epilogue, an epilogue that ends on another epilogue, and epilogues leading to other function calls.
2022-09-22gdb.base/skip.exp: Use finish to exit functionsBruno Larsen1-17/+17
gdb.base/skip.exp was making use of a fixed number of step commands to exit some functions. This caused some problems when using clang to test GDB, as GDB would need fewer steps to reach the desired spots. For instance, when testing in the section "step after disabling 3", the log looks like this: Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); (gdb) step bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 21 return 1; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1 step foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 42 return 0; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2 step main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34 34 test_skip_file_and_function (); (gdb) step test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59 59 test_skip (); (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3 step test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48 48 } (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4 step test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60 60 skip1_test_skip_file_and_function (); (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5 This shows that the feature is working but because the inferior lands in a different location, it registers as a failure. Seeing as along with this difference, there are also some differences that depend on gcc versions (where gdb might stop back at line 32 before entering foo), it would not be easy to test for this behavior using steps and analzing where the inferior stops at each point. On the other hand, using gdb_step_until is not feasible because we'd possibly gloss over stepping into baz and rendering the whole test useless. Instead, skip.exp now uses finish to leave functions, synchronizing through compilers and compiler versions. Some test names were also changed to be a bit more descriptive. The new log looks like this, independently of compiler used: Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); (gdb) step bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 21 return 1; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar finish Run till exit from #0 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); Value returned is $2 = 1 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar step foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 42 return 0; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo finish Run till exit from #0 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); Value returned is $3 = 0 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo step 34 test_skip_file_and_function (); (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz
2022-09-22fix gdb.base/jit-elf.exp when testing with clangBruno Larsen1-1/+1
When using clang as the compiler for the target, gdb.base/jit-elf.exp was failing because the filename displayed when GDB attached to the inferior was only showing up as with a relative path, like so: (gdb) attach 3674146 Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146 Reading symbols from /lib64/libm.so.6... Reading symbols from .gnu_debugdata for /lib64/libm.so.6... (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach While gcc's output is as follows: (gdb) attach 3592961 Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961 Reading symbols from /lib64/libm.so.6... Reading symbols from .gnu_debugdata for /lib64/libm.so.6... (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach This difference only happens when GDB's configure is ran using a relative path, but seeing as testing the full path is not important for this specific test, it feels worth fixing anyway. To fix the false positive, the regexp for checking where gdb has stopped was relaxed a little to allow the relative path.
2022-09-22gdb/testsuite: fix gdb.base/msym-bp-shl when running with ClangBruno Larsen1-1/+1
When trying to test gdb.base/msym-bp-shl.exp using clang, it would have many failures because one of the version of the foo function was being optimized away. Adding __attribute__ ((used)) to it fixed this.
2022-09-22gdb/testsuite: fix testing gdb.base/skip-inline.exp with clangBruno Larsen1-45/+62
When testing gdb.base/skip-inline.exp using clang, we get failures when trying to step out of functions, since clang requires one fewer step when compared to gcc. The inferior gets increasingly out of sync as the test continues because of this difference, which generates those failures. This commit fixes this by switching those hardcoded steps to gdb_step_until, to guarantee that the inferior is always synced to what the test expects. This approach does not work for the parts that use step 2 or step 3, so when we identify that clang is being used, those tests are skipped.
2022-09-22Change gdb.base/skip-solib.exp deal with lack of epilogue informationBruno Larsen2-2/+4
When running gdb.base/skip-solib.exp, the backtrace tests could fail with compilers that associated epilogue instructions with the last statement line of the function, instead of associating it with the closing brace, despite the feature being fully functional. As an example, when testing skipping the function square, the testsuite would show Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5 5 return square(0); (gdb) step 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6 (gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step bt #0 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6 #1 0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6 #2 0x0000000000401065 in _start () (gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt Which means that the feature is working, the testsuite is just mis-identifying it. To avoid this problem, the skipped function calls have been sent to a line before `return`, so epilogues won't factor in.
2022-09-22gdb/testsuite: Add a proc to test where compiler links the epilogueBruno Larsen1-0/+32
Different compilers link the epilogue of functions to different lines. As an example, gcc links it to the closing brace of the function, whereas clang links it to the last statement of the function. This difference is important for the testsuite, since the where GDB will land after a step can be wildly different. Where possible, this dependency should be side-stepped in the testsuite, but it isn't always possible, so this commit adds a gdb_caching_proc that is able to detect where the epilogue is linked, so tests can react accordingly.
2022-09-22ld/testsuite: allow to force another directory for gcc linkerClément Chigot1-8/+15
Add a new variable "ld_testsuite_tmpdir" to enable manual configuration of the -B flag added to gcc calls. This flag ensure that gcc is invoking the linker and the assembler we want to test. When launching the testsuite outside of the build tree, the links made by the testsuite in tmpdir/ld will point to nothing. Thus, even with the PATH correctly setup towards the linker directory, gcc might end up falling back to its default linker. Hence this variable to ensure that gcc, whatever happens, is using the linker we want. ld/ChangeLog: * testsuite/config/default.exp: Allow to change -B flag with ld_testsuite_bindir variable.
2022-09-22ld/testsuite: skip bootstrap.exp when OFILES are missingClément Chigot1-0/+6
OFILES are normally provided through an environment variable set by Makefiles. However, when launching the testsuite directly through runtest outside the build tree, it can be hard to retrieve them. Thus, they can be missing. Instead of letting tcl raise an error when trying to access this OFILES variable, skip bootstrap.exp if it doesn't exist. ld/ChangeLog: * testsuite/ld-bootstrap/bootstrap.exp: Skip if OFILES is missing
2022-09-22RISC-V: Remove "b" operand type from disassemblerTsukasa OI1-1/+0
There are a few operand types not used by any RISC-V instructions. - Cx - Vf - Ve - [ - ] - b But most of them has a reasoning to keep them: - Cx : Same as "Ct" except it has a constraint to have rd == rs2 (similar to "Cw"). Although it hasn't used, its role is clear enough to implement a new instruction with this operand type. - Vf, Ve : Used by vector AMO instructions (not ratified and real instructions are not upstreamed yet). - [, ] : Unused tokenization symbols. Reserving them is not harmful and a vendor may use this symbol for special purposes. ... except "b". I could not have found any reference to this operand type except it works like the "s" operand type. Historically, it seems... it's just unused from the beginning. Its role is not clear either. On such cases, we should vacate this room for the new operand type with much clearer roles. opcodes/ChangeLog: * riscv-dis.c (print_insn_args): Remove 'b' operand type.
2022-09-22RISC-V: Add macro-only operands to validate_riscv_insnTsukasa OI1-0/+3
Although they are not (and should not be) reachable, following macro-only operands are parsed in the `validate_riscv_insn' function and ignored. That function also notes that they are macro-only. - "A" - "B" - "I" Following this convention, this commit adds three remaining macro-only operands to this function. By doing this, we could instead choose to reject those operands from appearing in regular instructions later. - "c" (used by call, tail and jump macros) - "VM" (used by vmsge.vx and vmsgeu.vx macros) - "VT" (likewise) gas/ChangeLog: * config/tc-riscv.c (validate_riscv_insn): Add "c", "VM" and "VT" macro-only operand types.
2022-09-21gprofng: fix -Wduplicated-cond warningVladimir Mezentsev1-1/+1
gprofng/ChangeLog 2022-09-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * src/collctrl.cc: Fix -Wduplicated-cond warning.
2022-09-22Automatic date update in version.inGDB Administrator1-1/+1
2022-09-22bfd BLD-POTFILES.in dependenciesAlan Modra2-4/+4
A file that consists of a list of files doesn't depend on those files being built. This patch came from trying to avoid a maintainer-mode make -j bug, where the recipe for targmatch.h was being run twice in parallel. Typical output shown below. make[2]: Entering directory '/build/gas/all/bfd' GEN bfdver.h GEN elf32-target.h GEN elf64-target.h GEN targmatch.h Making info in po make[3]: Entering directory '/build/gas/all/bfd/po' cd .. && make po/SRC-POTFILES.in cd .. && make po/BLD-POTFILES.in make[4]: Entering directory '/build/gas/all/bfd' GEN elf32-aarch64.c GEN elf64-aarch64.c GEN elf32-ia64.c GEN elf64-ia64.c GEN elf32-loongarch.c GEN elf64-loongarch.c GEN elf32-riscv.c GEN elf64-riscv.c GEN peigen.c GEN pepigen.c GEN pex64igen.c GEN pe-aarch64igen.c GEN targmatch.h make[4]: Entering directory '/build/gas/all/bfd' CCLD doc/chew.stamp mv: cannot stat 'targmatch.new': No such file or directory make[4]: *** [Makefile:2325: targmatch.h] Error 1 * Makefile.am (po/BLD-POTFILES.in): Don't depend on $(BLD_POTFILES). (po/SRC-POTFILES.in): Don't depend on $(SRC_POTFILES).
2022-09-21gdbsupport: move fileio_errno_to_host to fileio.{h,cc} and renameSimon Marchi4-108/+61
gdb_bfd.c and remote.c contain identical implementations of a fileio_error -> errno function. Factor that out to gdbsupport/fileio.{h,cc}. Rename it fileio_error_to_host, for symmetry with host_to_fileio_error. Change-Id: Ib9b8807683de2f809c94a5303e708acc2251a0df
2022-09-21gdbsupport: convert FILEIO_* macros to an enumSimon Marchi12-132/+142
Converting from free-form macros to an enum gives a bit of type-safety. This caught places where we would assign host error numbers to what should contain a target fileio error number, for instance in target_fileio_pread. I added the FILEIO_SUCCESS enumerator, because remote.c:remote_hostio_parse_result initializes the remote_errno output variable to 0. It seems better to have an explicit enumerator than to assign a value for which there is no enumerator. I considered initializing this variable to FILEIO_EUNKNOWN instead, such that if the remote side replies with an error and omits the errno value, we'll get an errno that represents an error instead of 0 (which reprensents no error). But it's not clear what the consequences of that change would be, so I prefer to err on the side of caution and just keep the existing behavior (there is no intended change in behavior with this patch). Note that remote_hostio_parse_resul still reads blindly what the remote side sends as a target errno into this variable, so we can still end up with a nonsensical value here. It's not good, but out of the scope of this patch. Convert host_to_fileio_error and fileio_errno_to_host to return / accept a fileio_error instead of an int, and cascade the change in the whole chain that uses that. Change-Id: I454b0e3fcf0732447bc872252fa8e57d138b0e03
2022-09-21gdbsupport: move include/gdb/fileio.h contents to fileio.hSimon Marchi7-150/+114
I don't see why include/gdb/fileio.h is placed there. It's not installed by "make install", and it's not included by anything outside of gdb/gdbserver/gdbsupport. Move its content back to gdbsupport/fileio.h. I have omitted the bits inside an `#if 0`, since it's obviously not used, as well as the "limits" constants, which are also unused. Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9
2022-09-21gdbsupport: change path_join parameter to array_view<const char *>Simon Marchi3-10/+10
When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single character name, we hit this assertion failure: $ ./gdb -q --data-directory=data-directory -nx ./x /usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. The backtrace: #3 0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60 #4 0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239 #5 0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203 #6 0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84 #7 0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122 #8 0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471 #9 0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513 #10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209 #11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319 #12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344 #13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 The problem is this line in path_join: gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path)); ... where `path` is "x". IS_ABSOLUTE_PATH eventually calls HAS_DRIVE_SPEC_1: #define HAS_DRIVE_SPEC_1(dos_based, f) \ ((f)[0] && ((f)[1] == ':') && (dos_based)) This macro accesses indices 0 and 1 of the input string. However, `f` is a string_view of length 1, so it's incorrect to try to access index 1. We know that the string_view's underlying object is a null-terminated string, so in practice there's no harm. But as far as the string_view is concerned, index 1 is considered out of bounds. This patch makes the easy fix, that is to change the path_join parameter from a vector of to a vector of `const char *`. Another solution would be to introduce a non-standard gdb::cstring_view class, which would be a view over a null-terminated string. With that class, it would be correct to access index 1, it would yield the NUL character. If there is interest in having this class (it has been mentioned a few times in the past) I can do it and use it here. This was found by running tests such as gdb.ada/arrayidx.exp, which produce 1-char long filenames, so adding a new test is not necessary. Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi150-1323/+1320
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: add type::length / type::set_lengthSimon Marchi14-116/+119
Add the `length` and `set_length` methods on `struct type`, in order to remove the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi97-687/+683
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-09-21gdb: add type::target_type / type::set_target_typeSimon Marchi10-61/+70
Add the `target_type` and `set_target_type` methods on `struct type`, in order to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161
2022-09-21RISC-V: Fix riscv_set_tso declarationTsukasa OI1-1/+1
To avoid -Werror=strict-prototypes, this commit changes () to (void). This is because "()" possibly means a function prototype with indeterminate arguments on old C standards. gas/ChangeLog: * config/tc-riscv.c (riscv_set_tso): Fix declaration.
2022-09-21PR29566, objdump -p considers an empty .gnu.version_r invalidAlan Modra1-5/+6
Allow and ignore an empty section. PR 29566 * elf.c (bfd_section_from_shdr): Don't set elf_dynverdef or elf_dynverref for empty sections. (_bfd_elf_slurp_version_tables): Remove now redundant tests.
2022-09-21RISC-V: Set EF_RISCV_TSO also on .option archTsukasa OI1-0/+3
This is a minor fix to commit 96462b012988d35ebb1137a2ad9fd0a96547d79a ("RISC-V: Implement Ztso extension"). Currently, it sets EF_RISCV_TSO ELF flag when initial ISA string contains the 'Ztso' extension. However, GAS has a way to update the ISA string: ".option arch". When the architecture is updated by ".option arch", EF_RISCV_RVC ELF flag is set when the 'C' extension is detected. Analogously, this commit sets the EF_RISCV_TSO when the 'Ztso' extension is detected. gas/ChangeLog: * config/tc-riscv.c (s_riscv_option): Set TSO ELF flag if the 'Ztso' extension is specified via ".option arch" directive.
2022-09-21PR29573, addr2line doesn't display file/line for local symbolsAlan Modra1-18/+16
The DWARF standard is clear that DW_AT_linkage_name is optional. Compilers may not provide the attribute on functions and variables, even though the language mangles names. g++ does not for local variables and functions. Without DW_AT_linkage_name, mangled object file symbols can't be directly matched against the source-level DW_AT_name in DWARF info. One possibility is demangling the object file symbols, but that comes with its own set of problems: 1) A demangler might not be available for the compiler/language. 2) Demangling doesn't give the source function name as stored in DW_AT_name. Class and template parameters must be stripped at least. So this patch takes a simpler approach. A symbol matches DWARF info if the DWARF address matches the symbol address, and if the symbol name contains the DWARF name as a sub-string. Very likely the name matching is entirely superfluous. PR 29573 * dwarf.c (lookup_symbol_in_function_table): Match a symbol containing the DWARF source name as a substring. (lookup_symbol_in_variable_table): Likewise. (_bfd_dwarf2_find_nearest_line_with_alt): If stash_find_line_fast returns false, fall back to comp_unit_find_line.
2022-09-21dwarf2.c: simplify best_fit_len testsAlan Modra1-32/+22
* dwarf2.c (lookup_address_in_function_table): Simplify best_fit_len test. (info_hash_lookup_funcinfo): Likewise. (lookup_symbol_in_function_table): Likewise, also reorder tests and check "file" is set. (lookup_symbol_in_variable_table): Reorder tests.
2022-09-21dwarf2.c: mangle_styleAlan Modra1-11/+33
non_mangled incorrectly returned "true" for Ada. Correct that, and add a few more non-mangled entries. Return a value suitable for passing to cplus_demangle to control demangling. * dwarf2.c: Include demangle.h. (mangle_style): Rename from non_mangled. Return DMGL_* value to suit lang. Adjust all callers.
2022-09-21dwarf2.c remove varinfo and funcinfo sec fieldAlan Modra1-19/+3
The "sec" field in these structures is only set and used in lookup functions. It always starts off as NULL. So the only possible effect of the field is to modify the return of the lookup, which was its purpose back in 2005 when HJ fixed PR990. Since then we solved the problem of relocatable object files with the fix for PR2338, so this field is now redundant. * dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field. (lookup_symbol_in_function_table): Don't set or test "sec". (lookup_symbol_in_variable_table): Likewise. (info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise.
2022-09-21configure: Pass CPPFLAGS_FOR_BUILD to subdirsTsukasa OI2-0/+5
Because CPPFLAGS_FOR_BUILD is used in some subdirectories (through bfd/warning.m4), not AC_SUBSTing the variable causes minor issues. Fortunately, it didn't cause severe errors but error messages related to @CPPFLAGS_FOR_BUILD@ (not AC_SUBSTed CPPFLAGS_FOR_BUILD variable passed to subdirectories through Makefile) remain in config.log. To avoid invalid invocation of preprocessor for build environment, we need to set proper CPPFLAGS_FOR_BUILD (may be empty) and pass it to subdirectories that need it. This is what this commit does. ChangeLog: * configure.ac: Pass CPPFLAGS_FOR_BUILD to subdirectories. * configure: Regenerate.
2022-09-21RISC-V: Implement Ztso extensionShihua6-0/+29
This patch support ZTSO extension. It will turn on the tso flag for elf_flags once we have enabled Ztso extension. This is intended to implement v0.1 of the proposed specification which can be found in Chapter 25 of, https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf. bfd\ChangeLog: * elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Set TSO flag. * elfxx-riscv.c: Add Ztso's arch. binutils\ChangeLog: * readelf.c (get_machine_flags): Set TSO flag. gas\ChangeLog: * config/tc-riscv.c (riscv_set_tso): Ditto. (riscv_set_arch): Ditto. * testsuite/gas/riscv/ztso.d: New test. include\ChangeLog: * elf/riscv.h (EF_RISCV_TSO): Ditto.
2022-09-21RISC-V: Always generate R_RISCV_CALL_PLT reloc for call in assembler.Nelson Chu4-36/+32
Since we have the same behaviors of CALL and CALL_PLT relocs in linker for now, https://github.com/bminor/binutils-gdb/commit/3b1450b38c644f99aa2e211747b428b9f8d15cca And the psabi already deprecate the CALL reloc, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0 Therefore, we should always generate R_RISCV_CALL_PLT reloc for call, even if it has @plt postfix. I believe LLVM (https://reviews.llvm.org/D132530) already support this, so GNU as should do the same thing. gas/ * config/tc-riscv.c (riscv_ip): Always generate CALL_PLT reloc for call, even if it has @plt postfix. * testsuite/gas/riscv/no-relax-reloc.d: Updated CALL to CALL_PLT. * testsuite/gas/riscv/relax-reloc.d: Likewise. ld/ * testsuite/ld-riscv-elf/variant_cc-r.d: Updated CALL to CALL_PLT.
2022-09-21Automatic date update in version.inGDB Administrator1-1/+1
2022-09-21Re: PowerPC64 pcrel got relocs against local symbolsAlan Modra1-6/+52
The last patch wasn't all that shiny. There are rather a lot more relocations that can hit the assertion in md_apply_fix if the symbol is local or absolute. Fix them all. * config/tc-ppc.c (ppc_force_relocation): Add all relocs that expect a symbol in md_apply_fix. Remove tls pcrel relocs already covered in general tls match range.
generated by cgit v1.1 at 2025-09-22 05:27:17 +0000