aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-05arm: remove options to select the FPARichard Earnshaw3-26/+2
Remove the command-line options to choose the FPA (or FPE - an emulated FPA). From this point on it should be impossible to assemble the old FPA instructions.
2024-06-05arm: change default FPUs from FPA to noneRichard Earnshaw1-62/+63
Change the cases where the default FPU was FPA to none. This should ensure that any code that used settings to pick the floating-point order will not silently produce a different output. The options that explicitly set the FPA remain for the moment.
2024-06-05arm: redirect fp constant data directives through a wrapperRichard Earnshaw12-10/+55
Assembler directives such as .float, or .double are handled by generic code, but on Arm, their output can vary depeding on the type of FPU begin targetted. When we remove FPA support we don't want to silently generate different code for processors that previously defaulted to the FPA, so redirect these directives through a wrapper function that checks the FPU is enabled; we use the legacy -mno-fpu in the test to catch this. Also fix a few tests so that they won't start to fail on targets (eg arm-wince-pe) where there is no default format for the FPU and we pick this from the default processor type.
2024-06-05arm: adjust FPU selection logicRichard Earnshaw1-9/+2
The logic here seems to be overly complex, so simplify it a bit. One particular problem was that using the legacy -mno-fpu option was not working properly, as this has all the feature bits set to zero causing the code to then pick a different FPU as the default. Fix this by only selecting an FPU as a fallback if the code has not otherwise selected one: there was only one route by which this could happen. This patch is really a pre-cursor to the following one where we want to make no-fpu internally a fall-back position for some legacy processors where previously we would have dropped back to the FPA.
2024-06-05arm: default to softvfp on armv6 or later coresRichard Earnshaw1-17/+17
From armv6 onwards a lot of cores started to come with a physical VFP implementation; but many still did not and in some cases there are both variants. For the cores that lacked a physical VFP we would fall back to FPU_NONE if the platform/ABI did not mandate something else. To make matters worse, FPU_NONE is internal state used to imply soft-fpa (ie a mixed-endian double format), so any use of .double in hand-written assembly is almost certainly generating incorrect output. That's undesirable, all these cores should really default to a softvfp model.
2024-06-05arm: rename FPU_ARCH_VFP to FPU_ARCH_SOFTVFPRichard Earnshaw6-59/+97
FPU_ARCH_VFP has always meant VFP floating-point format (natural FP word order) but without any VFP instructions. But the name FPU_ARCH_VFP is potentially confusing. This patch just changes the name to make the meaning clearer.
2024-06-05arm: remove FPA related testsRichard Earnshaw27-1858/+119
Remove various tests of the FPA instruction set and relocation support.
2024-06-05Fix illegal memory access when bfd_get_section_contents is called with a ↵Nick Clifton2-10/+41
NULL section pointer. PR 31843
2024-06-05RISC-V: Tidy vendor core-v extension gas testcasesNelson Chu146-1629/+1393
1. Combined testcases into one if they use same extention name. 2. Likewise for the fail testcases. 3. Renamed with x-cv prefix, just like what other vendors did. gas/ * testsuite/gas/riscv/cv-alu-*: Combined and renamed to x-cv-alu. Likewise for fail testcases, to x-cv-alu-fail*. * testsuite/gas/riscv/cv-bi-*: Likewise, but renamed to x-cv-bi and x-cv-bi-fail. * testsuite/gas/riscv/cv-elw-*: Likewise, but renamed to x-cv-elw and x-cv-elw-fail. * testsuite/gas/riscv/cv-mac-*: Likewise, but renamed to x-cv-mac and x-cv-mac-fail. * testsuite/gas/riscv/cv-mem-*: Likewise, but renamed to x-cv-mem and x-cv-mem-fail.
2024-06-05RISC-V: Add support for XCVmem extension in CV32E40PMary Bennett72-0/+811
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html Contributors: Mary Bennett <mary.bennett682@gmail.com> Nandni Jamnadas <nandni.jamnadas@embecosm.com> Pietra Ferreira <pietra.ferreira@embecosm.com> Charlie Keaney Jessica Mills Craig Blackmore <craig.blackmore@embecosm.com> Simon Cook <simon.cook@embecosm.com> Jeremy Bennett <jeremy.bennett@embecosm.com> Helene Chelin <helene.chelin@embecosm.com> bfd/ChangeLog: * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvmem` instruction class. (riscv_multi_subset_supports_ext): Likewise. gas/ChangeLog: * doc/c-riscv.texi: Note XCVmem as an additional ISA extension for CORE-V. * testsuite/gas/riscv/cv-mem-fail-march.d: New test. * testsuite/gas/riscv/cv-mem-fail-march.l: New test. * testsuite/gas/riscv/cv-mem-fail-march.s: New test. * testsuite/gas/riscv/cv-mem-fail-operand-01.d: New test. * testsuite/gas/riscv/cv-mem-fail-operand-01.l: New test. * testsuite/gas/riscv/cv-mem-fail-operand-01.s: New test. * testsuite/gas/riscv/cv-mem-fail-operand-02.d: New test. * testsuite/gas/riscv/cv-mem-fail-operand-02.l: New test. * testsuite/gas/riscv/cv-mem-fail-operand-02.s: New test. * testsuite/gas/riscv/cv-mem-fail-operand-03.d: New test. * testsuite/gas/riscv/cv-mem-fail-operand-03.l: New test. * testsuite/gas/riscv/cv-mem-fail-operand-03.s: New test. * testsuite/gas/riscv/cv-mem-fail-operand-04.d: New test. * testsuite/gas/riscv/cv-mem-fail-operand-04.l: New test. * testsuite/gas/riscv/cv-mem-fail-operand-04.s: New test. * testsuite/gas/riscv/cv-mem-fail-operand-05.d: New test. * testsuite/gas/riscv/cv-mem-fail-operand-05.l: New test. * testsuite/gas/riscv/cv-mem-fail-operand-05.s: New test. * testsuite/gas/riscv/cv-mem-lbpost.d: New test. * testsuite/gas/riscv/cv-mem-lbpost.s: New test. * testsuite/gas/riscv/cv-mem-lbrr.d: New test. * testsuite/gas/riscv/cv-mem-lbrr.s: New test. * testsuite/gas/riscv/cv-mem-lbrrpost.d: New test. * testsuite/gas/riscv/cv-mem-lbrrpost.s: New test. * testsuite/gas/riscv/cv-mem-lbupost.d: New test. * testsuite/gas/riscv/cv-mem-lbupost.s: New test. * testsuite/gas/riscv/cv-mem-lburr.d: New test. * testsuite/gas/riscv/cv-mem-lburr.s: New test. * testsuite/gas/riscv/cv-mem-lburrpost.d: New test. * testsuite/gas/riscv/cv-mem-lburrpost.s: New test. * testsuite/gas/riscv/cv-mem-lhpost.d: New test. * testsuite/gas/riscv/cv-mem-lhpost.s: New test. * testsuite/gas/riscv/cv-mem-lhrr.d: New test. * testsuite/gas/riscv/cv-mem-lhrr.s: New test. * testsuite/gas/riscv/cv-mem-lhrrpost.d: New test. * testsuite/gas/riscv/cv-mem-lhrrpost.s: New test. * testsuite/gas/riscv/cv-mem-lhupost.d: New test. * testsuite/gas/riscv/cv-mem-lhupost.s: New test. * testsuite/gas/riscv/cv-mem-lhurr.d: New test. * testsuite/gas/riscv/cv-mem-lhurr.s: New test. * testsuite/gas/riscv/cv-mem-lhurrpost.d: New test. * testsuite/gas/riscv/cv-mem-lhurrpost.s: New test. * testsuite/gas/riscv/cv-mem-lwpost.d: New test. * testsuite/gas/riscv/cv-mem-lwpost.s: New test. * testsuite/gas/riscv/cv-mem-lwrr.d: New test. * testsuite/gas/riscv/cv-mem-lwrr.s: New test. * testsuite/gas/riscv/cv-mem-lwrrpost.d: New test. * testsuite/gas/riscv/cv-mem-lwrrpost.s: New test. * testsuite/gas/riscv/cv-mem-sbpost.d: New test. * testsuite/gas/riscv/cv-mem-sbpost.s: New test. * testsuite/gas/riscv/cv-mem-sbrr.d: New test. * testsuite/gas/riscv/cv-mem-sbrr.s: New test. * testsuite/gas/riscv/cv-mem-sbrrpost.d: New test. * testsuite/gas/riscv/cv-mem-sbrrpost.s: New test. * testsuite/gas/riscv/cv-mem-shpost.d: New test. * testsuite/gas/riscv/cv-mem-shpost.s: New test. * testsuite/gas/riscv/cv-mem-shrr.d: New test. * testsuite/gas/riscv/cv-mem-shrr.s: New test. * testsuite/gas/riscv/cv-mem-shrrpost.d: New test. * testsuite/gas/riscv/cv-mem-shrrpost.s: New test. * testsuite/gas/riscv/cv-mem-swpost.d: New test. * testsuite/gas/riscv/cv-mem-swpost.s: New test. * testsuite/gas/riscv/cv-mem-swrr.d: New test. * testsuite/gas/riscv/cv-mem-swrr.s: New test. * testsuite/gas/riscv/cv-mem-swrrpost.d: New test. * testsuite/gas/riscv/cv-mem-swrrpost.s: New test. * testsuite/gas/riscv/march-help.l: Add xcvmem string. include/ChangeLog: * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros for XCVmem. * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros for XCVmem. (enum riscv_insn_class): Add the XCVmem instruction class. opcodes/ChangeLog: * riscv-opc.c: Add XCVmem instructions.
2024-06-05RISC-V: Add support for XCVbi extension in CV32E40PMary Bennett24-1/+124
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html Contributors: Mary Bennett <mary.bennett682@gmail.com> Nandni Jamnadas <nandni.jamnadas@embecosm.com> Pietra Ferreira <pietra.ferreira@embecosm.com> Charlie Keaney Jessica Mills Craig Blackmore <craig.blackmore@embecosm.com> Simon Cook <simon.cook@embecosm.com> Jeremy Bennett <jeremy.bennett@embecosm.com> Helene Chelin <helene.chelin@embecosm.com> Nazareno Bruschi <nazareno.bruschi@embecosm.com> Lin Sinan include/ChangeLog: * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros for XCVbi. * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros for XCVbi. (enum riscv_insn_class): Add the XCVbi instruction class. gas/ChangeLog: * config/tc-riscv.c (validate_riscv_insn): Add the necessary operands for the extension. (riscv_ip): Likewise. * doc/c-riscv.texi: Note XCVbi as an additional ISA extension for CORE-V. * testsuite/gas/riscv/cv-bi-beqimm.d: New test. * testsuite/gas/riscv/cv-bi-beqimm.s: New test. * testsuite/gas/riscv/cv-bi-bneimm.d: New test. * testsuite/gas/riscv/cv-bi-bneimm.s: New test. * testsuite/gas/riscv/cv-bi-fail-march.d: New test. * testsuite/gas/riscv/cv-bi-fail-march.l: New test. * testsuite/gas/riscv/cv-bi-fail-march.s: New test. * testsuite/gas/riscv/cv-bi-fail-operand-01.d: New test. * testsuite/gas/riscv/cv-bi-fail-operand-01.l: New test. * testsuite/gas/riscv/cv-bi-fail-operand-01.s: New test. * testsuite/gas/riscv/cv-bi-fail-operand-02.d: New test. * testsuite/gas/riscv/cv-bi-fail-operand-02.l: New test. * testsuite/gas/riscv/cv-bi-fail-operand-02.s: New test. * testsuite/gas/riscv/cv-bi-fail-operand-03.d: New test. * testsuite/gas/riscv/cv-bi-fail-operand-03.l: New test. * testsuite/gas/riscv/cv-bi-fail-operand-03.s: New test. * testsuite/gas/riscv/march-help.l: Add xcvbi string. include/ChangeLog: * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros for XCVbi. * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros for XCVbi. (enum riscv_insn_class): Add the XCVbi instruction class. opcodes/ChangeLog: * riscv-dis.c (print_insn_args): Add disassembly for new operand. * riscv-opc.c: Add XCVbi instructions.
2024-06-05RISC-V: Add support for XCVelw extension in CV32E40PMary Bennett14-0/+203
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html Contributors: Mary Bennett <mary.bennett682@gmail.com> Nandni Jamnadas <nandni.jamnadas@embecosm.com> Pietra Ferreira <pietra.ferreira@embecosm.com> Charlie Keaney Jessica Mills Craig Blackmore <craig.blackmore@embecosm.com> Simon Cook <simon.cook@embecosm.com> Jeremy Bennett <jeremy.bennett@embecosm.com> Helene Chelin <helene.chelin@embecosm.com> bfd/ChangeLog: * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvelw` instruction class. (riscv_multi_subset_supports_ext): Likewise. gas/ChangeLog: * doc/c-riscv.texi: Note XCVelw as an additional ISA extension for CORE-V. * testsuite/gas/riscv/cv-elw-fail.d: New test. * testsuite/gas/riscv/cv-elw-fail.l: New test. * testsuite/gas/riscv/cv-elw-fail.s: New test. * testsuite/gas/riscv/cv-elw-fail-march.d: New test. * testsuite/gas/riscv/cv-elw-fail-march.l: New test. * testsuite/gas/riscv/cv-elw-fail-march.s: New test. * testsuite/gas/riscv/cv-elw-pass.d: New test. * testsuite/gas/riscv/cv-elw-pass.s: New test. * testsuite/gas/riscv/march-help.l: Add xcvelw string. opcodes/ChangeLog: * riscv-opc.c: (riscv_opcode) Add event load instructions. include/ChangeLog: * opcode/riscv-opc.h: Add corresponding MATCH and MASK instruction opcode macros. * opcode/riscv.h (riscv_insn_class): Add INSN_CLASS_XCVELW.
2024-06-05gdb/testsuite: remove trailing \r from rust_llvm_version resultAndrew Burgess1-1/+2
I noticed that the value returned by rust_llvm_version had a trailing carriage return. I don't think this is causing any problems right now, but looking at the code I don't think this was the desired behaviour. The current code runs 'rustc --version --verbose', splits the output at each '\n' and then loops over every line looking for the line that contains the LLVM version. There are two problems here. First, at the end of each captured line we have '\r\n', so when we split the lines on '\n', each of the lines will still end with a '\r' character. Second, though we loop over the lines, when we try to compare the line contents we actually compare the unsplit full output. Luckily this still finds the match, but this renders the loop over lines redundant. This commit makes two fixes: 1. I use regsub to convert all '\r\n' sequences to '\n'; now when we split on '\n' the lines will not end in '\r'. 2. Within the loop over lines block I now check the line contents rather than the unsplit full output; now we capture a value without a trailing '\r'. There's only one test (gdb.rust/simple.exp) that uses rust_llvm_version, and it doesn't care if there's a trailing '\r' or not, so this change should make no difference there. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-05gdb: more filename styling in remote.c and target.cAndrew Burgess2-9/+17
I spotted a few more places where we could apply filename styling in remote.c and target.c. Other than the styling, there should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-05Automatic date update in version.inGDB Administrator1-1/+1
2024-06-04Return global scope from DAP scopes requestTom Tromey6-4/+115
A co-worker requested that the DAP code emit a scope for global variables. It's not really practical to do this for all globals, but it seemed reasonable to do this for globals coming from the frame's compilation unit. For Ada in particular, this is convenient as it exposes package-scoped variables. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-06-04Convert DAP disassemble code to use Block hashingTom Tromey1-4/+3
This changes the DAP disassemble code to use the new Block hashing, storing the already-visited blocks in a set rather than a list.
2024-06-04Memoize gdb.Block and make them hashableTom Tromey2-64/+83
In subsequent patches, it's handy if gdb.Block is hashable, so it can be stored in a set or a dictionary. However, doing this in a straightforward way is not really possible, because a block isn't truly immutable -- it can be invalidated. And, while this isn't a real problem for my use case (in DAP the maps are only used during a single stop), it seemed error-prone. This patch instead takes the approach of using the gdb.Block's own object identity to allow hashing. This seems fine because the contents don't affect the hashing. In order for this to work, though, the blocks have to be memoized -- two requests for the same block must return the same object. This also allows (actually, requires) the simplification of the rich-compare method for blocks. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-06-04Put "source" into DAP scopeTom Tromey2-1/+5
I noticed a FIXME comment in the DAP code about adding a "source" field to a scope. This is easy to implement; I don't know why I didn't do this originally.
2024-06-04Remove a couple unnecessary castsTom Tromey1-2/+2
After the previous bcache change, a couple of casts in objfiles.h are now redundant.
2024-06-04Make bcache more type-safeTom Tromey4-12/+33
The bcache uses memcpy to make copies of the data passed to it. In C++, this is only safe for trivially-copyable types. This patch changes bcache to require this property, and slightly changes the API to make it easier to use when copying a single object. It also makes the new 'insert' template methods return the correct type.
2024-06-04Some constification in psymtabTom Tromey2-33/+30
This patch changes some spots in psymtab.[ch] to use 'const'. This is just preparation for a subsequent patch. Note that psymbols are conceptually const, and since they were changed to be objfile-indepdendent, they are truly never modified -- which is what makes this patch reasonably short.
2024-06-04Rely on std::uncaught_exceptionsTom Tromey1-7/+1
std::uncaught_exceptions is a C++17 feature, so I think we can remove this conditional code from inferior.h.
2024-06-04Add myself to gdb/MAINTAINERSDmitry Neverov1-0/+1
2024-06-04src-release.sh: fix adjusting files permissions and cleaningRostislav Krasny1-4/+48
PR 31800
2024-06-04gdb/testsuite: tests for debug lookup within the sysrootAndrew Burgess2-0/+215
Add tests for looking up debug information within the sysroot via both build-id and gnu_debuglink. I wanted to ensure that the gnu_debuglink test couldn't make use of build-ids, so I added the 'no-build-id' flag to gdb_compile. As these tests rely on setting the sysroot, if I'm running a dynamically linked executable, GDB will try to find all shared libraries within the sysroot. This would mean I'd have to figure out and copy all shared libraries the executable uses, certainly possible, but a bit of a pain. So instead, I've just compiled the test executable as a static binary. Now there are no shared library dependencies. I can now split the debug information out from the test binary, and place it within the sysroot. When GDB is started and the executable loaded, we can check that GDB is finding the debug information within the sysroot. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 Approved-By: Tom de Vries <tdevries@suse.de>
2024-06-04gdb/testsuite: make gdb_gnu_strip_debug consistentAndrew Burgess3-37/+25
While writing a test I realised that the default behaviour of gdb_gnu_strip_debug doesn't match its comment. The comment says that the function takes a FILENAME, and splits the file into FILENAME.stripped and FILENAME.debug, leaving FILENAME unchanged. The comment says that a .gnu_debuglink will be added to FILENAME.stripped. However, this is not true, FILENAME.stripped is created, with no debug information. FILENAME.debug is created containing the debug information. But, when adding the .gnu_debuglink we take FILENAME.stripped as the input, and then overwrite FILENAME with the output. As a result, FILENAME.stripped does not include a .gnu_debuglink, while FILENAME contains the .gnu_debuglink and no debug information! The users of gdb_gnu_strip_debug can be split into two groups, those who are using the .gnu_debuglink, these tests are all written assuming that FILENAME is updated. Then there are some tests that only rely on gdb_gnu_strip_debug's ability to split out the debug information, these tests are then going to do a lookup based on the build-id, these tests don't require the .gnu_debuglink. These tests use the FILENAME.stripped output file. This all seems too confused to me. As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I propose that we just make that the actual, advertised behaviour of this proc. So now, gdb_gnu_strip_debug will take FILENAME, and will split the debug information out into FILENAME.debug. The debug information will then be stripped from FILENAME, and by default a .gnu_debuglink will be added to FILENAME pointing to FILENAME.debug. I've updated the two tests that actually relied on FILENAME.stripped to instead just use FILENAME. One of the tests was doing a build-id based lookup, but was still allowing the .gnu_debuglink to be added to FILENAME, I've updated this test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops the .gnu_debuglink from being added. All of the tests that call gdb_gnu_strip_debug still pass for me. Acked-By: Tom de Vries <tdevries@suse.de>
2024-06-04gdb/Makefile.in: silence recipe for creating .deps/ directoriesAndrew Burgess1-1/+1
When building in a fresh directory we'll see some output like this: /bin/sh ../../src/gdb/../mkinstalldirs arch/.deps mkdir -p -- arch/.deps /bin/sh ../../src/gdb/../mkinstalldirs cli/.deps mkdir -p -- cli/.deps /bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps mkdir -p -- dwarf2/.deps ... etc ... this commit uses silent-rules.mk to silence this output, now we'll see: GEN arch/.deps GEN cli/.deps GEN dwarf2/.deps ... etc ... The recipe that currently generates these directories uses mkinstalldirs, as I mention in commit 032e5e0c0c08977, mkinstalldirs is deprecated and 'install-sh -d' should be used instead. This silences the 'mkdir -p -- ...' part of the output. There should be no change in what is actually built after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-04LoongArch: Disable linker relaxation if set the address of section or segmentmengqinggang3-0/+41
If set the address of section or segment, the offset from pc to symbol may become bigger and cause overflow.
2024-06-04LoongArch: Make align symbol be in same section with alignment directivemengqinggang9-33/+104
R_LARCH_ALIGN (psABI v2.30) requires a symbol index. The symbol is only created at the first time to handle alignment directive. This means that all other sections may use this symbol. If the section of this symbol is discarded, there may be problems. Search it in its own section. Remove elf_backend_data.is_rela_normal() function added at commit daeda14191c. Co-authored-by: Jinyang He <hejinyang@loongson.cn> Reported-by: WANG Xuerui <git@xen0n.name> Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t
2024-06-04arm: testsuite: fix msdos line endings in testsRichard Earnshaw2-18/+18
A couple of the tests in the testsuite were at some point in the past committed with DOS-style CRLF line endings. This potentially causes email problems if the tests are touched in the middle of a large patch series so convert them to standard Un*x line endings.
2024-06-04Automatic date update in version.inGDB Administrator1-1/+1
2024-06-03gprofng: add hardware counters for AMD Zen4Vladimir Mezentsev3-1/+889
ChangeLog 2024-06-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * common/hwctable.c: Add the hwc table for AMD Zen4. * src/hwc_amd_zen4.h: New file. * src/hwc_amd_zen3.h: Define _HWC_AMD_ZEN3_H.
2024-06-03Remove one call to can_box from TUITom Tromey1-9/+3
This removes a call to can_box from tui_source_window_base::show_source_content. can_box will always return true here. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-06-03Fix deprecation textTom Tromey1-1/+1
I noticed one spot where deprecate_cmd is called with a second argument that is not a command name. This patch fixes the problem. Regression tested on x86-64 Fedora 38.
2024-06-03Enable call of overloaded subscript operator from pythonHannes Domani3-1/+12
If you try to use the overloaded subscript operator of a class in python, it fails like this: (gdb) py print(gdb.parse_and_eval('b')[5]) Traceback (most recent call last): File "<string>", line 1, in <module> gdb.error: Cannot subscript requested type. Error while executing Python code. This simply checks if such an operator exists, and calls it instead, making this possible: (gdb) py print(gdb.parse_and_eval('b')[5]) 102 'f' Approved-By: Tom Tromey <tom@tromey.com>
2024-06-03Allow calling of convenience functions with pythonHannes Domani2-5/+24
As mentioned in PR13326, currently when you try to call a convenience function with python, you get this error: (gdb) py print(gdb.convenience_variable("_isvoid")(3)) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD). Error while executing Python code. So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as well, making this possible: (gdb) py print(gdb.convenience_variable("_isvoid")(3)) 0 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 Approved-By: Tom Tromey <tom@tromey.com>
2024-06-03src-release.sh: Use -T0 for xz compressionMark Wielaard1-1/+1
Use parallel compression to create the xz archive. On my machine (using 4 cores) this reduces the time to create binutils-2.42.50.tar.xz from 1 minute 40 seconds to 56 seconds. xz has supported -T0 since version 5.2.0 (released 2014-12-21).
2024-06-03[gdb/testsuite] Fix timeout in gdb.tui/resize-2.expTom de Vries1-3/+15
When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run into: ... tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable ^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout) ... The test-case does "Term::resize 24 80 0" while having the settings of an earlier "Term::resize 40 90", so both dimensions change. When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc: - calls stty to change one dimension, - waits for the message (enabled by "maint set tui-resize-message on") confirming the resize has happened, - calls stty to change the other dimension, and again - waits for the message confirming the resize has happened. Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the message is not printed, so stty is called twice, and afterwards we check for the results of the two resizes, which is the test that is failing. The problem is that not waiting for a response after each stty call opens up the possibility of the responses being merged. Fix this by calling Term::resize twice, changing one dimension at a time, and waiting for a single prompt redisplay after each one. Tested on x86_64-linux. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> PR testsuite/31822 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822
2024-06-03Automatic date update in version.inGDB Administrator1-1/+1
2024-06-02Fix typo in tui-data.hTom Tromey1-1/+1
I noticed a typo in a comment in tui-data.h.
2024-06-02Automatic date update in version.inGDB Administrator1-1/+1
2024-06-01Automatic date update in version.inGDB Administrator1-1/+1
2024-05-31[gdb/testsuite] New test: gdb.base/errno.expKevin Buettner2-0/+300
Printing the value of 'errno' from GDB is sometimes problematic. The situation has improved in recent years, though there are still scenarios for which "print errno" doesn't work. The test, gdb.base/errno.exp, introduced by this commit, tests whether or not GDB can print errno using a binary compiled in the following different ways: - default: no switches aside from -g (and whatever else is added by the testing framework) - macros: macro info is included in the debuginfo; this is enabled by using -g3 when using gcc or clang - static: statically linked binary - static-macros: statically linked binary w/ macro definitions included in debuginfo - pthreads: libpthread linked binary - pthreads-macros: libpthread linked binary w/ macro definitions included in debuginfo - pthreads-static: Statically linked against libpthread - pthreads-static-macros: Statically linked against libpthread w/ macro definitions For each of these, the test also creates a corefile, then loads the corefile and attempts to print errno again. Additionally, the test checks that a "masking" errno declared as a local variable will print correctly. On Linux, if the machine is missing glibc debuginfo (or you have debuginfod disabled), it's likely you'll see: (gdb) print errno 'errno' has unknown type; cast it to its declared type But if you add a cast, the value of errno is often available: (gdb) print (int) errno $1 = 42 The test detects this situation along with several others and does 'setup_xfail' for tests that will almost certainly fail. It could be argued that some of these ought to be KFAILs due to deficiencies in GDB, but I'm not entirely certain which, if any, are fixable yet. On Fedora 39, without glibc debuginfo, there are no failures, but I do see the following XFAILS: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: print errno XFAIL: gdb.base/errno.exp: macros: print (int) errno XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: print errno XFAIL: gdb.base/errno.exp: static-macros: print (int) errno XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads: print errno XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile On Fedora 39, with glibc debug info, but without libc.a (for static linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED tests. So, even when testing in less than ideal conditions, either due to lack of glibc debuginfo or lack of a libc to link against to make a static binary, there are no failures. With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40, Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs: XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: print errno XFAIL: gdb.base/errno.exp: static-macros: print (int) errno XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile On FreeBSD 13.1, the total number of XFAILs are fewer, and could be even better still if it had debug info for glibc: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: print errno XFAIL: gdb.base/errno.exp: macros: print (int) errno XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads: print errno XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile Starting with glibc-2.34, most of the pthreads library has been incorporated into libc, so finding thread-local variables using libthread_db is possible for several scenarios in which it previously wasn't. But, prior to this, accessing errno for the default scenario was a problem. This is borne out by running this new test on Fedora 34, which uses glibc-2.33: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: print (int) errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: print errno XFAIL: gdb.base/errno.exp: static-macros: print (int) errno XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile In the v3 version of this test, Tom de Vries tested on openSUSE Leap 15.5 and found a number of cases which showed a FAIL instead of an XFAIL. The v4 version of this test fixed those problems. On Leap 15.5, which uses glibc-2.31, with glibc debug info, I now see: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: print (int) errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile On Leap 15.5, with glibc debuginfo missing, the results are a little worse: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: print (int) errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: print errno XFAIL: gdb.base/errno.exp: macros: print (int) errno XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads: print errno XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile The v5 version of this test fixed failures when testing with check-read1. (Thanks to Linaro CI for finding these.) I revised the regular expressions being used so that the failures were eliminated, but the results mentioned above have not changed. The v6 version of this test fixes some nits pointed out by both Tom de Vries and Pedro Alves. One of Pedro's suggestions was to rename the test from check-errno.exp to errno.exp, so in v5, the name has changed. Tom also noticed that there were failures when using --target_board=native-extended-gdbserver. For v6, I've tested on 10 different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o glibc debuginfo, and Fedora 34) using "make check" and "make check-read1" using target boards "unix", "native-extended-gdbserver", and "native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for a total of 12 distinct test runs on each machine. I've also tested the native-only cases on FreeBSD. (Attempting to test against gdbserver on FreeBSD resulted in hangs while running the test suite.) The v7 version of this test simplifies the REs used in the uses of gdb_test_multiple by adding -wrap and removing parts of the REs which match the GDB prompt. In cases where there was a leading '.*', those were removed too. Thanks to Pedro for explaining how to use -wrap. So, bottom line, this test does not introduce any new failures on the platforms on which I've tested, but the XFAILs are certainly unfortunate. Some aren't fixable - e.g. when attempting to make a function call while debugging a core file - but I think that some of them are. I'm using this new test case as a starting point for investigating problems with printing errno. Co-Authored-By: Jan Kratochvil Approved-By: Tom de Vries <tdevries@suse.de>
2024-05-31aarch64, testsuite: avoid regexes in opcode fieldClaudio Bantaloukas2-493/+493
Some dejagnu files use regexes rather than specific encodings. This change replaces them with the explicit encodings we expect. Tested against aarch64-unknown-linux-gnu and aarch64-none-elf.
2024-05-31gas, aarch64: Fixes in texi and tests following faminmax and lut changessaurabh.jha@arm.com4-162/+162
Making two cleanups that came out of the comments from my previous patches: 1. Fixing `c-aarch64.texi` file so that the AArch64 architecture extensions are ordered alphabetically. 2. Fixing faminmax test cases so that they follow the existing test conventions.
2024-05-31Move dwarf2_per_bfd::index_addrmap to mapped_gdb_indexTom Tromey5-37/+25
dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader, so this field can be moved to mapped_gdb_index instead. Then, cooked_index_functions::find_per_cu can be removed in favor of a method on the index object. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-05-31aarch64: Add some DT_RELR ld testsSzabolcs Nagy12-0/+351
2024-05-31aarch64: Add DT_RELR supportSzabolcs Nagy5-1/+445
The logic to decide if an input relocation for a symbol becomes a particular kind of output relocation is one of the hard to maintain parts of the bfd ld backend, since it is partially repeated across elfNN_aarch64_check_relocs (where dynamic relocations are counted per symbol and input section), elfNN_aarch64_late_size_sections (where relocation sections are sized and GOT offsets assigned), elfNN_aarch64_relocate_section (where most relocations are applied and output to a relocation section), elfNN_aarch64_finish_dynamic_symbol (where some of the GOT relocations are applied and output). The DT_RELR support adds another layer to this complexity: after the output relocation sections are sized, so all dynamic relocations are accounted (in elfNN_aarch64_late_size_sections), we scan the symbols and input relocations again to decide which ones become relative relocations that can be packed. The sizes of the relocation sections are updated accordingly. This logic must be consistent with the code that applies the relocs later so each relative relocation is emitted exactly once: either in .rela.* or packed in .relr.dyn. Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that may be called repeatedly whenever the layout changes since an address change can affect the size of the packed format. Then the final content is emitted in elfNN_aarch64_finish_relative_relocs, that is called after the layout is final and before relocations are applied and emitted. These hooks are only called if DT_RELR is enabled. We only pack relative relocs that are known to be aligned in the output during .relr.dyn sizing, the potentially unaligned relative relocs are emitted normally (in .rela.*, not packed), because the format requires aligned addresses.
2024-05-31x86: reduce check_{byte,word,long,qword}_reg() overheadJan Beulich1-4/+15
These run after template matching. Therefore it is quite pointless for them to check all operands, when operand sizes matching across operands is already known. Exit the loops early in such cases. In check_byte_reg() also drop a long-stale part of a comment.
generated by cgit v1.1 at 2024-10-20 10:59:23 +0000