aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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.
2024-05-31gdb, amd64: remove unused forward declarationsFelix Willgerodt1-12/+0
These structs are not referenced anywhere anymore and seemed to have been missed at some point when their usage was removed. Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-05-31gdb, doc: Fix AVX-512 documentation.Felix Willgerodt1-1/+9
org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the docs yet. Fix that. In addition the documentation describes xmm registers with an `h` (e.g. xmm16h). I am assuming that we follow the register xml files here, which don't have the h suffix. So this removes that as well. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-05-30gdb: remove unused includes in utils.hSimon Marchi45-6/+45
Remove some includes reported as unused by clangd. Add some includes in other files that were previously relying on the transitive include. Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
2024-05-31Automatic date update in version.inGDB Administrator1-1/+1
2024-05-30gdb: remove unused includes in symfile.cSimon Marchi1-9/+1
Remove some includes reported as unused by clangd. Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6
2024-05-30gdb: remove unused includes in breakpoint.{c,h}Simon Marchi2-3/+0
Remove some includes reported as unused by clangd. Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d
2024-05-30Update binutils release documentation to include using the -z option when ↵Nick Clifton1-3/+3
invoking src-release.sh
2024-05-30src-release.sh: Support zstd compressionMark Wielaard1-2/+18
2024-05-30.gitignore: ignore .vscodeSimon Marchi1-0/+1
2024-05-30Automatic date update in version.inGDB Administrator1-1/+1
2024-05-29gdb/doc: don't have .pod targets separate to man page targetsAndrew Burgess1-6/+19
While preparing the new release it was discovered that commit: commit 824083f34c222aa7419e2ea58e82d6f230d5f531 Date: Fri Apr 12 17:47:20 2024 +0100 gdb/doc: use silent-rules.mk in the Makefile was causing problems. Given a release tar file, an attempt to build and install GDB would give an error like this: [...] TEXI2POD gdb.pod cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16. make[5]: *** [Makefile:663: gdb.pod] Error 2 The problem here is how the man pages are built, and how they are distributed within a release. Within the development (git) tree, the man page files are not part of the source tree, these files are built as needed. Within a release tar file though, the man pages are included. The idea being that a user can build and install GDB, including getting the man pages, without having to install the tools needed to generate the man pages. The man pages are generated in a two step process. First the .texi file is processed with texi2pod to create a .pod file, then this .pod file is processed to create the .1 or .5 man file. Prior to the above commit these two steps were combined into a single recipe, this meant that when a user performed a build/install from a release tree all of the dependencies, as well as the final result, were all present in the source tree, and so nothing needed to be rebuilt. However, the above commit split the two steps apart. Now we had a separate rule for building the .pod files, and the .1/.5 man page files depended on the relevant .pod file. As the .pod files are not shipped in a GDB release, this meant that one of the dependencies of the man page files was now missing. As a result if a user tried to install from a release tree a rebuild of the .pod files would be attempted, and if that succeeded then building the man pages would follow that. Unfortunately, building the .pod files would fail as the GDBvn.texi file, though present in the source tree, was not present in the build tree, which is where it is needed for the .pod file generation to work. To fix this, I propose merging the .pod creation and the .1/.5 man page creation back into a single recipe. Having these two steps split is probably the "cleaner" solution, but makes it harder for us to achieve our goal of shipping the prebuilt man page files. I've added a comment explaining what's going on (such a comment would have prevented this mistake having been made in the first place). One possibly weird thing here is that I have left both an ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S) recipes. This is 100% not going to break anything, these just print two different progress messages while executing the recipes, but I'm not sure if this is considered poor style or not. Maybe we're only supposed to have a single ECHO_* per recipe? Anyway, even if this is poor style, I figure it really is just a style thing. We can tweak this later as needed. Otherwise, this commit should fix the current issue blocking the next GDB release. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-29readelf: Use section names for displaying RELR relocsSzabolcs Nagy1-8/+24
In some cases using section names instead of symbol names for displaying an address is more useful. If the symbol falls outside the section where the address is then likely it is not useful to display the address relative to. And if symbols are stripped from a binary then printing the section that contains the address is more useful than printing <no sym>.
2024-05-29readelf: Fix symbol display for RELR relocsSzabolcs Nagy1-17/+125
Filter symbols before binary searching for the right symbol to display for a given address, such that only displayable symbols are present and at most one per address. The current logic does not handle multiple symbols for the same address well if some of them are empty, the selected symbol is not stable with respect to an unrelated symbol table change and on aarch64 often mapping symbols are displayed which is not useful. Filtering solves these problems at the cost of a linear scan of the sorted symbol table. The heuristic to select the best symbol likely could be improved, this patch aims to improve symbol display for RELR without complex logic such that the output is useful and stable for ld tests.
2024-05-29x86/Intel: warn about undue mnemonic suffixesJan Beulich37-5814/+5779
Except for very few insns mnemonic suffixes aren't permitted in Intel syntax. Warn about such for now, indicating that they will be outright refused down the road. While fiddling with testcases to address fallout, drop a few things which should never have been tested as valid Intel syntax. Also add a previously missing line to simd-suffix.d.
2024-05-29x86/Intel: SHLD/SHRD have dual meaningJan Beulich4-2/+79
Since we uniformly permit D suffixes in Intel mode whenever in AT&T mode an L suffix may be used, we need to be consistent with this. Take the easy route, despite that still leading to an anomaly which is also visible from the new testcase: shld eax, ecx, 1 shld eax, ecx, cl can mean two things with APX: SHL with a D suffix in NDD EVEX encoding, or the traditional SHLD in legacy encoding.
2024-05-29PR31796, Internal error in write_function_pdata at obj-coff-sehAlan Modra1-2/+22
PR31796 is the result of lack of aarch64 support in obj-coff-seh.c. Nick fixed this with commit 73c8603c3f. Make the seh support consistently warn in future if some archictecture is missing, rather than giving internal errors. PR 31796 * config/obj-coff-seh.c (verify_target): New function. (obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc), (obj_coff_seh_endprologue): Use it.
2024-05-29Automatic date update in version.inGDB Administrator1-1/+1
2024-05-28ld: pru: Increase the default memory region sizesDimitar Dimitrov1-2/+2
The default memory region sizes for PRU were set somewhat arbitrarily to the sizes of the most popular BeagleBone board with AM33x SoC. But the PRU toolchain documentation has always instructed to use SoC-specific spec files to override the defaults and set the correct memory sizes [1]. The small default memory sizes can cause IMEM memory region overflow even for simple printf("Hello world") programs, as usually done by Autotools checks. The stdio is simply too big to fit in 8K instruction memory. This can confuse the check and lead to wrong feature selection during configure [2]. Fix by bumping the default DMEM and IMEM memory sizes. There is no need to backport this patch. Issue was caught with a feature-rich newlib build used for daily CI. The release builds of the PRU toolchain use stripped newlib configuration, which does not overflow the IMEM region, even for 8K. [1] https://github.com/dinuxbg/gnuprumcu [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
2024-05-28Make tui_win_info::make_window non-virtualTom Tromey1-1/+2
Nothing overrides tui_win_info::make_window, so remove the "virtual". Tested by rebuilding.
2024-05-28gas, aarch64: Add SVE2 lut extensionsaurabh.jha@arm.com16-131/+719
Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links: * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en These instructions use new SVE2 vector operands. They are called SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have 1 bit, 2 bit, and 3 bit indices respectively. The lsb and width of these new operands are the same as many existing operands but the convention is to give different names to fields that serve different purpose so we introduced new fields in aarch64-opc.c and aarch64-opc.h. We made a design choice for the second operand of the halfword variant of luti4 with two register tables. We could have either defined a new operand, like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With the new operand, we would need to implement constraints on register lists based on either operand or opcode flag. With existing operand, we could just existing constraint checks using opcode flag. We chose the second approach and went with SVE_ZnxN and added opcode flag to enforce lengths of vector register list operands. This way, we can reuse the existing constraint check logic.
2024-05-28gas, aarch64: Add AdvSIMD lut extensionsaurabh.jha@arm.com21-363/+1016
Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links: * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en These instructions needed definition of some new operands. We will first discuss operands for the third operand of the instructions and then discuss a vector register list operand needed for the second operand. The third operands are vectors with bit indices and without type qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12 and they have 1 bit, 2 bit, and 3 bit indices respectively. For these new operands, we defined new parsing case branch. The lsb and width of these operands are the same as many existing but the convention is to give different names to fields that serve different purpose so we introduced new fields in aarch64-opc.c and aarch64-opc.h for these new operands. For the second operand of these instructions, we introduced a new operand called LVn_LUT. This represents a vector register list with stride 1. We defined new inserter and extractor for this new operand and it is encoded in FLD_Rn. We are enforcing the number of registers in the reglist using opcode flag rather than operand flag as this is what other SIMD vector register list operands are doing. The disassembly also uses opcode flag to print the correct number of registers.
2024-05-28Use bool in thread_eventsTom Tromey7-16/+16
This changes target_ops::thread_events and target_thread_events to use 'bool'. The callers were already doing this. Tested by rebuilding. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-05-28Fix typo in assembler documentationNick Clifton1-1/+1
2024-05-28Fix: internal error in write_function_pdata at obj-coff-sehNick Clifton1-0/+5
PR 31796
2024-05-28Updated Spanish translation for the BFD sub-directory.Nick Clifton1-4754/+7118
2024-05-28opcodes: add a .gitattributes file for aarch64 autogenerated file exceptionsRichard Earnshaw1-0/+3
The autogenerated files in opcodes use spaces for indentation. Changing that would be a lot of work to little benefit, so add a local override to the white-space rules, so patches apply cleanly.
2024-05-28Add new ELF section and segment types to readelf.Nick Clifton11-323/+517
2024-05-28RISC-V: Fix U insn; replace opcode6 with opcode7 in gas/doc/c-riscv.texiJavier Mora1-22/+22
The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the bit arrangement of the simm20 immediate that belongs to the J type; It should be just `simm20[19:0]`. The current behavior of `gas` matches the proposed documentation change. Additionally, the opcode is called `opcode6` despite of having 7 bits. Rename it to `opcode7`. gas/ * doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7.
2024-05-28Automatic date update in version.inGDB Administrator1-1/+1
2024-05-27Re-run make-target-delegates.pyTom Tromey1-8/+6
I re-ran make-target-delegates.py and discovered that the tree was out of sync. This patch corrects the problem.
2024-05-28RISC-V: Fixed overwritten IRELATIVE relocs in the .rel.iplt for data reloc.Nelson Chu7-13/+44
This was originally reported by Hau Hsu <hau.hsu@sifive.com>. Similar to commit 51a8a7c2e3cc0730831963651a55d23d1fae624d We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64. This just like what did in the riscv_elf_finish_dynamic_symbol. bfd/ * elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the riscv_elf_relocate_section when handling ifunc data reloc. ld/ * testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed. * testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise. * testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise. * testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise. * testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed.
2024-05-28RISC-V: Segment fault for kernel purgatory when linking.Nelson Chu1-13/+10
This was originally reported by Ard Biesheuvel <ardb@kernel.org>. The followings are reproduce steps, https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u The segment fault happens in the riscv_elf_finish_dynamic_sections when the output got section is an ABS. Refer to MIPS code, they added an extra bfd_is_abs_section check to avoid ABS got, so this seems the right and easier way to go in the short-term. bfd/ * elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize and fill the got entries only when the got isn't an ABS section, and the size of got is larger than zero. The similar goes for gotplt, except we already reported error when the gotplt is an ABS.
generated by cgit v1.1 at 2024-11-25 11:36:51 +0000