aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
9 daysAutomatic date update in version.inGDB Administrator1-1/+1
10 daysdoc: sframe: mention errata 1 of SFrame version 2Indu Bhagat1-9/+11
With the changes of an added flag SFRAME_F_FDE_FUNC_START_PCREL, s390x support and new section type SHT_GNU_SFRAME, indicate that this document specifies the errata 1 of SFrame version 2. This will help distinguish the document / specification better from previous releases. libsframe/doc/ * sframe-spec.texi: Mention errata 1 of SFrame version 2.
10 daysAutomatic date update in version.inGDB Administrator1-1/+1
10 daysPR 33214 sparc LDM/STM/LDMA/STMA etc. FAIL on Solaris/SPARCAlan Modra1-34/+6
Delete code in compare_opcodes preferencing 1+i over i+1 and 1,i over i,1. Instead simply make the sort stable, by keeping the original table order.
10 days[gdb/tui] Fix shell command terminal settingsTom de Vries3-0/+42
In bash I have the following terminal settings: ... $ stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 ... and then in gdb using the shell command likewise: ... (gdb) shell stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 (gdb) ... and likewise using a shell session: ... (gdb) shell $ stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 $ ... But in TUI, we get different settings (removed runaway indentation for readability): ... (gdb) shell sttyspeed 38400 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel iutf8 -onlcr -icanon -echo (gdb) ... and consequently the shell is not really usable. This is PR tui/18215. The easiest way to fix this is to just temporarily leave TUI while in the shell, leaving the output of the commands in CLI mode, but that's a bit confusing. Fix this (as suggested in the PR) by restoring the initial terminal settings while in the shell command, such that also in TUI we have: ... (gdb) shell sttyspeed 38400 baud; line = 0; -brkint -imaxbel iutf8 (gdb) ... Tested on x86_64-linux. Reported-By: Doug Evans <dje@google.com> Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18215
10 daysgdb: Convert gdb/mingw-hdep.c to INIT_GDB_FILEPedro Alves1-4/+1
I noticed that my MinGW GDB did not have the "maint set console-translation-mode" command, even though the code to register it is in gdb/mingw-hdep.c. The problem is that gdb/mingw-hdep.c is not using INIT_GDB_FILE. This fixes it. Change-Id: I3aa305c517e100d4733b391a110a1b20b89fdb7f
10 daysgdb: use the location_completer for the list commandGuinevere Larsen1-0/+1
The "location_completer" function has been available for a long time, but it was seemingly never used as the completer for the list function. A quick check through git history shows that a similar completer was available for the "edit" command but wasn't added to "list" with no reasoning for it. I think "list" should use the location_completer, as it is more aware of the locspec grammar. Approved-By: Tom Tromey <tom@tromey.com>
10 daysgdb: fix copyright year in svr4-tls-tdep.cSimon Marchi1-1/+1
Change-Id: Ia03b286d9544a209197e58e59e752dc3d2715359
10 daysgdb: fix copyright year in solib-frv.hSimon Marchi1-1/+1
My mistake, I forgot to update this when merging my patch series. Change-Id: I67691c962d91221bd9a684febd7296b4b9b5999f
10 daysgdb/dwarf: apply DW_AT_bit_offset when DW_AT_data_member_location is ↵Simon Marchi1-1/+6
constant block Since commit 420d030e88 ("Handle field with dynamic bit offset"), I see: $ make check TESTS="gdb.trace/unavailable-dwarf-piece.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d y FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d z The first FAIL is: p/d x $4 = {a = 0, b = <unavailable>, c = <unavailable>, d = <unavailable>, e = <unavailable>, f = <unavailable>, g = <unavailable>, h = <unavailable>, i = <unavailable>, j = 0} (gdb) FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x When we should see: p/d x $4 = {a = 0, b = <unavailable>, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0, i = 0, j = 0} (gdb) PASS: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x The structure we print is: 0x0000004f: DW_TAG_structure_type DW_AT_name [DW_FORM_string] ("t") DW_AT_byte_size [DW_FORM_sdata] (3) DW_AT_decl_file [DW_FORM_udata] (0) DW_AT_decl_line [DW_FORM_udata] (1) 0x00000055: DW_TAG_member DW_AT_name [DW_FORM_string] ("a") DW_AT_type [DW_FORM_ref4] (0x00000019 "unsigned char") DW_AT_data_member_location [DW_FORM_exprloc] (DW_OP_plus_uconst 0x0) 0x0000005f: DW_TAG_member DW_AT_name [DW_FORM_string] ("b") DW_AT_type [DW_FORM_ref4] (0x00000019 "unsigned char") DW_AT_byte_size [DW_FORM_sdata] (1) DW_AT_bit_size [DW_FORM_sdata] (1) DW_AT_bit_offset [DW_FORM_sdata] (7) DW_AT_data_member_location [DW_FORM_exprloc] (DW_OP_plus_uconst 0x1) ... The particularity of field "b" (and the following ones, not shown here) is that they have: - a DW_AT_data_member_location of expression form, but that GDB reduces to a constant - a DW_AT_bit_offset What I think happens is that the code path taken in this particular scenario never ends up using the DW_AT_bit_offset value. Fix it by calling apply_bit_offset_to_field, like what is done when data_member_location_attr is using a constant form. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33136 Change-Id: I18e838e6c56a548495d3af332aeff3051188eaa9 Approved-By: Tom Tromey <tom@tromey.com>
10 daysgdb/dwarf: rename some variables in handle_member_locationSimon Marchi1-24/+32
For legibility, use more specific names for attribute variables and don't reuse them for different attributes. Change-Id: I98d8bb32fc64b5f6357fbc88f6fe93f2ddc8ef7c Approved-By: Tom Tromey <tom@tromey.com>
11 daysgas/NEWS: Add AArch64 updatesAlice Carlotti1-0/+8
11 daysgas/doc: Update AArch64 Architecture ExtensionsAlice Carlotti1-9/+11
Add faminmax, move a couple of misplaced entries, and improve a few other entries. The documentation now lists every recognised extension name, with the exception of a couple of aliases that are deliberately undocumented.
11 daysaarch64: Fix sve2p2/sme2p2 dependenciesAlice Carlotti1-2/+2
Change dependency on sve2/sme2 to sve2p1/sme2p1.
11 daysgas: sframe: command line option takes precedenceIndu Bhagat7-10/+44
over gas directive to emit .sframe section. Fix PR gas/33175 sframe: --gsframe=no does not disable when .cfi_sections directive with .sframe --gsframe=no should also disable generation of SFrame section when explicit CFI directive: .cfi_sections .sframe is specified in the input. This means we need to track whether SFrame generation was explicitly disabled by the user. Introduce a new enum to facilitate disambiguation between GEN_SFRAME_DEFAULT_NONE and GEN_SFRAME_DISABLED. While fixing the bug by adding the enum, keep the upcoming requirement in mind: we will also need to disambiguate between --enable-default-sframe and user-specified --gsframe/--gsframe=yes. The intent is to not display SFrame related warnings or errors like: as_bad (_(".sframe not supported for target")); for unsupported targets if --enable-default-sframe is in effect. This implies we need to have a four state enum ( GEN_SFRAME_DEFAULT_NONE, GEN_SFRAME_CONFIG_ENABLED, GEN_SFRAME_DISABLED, GEN_SFRAME_ENABLED) gas/ PR gas/33175 * dw2gencfi.c (cfi_finish): Check state of flag_gen_sframe to determine whether any SFrame section is generated. * as.h (enum gen_sframe_option): New definition. * as.c (parse_args): Keep track of whether the flag is explicitly enabled or disabled gas/testsuite/ PR gas/33175 * gas/cfi-sframe/cfi-sframe-common-1.d: Remove redundant --gsframe. * gas/cfi-sframe/cfi-sframe.exp: Add new test. * gas/cfi-sframe/cfi-sframe-common-1c.d: New test. No SFrame section if explicit --gsframe=no. * gas/cfi-sframe/cfi-sframe-common-1c.s: New test.
11 daysreadelf: objdump: sframe: fix dumping with section nameIndu Bhagat5-1/+68
Fix PR binutils/33186 - No SFrame dump if section name is not .sframe When the section name is not ".sframe", ensure that readelf and objdump are able to dump a section of type SHT_GNU_SFRAME and not fail if the user specifies the new section name. For objdump, in dump_dwarf_section (), use the match string of ".sframe" to find the corresponding debug_displays[] item for SFrame section. Doing this ensures that any call to dump_dwarf_section () with the section pointing to the SFrame section (with name possibly different from ".sframe") will successfully dump the SFrame section. If the SFrame section is named anything but ".sframe", and user does not specify the name of the SFrame section either, the documented behaviour is that the default section name is assumed to be ".sframe". So the following (albeit counter intuitive) is expected at this time: $ readelf -S sort | grep sframe [NN] .sframe2 GNU_SFRAME 0000000000NNNNNN 0000NNNN (Note section name .sframe2). $ objdump --sframe sort sort: file format elf64-x86-64 No .sframe section present (Similarly for readelf as well). For objdump, set dump_sframe_section_name to ".sframe" if user specifies no section name. In the error checking done in dump_sframe_section, add the case when user specifies a valid section name but one that does not contain SFrame section data. For sections generated with Binutils >= 2.45, this can be checked with section type of SHT_GNU_SFRAME. Previously these sections were SHT_PROGBITS with name ".sframe". Similar changes in readelf. Add a test each for objdump and readelf to dump a renamed section. Use gas_sframe_check to limit the execution of these tests only when a gas supporting SFrame format is present. binutils/ PR binutils/33186 * objdump.c (dump_dwarf_section): Set match to ".sframe" which corresponds to the name in the debug_displays[] entry for SFrame section. (dump_sframe_section): Check if the user specified section name contains SFrame data. (main): Set default section name to ".sframe". * readelf.c (display_debug_section): Adjust checks to find the debug_diplays[] item for the input arg SFrame section. Use id instead of i, as it is more readable. binutils/testsuite/ PR binutils/33186 * binutils-all/x86-64/objdump-sframe-01.d: New test. * binutils-all/x86-64/readelf-sframe-01.d: New test. * binutils-all/x86-64/sframe-func.s: New test.
11 daysld: Force SHELL=/bin/bash in ld for Solaris [PR32580]Rainer Orth3-2/+34
As described in PR ld/32580, when using SHELL=/bin/sh or /bin/ksh on Solaris, the generated linker scripts get corrupted. So far, the only workaround is to enforce /bin/bash instead. This is a major nuisance for developers and users alike, so this patch automates this by overriding SHELL in ld/configure.ac. Tested on amd64-pc-solaris2.11 in three configurations: * CONFIG_SHELL unset * CONFIG_SHELL=/bin/ksh * CONFIG_SHELL='/bin/bash --norc' In the first two cases, SHELL was set to /bin/bash as desired, while in the third it was left unchanged. 2025-07-24 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> ld: PR ld/32580 * configure.ac <*-*-solaris2*>: Enforce SHELL=/bin/bash. * configure: Regenerate.
11 daysPR 33210 NULL pointer arithmetic in coffcode.hAlan Modra1-1/+3
Fix ubsan "runtime error: applying zero offset to null pointer".
11 daysAutomatic date update in version.inGDB Administrator1-1/+1
11 daysstrip: Properly handle LLVM IR bitcodeH.J. Lu6-21/+299
commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d Author: H.J. Lu <hjl.tools@gmail.com> Date: Sun May 4 05:12:46 2025 +0800 strip: Add GCC LTO IR support added "-R .gnu.lto_.*" to strip to remove all GCC LTO sections. When "-R .gnu.lto_.*" is used, the plugin target is ignored so that all LTO sections are stripped as the regular sections. It works for the slim GCC LTO IR since the GCC LTO IR is stored in the regular sections. When the plugin target is ignored, the GCC LTO IR can be recognized as the normal object files. But it doesn't work for the slim LLVM IR which is stored in a standalone file. 1. Add bfd_check_format_matches_lto and bfd_check_format_lto to take an argument, lto_sections_removed, to indicate if all LTO sections should be removed. 2. Update strip to always enable the plugin target so that the plugin target is enabled when checking for bfd_archive. 3. Update strip to ignore the plugin target for bfd_object when all LTO sections should be removed. If the object is unknown, copy it as an unknown file without any messages. 4. Treat the "-R .llvm.lto" strip option as removing all LTO sections. bfd/ PR binutils/33198 * format.c (bfd_check_format_lto): New function. (bfd_check_format): Call bfd_check_format_matches_lto. (bfd_check_format_matches): Renamed to ... (bfd_check_format_matches_lto): This. Add an argument, lto_sections_removed, to indicate if all LTO sections should be removed and don't match the plugin target if lto_sections_removed is true. (bfd_check_format_matches): Call bfd_check_format_matches_lto. * bfd-in2.h: Regenerated. binutils/ PR binutils/33198 * objcopy.c (copy_archive): Call bfd_check_format_lto, instead of bfd_check_format, and pass lto_sections_removed. Remove the non-fatal message on unknown element since it will be copied as an unknown file. (copy_file): Don't check lto_sections_removed when enabling LTO plugin in strip. (copy_file): Ignore the plugin target first if all LTO sections should be removed. Try with the plugin target next if ignoring the plugin target failed to match the format. (strip_main): Also set lto_sections_removed for -R .llvm.lto. * testsuite/binutils-all/x86-64/pr33198.c: New file. * testsuite/binutils-all/x86-64/x86-64.exp (run_pr33198_test): New. Run binutils/33198 tests. * testsuite/lib/binutils-common.exp (llvm_plug_opt): New. (CLANG_FOR_TARGET): New. Set to "clang" for native build if "clang -v" reports "clang version". Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
12 days[gdb/testsuite] Add Term::get_string_with_attrs in tuitermTom de Vries2-6/+19
While reading a gdb.log for test-case gdb.tui/main-2.exp, I noticed that this line was somewhat hard to read: ... screen line 6: '<fg:cyan><intensity:bold>|<fg:default><intensity:normal>B+> 21 <reverse:1> return 0;<reverse:0> <fg:cyan><intensity:bold>|<fg:default><intensity:normal>' ... because of the border attributes. Then I realized that the test-case is only interested in the text between the borders, so I added a proc Term::get_string_with_attrs that allows me to drop the borders, getting us instead: ... screen line 6: 'B+> 21 <reverse:1> return 0;<reverse:0> ' ... Tested on aarch64-linux.
12 days[gdb/testsuite] Use TERM=ansiw in tuiterm for bsdTom de Vries1-2/+10
TERM=ansi is different on freebsd and linux. Consequently, many TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) fail on freebsd. One of the problems is that send_gdb "<cmd>\r\n" is needed instead of send_gdb "<cmd>\n". This is because gdb_send "layout regs\n" translates to "layout regs<KEY_DOWN>", which evidently missing the carriage return part. While we can work around this, there are other problems. There is no color support, and the cursor keys fail to scroll the source window. So I went looking for an alternative to TERM=ansi on freebsd, and came across TERM=ansiw. Using this didn't work out of the box, but with the fixes in this series it now does. I also briefly looked at TERM=ansis, which is interesting because it's available on both linux and freebsd, but ansiw is a better choice for now. I've filed PR33179 to document what I learned, with the aim to eventually follow up and address two test-case failures with TERM=ansis on linux. Tested on x86_64-freebsd.
12 days[gdb/testsuite] Log on return in Term::_log_curTom de Vries1-1/+8
Proc Term::_log_cur logs the cursor update of code in its body argument: ... proc _ctl_0x08 {} { _log_cur "Backspace" { variable _cur_col if {$_cur_col > 0} { incr _cur_col -1 } } } ... giving us for instance: ... +++ Backspace, cursor: (2, 0) -> (2, 0) ... But if we rewrite the code to use a return: ... if { $_cur_col == 0 } { return } incr _cur_col -1 ... and the return is triggered, the log message disappears. Fix this by wrapping the "uplevel $body" in a catch: ... - uplevel $body + set code [catch {uplevel $body} result] ... Tested on aarch64-linux.
12 daysAutomatic date update in version.inGDB Administrator1-1/+1
12 daysgold: configury: fix obsolete macrosPietro Monteiro3-31/+4
Running `autoreconf -vf -Wall' in the gold directory shows errors about the use of obsolete macros. This patch fix the issues with macros used directly by configure.ac. However, it doesn't fix all warnings. There are autoconf warnings about macros from files in config and one automake warning about a target being shadowed. It cuts a lot of the noise down and makes an upgrade to autoconf 2.71+ easier. https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html#index-AC_005fOUTPUT-2133 gold/ChangeLog: * aclocal.m4: Regenerate. * configure: Regenerate. * configure.ac: Replace AM_CONFIG_HEADER by AC_CONFIG_HEADERS. Replace AC_OUTPUT(file list) by AC_CONFIG_FILES([file list])\nAC_OUTPUT. Approved-by: Alan Modra <amodra@gmail.com>
12 days[gdb/testsuite] Fix Term::_csi_m with no argsTom de Vries2-0/+14
When calling Term::_csi_m with no args, default behaviour needs to be applied, which is equivalent to "Term::_csi_m 0" [1]. However, while "Term::_csi_m 0" works, as well as 'Term::_csi_m ""', calling Term::_csi_m with no args has no effect. Fix this by implementing the default behaviour in Term::_csi_m. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://vt100.net/docs/vt510-rm/SGR.html
12 days[gdb/testsuite] Handle auto_left_margin in tuitermTom de Vries2-5/+40
The terminal capability bw (aka as auto_left_margin) controls whether a backspace at the start of a line wraps to the last column of the previous line. For tuiterm, we use TERM=ansi, and on linux at least that capability is off. Consequently the current implementation of Term::_ctl_0x08 doesn't wrap. Add this capability in Term::_ctl_0x08, and add a unit test. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
12 daysgdbserver: use reference in range for loopSimon Marchi1-1/+1
The armhf buildbot fails to build GDB, with: ../../binutils-gdb/gdbserver/server.cc: In function ‘void handle_general_set(char*)’: ../../binutils-gdb/gdbserver/server.cc:1021:23: error: loop variable ‘<structured bindings>’ creates a copy from type ‘const std::pair<thread_info*, enum_flags<gdb_thread_option> >’ [-Werror=range-loop-construct] 1021 | for (const auto [thread, options] : set_options) | ^~~~~~~~~~~~~~~~~ ../../binutils-gdb/gdbserver/server.cc:1021:23: note: use reference type to prevent copying 1021 | for (const auto [thread, options] : set_options) | ^~~~~~~~~~~~~~~~~ | & I did not use a reference on purpose, because the pair is very small. I don't see the problem when building on amd64, I presume it is because the pair is considered too big to copy on a 32-bit architecture, but not on a 64-bit architecture. In any case, fix it by adding a reference. Change-Id: I8e95235d6e53f032361950cf6e0c7d46b082f951
12 days[gdb/testsuite] Handle Horizontal Position Absolute in tuitermTom de Vries2-1/+17
I ran the tui testsuite on freebsd with TERM=ansiw, and investigated the first failure, in test-case gdb.tui/tui-init-source.exp. The problem turned out to be the lack of handling a Horizontal Position Absolute [1] sequence "^[[80`" in tuiterm. Add Term::_csi_`, forwarding to Term::_csi_G which handles Cursor Horizontal Absolute [2]. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://vt100.net/docs/vt510-rm/HPA.html [2] https://vt100.net/docs/vt510-rm/CHA.html
12 days[gdb/testsuite] Fix Cursor Horizontal Absolute clippingTom de Vries2-1/+17
I looked at the tuiterm implementation of Cursor Horizontal Absolute: ... proc _csi_G {args} { set arg [_default [lindex $args 0] 1] _log_cur "Cursor Horizontal Absolute ($arg)" { variable _cur_col variable _cols set _cur_col [expr {min ($arg - 1, $_cols)}] } } ... and noticed a problem with the clipping behavior. If we have say $_cols == 80, and we do _csi_G 81 we get $_cur_col == 80, while $_cur_col is zero-based and should be in the 0..79 range. Fix this by using: ... set _cur_col [expr {min ($arg, $_cols)} - 1] ... which gets us $_cur_col == 79. Add two boundary tests to gdb.tui/tuiterm.exp. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
12 daysgdb, gdbserver: use structured bindings in a few placesSimon Marchi6-53/+24
I wanted to change one of these, so I searched for more similar instances, while at it. I think this looks a bit tidier, over unpacking the pairs by hand. Change-Id: Ife4b678f7a6aed01803434197c564d2ab93532a7 Approved-By: Tom Tromey <tom@tromey.com>
12 daysPR 33197 [AVR] Incorrect syntax in generated ldscriptAlan Modra1-10/+12
Rearrange scripttempl/avr.sc to avoid oddities of shells expanding ${RELOCATING+stuff} in here documents where "stuff" contains quoted strings. Also I think it is better to avoid multi-line "stuff" as it can be tricky to spot the ending brace.
12 dayslibctf: don't run tests requiring deduplicating linker unless one is in useNick Alcock5-1/+67
Before now, we were relying on gcc -B to repoint GCC at our freshly-built linker, and assuming we could use this to run tests that do linker dedup. This is, alas, not reliable (building --with-ld=/an/absolute/path bypasses -B searches for the linker), and we would like the libctf tests in particular to not fail if the compiler uses a linker that cannot deduplicate (simply skipping such tests). Add a new testsuite function that tries to link one of the lookup tests' testcases (which is known to produce conflicting types, i.e. a dict with per-translation-unit children) and then does an objdump and greps it for signs of the per-translation-unit children. If there are none, the linker probably just concatenated the sections: i.e., it is not a linker that can deduplicate CTF. libctf/ PR libctf/33162 * testsuite/config/default.exp (objdump): Introduce. (OBJDUMPFLAGS): Likewise. * testsuite/lib/ctf-lib.exp (check_ctf_linker_dedup): New. * testsuite/libctf-lookup/lookup.exp: Use it. * testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise. * testsuite/libctf-regression/regression.exp: Likewise.
12 dayslibctf: exclude always-emitted Solaris symbols from the symtypetabRainer Orth1-0/+6
If we're skipping _BEGIN_ and _END_ we should certainly skip all the other ABI-required always-emitted symbols given in ld/emultempl/solaris2*em as well. (This fixes a couple of diagnostics tests, but that's just because the tests are quite sensitive to CTF section sizes, and introducing any symtypetab entries for those tests perturbs those.) Some of these are usually STT_NOTYPE, but not always: if programs already emitted the symbol they might end up with any type, in particular STT_OBJECT, and appear in the symtypetabs. [nca: added commit log, added more symbols] libctf/ PR libctf/33162 * ctf-serialize.c (ctf_symtab_skippable): Skip more always-emitted Solaris symbols.
12 dayslibctf: get libctf-nobfd.ver from the right place with Solaris ldNick Alcock2-2/+2
We generate de-commented version scripts for Solaris ld (whose -z gnu-version-script linker option does not support comments), but after we switched to generating libctf-nobfd.ver itself, we failed to adjust this code to pick it up from the new location. libctf/ PR libctf/33161 * configure.ac: Fix libctf-nobfd.ver path on Solaris. * configure: Regenerated.
12 dayslibctf: do not use mmap on Solaris 11Rainer Orth2-0/+16
Writable mmaps and read are inconsistent with each other on Solaris 11.4, which breaks archive writing. Simply assert that Solaris 2.11 doesn't have mmap, falling back to read(): the archive format is being bumped shortly, to one with completely different writeout code, so this workaround need not stay for long. [nca: added commit log] libctf/ PR libctf/29292 * configure.ac: Turn off mmap on Solaris 2.11. * configure: Regenerated.
13 daysgas: sframe: fix PR gas/33170Indu Bhagat4-4/+71
SFrame generation code assumes that since DW_CFA_restore means restoration of the state of the register to the one at the beginning of the function, there must be a state to restore to (hence the gas_assert (cie_fre)). This assumption needs adjustment. DW_CFA_restore may be present in the very beginning of a (e.g., cold) function, with no initialized state for SFrame functions to restore to. gas/ PR gas/33170 * gas/gen-sframe.c (sframe_xlate_do_restore): Use current FRE if CIE FRE is not yet setup. gas/testsuite/ PR gas/33170 * gas/cfi-sframe/cfi-sframe.exp: New test. * gas/cfi-sframe/cfi-sframe-x86_64-pr33170.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-pr33170.s: New test.
13 daysAutomatic date update in version.inGDB Administrator1-1/+1
13 days[gdb/testsuite] Modernize gdb.base/command-line-input.expTom de Vries1-10/+20
Modernize test-case gdb.base/command-line-input.exp using clean_restart, multi_line and string_to_regexp. Tested on x86_64-linux. Approved-By: Andrew Burgess <aburgess@redhat.com>
13 days[gdb/cli] Clear line buffer on ^CTom de Vries2-0/+31
Gdb has the ability to gather input over several lines [1], for instance this: ... (gdb) print 1 $1 = 1 (gdb) ... can also be typed as: ... (gdb) print\ 1 $2 = 1 (gdb) ... Furthermore, if we type a command but change our mind, we can abort using ^C and start over using a fresh gdb prompt [2]: ... (gdb) print 1❌️ Quit (gdb) echo 1\n 1 (gdb) ... Now say we type a multi-line command but abort it, we get: ... (gdb) print\ 1❌️ Quit (gdb) echo 1\n ❌️ Undefined command: "printecho". Try "help". (gdb) ... Using "set trace-commands on", we can see what happened: ... +printecho 1\n .. Gdb has prepended the first line of the cancelled multi-line command to the following command. Fix this by clearing current_ui->line_buffer on catching a gdb_exception in start_event_loop. Tested on x86_64-linux. Approved-By: Andrew Burgess <aburgess@redhat.com> PR cli/33063 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33063 [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Output.html [2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Quitting-GDB.html
13 daysgdb: Remove redundant parameter for filename completionGuinevere Larsen3-9/+8
As I was working on an unrelated patch, I noticed that all calls to make_source_files_completion_list had both parameters of the function call being the same pointer. I think we can remove that redundancy and make that call with just one parameter. Approved-By: Andrew Burgess <aburgess@redhat.com>
13 daysgdb/solib-svr4: fix indentSimon Marchi1-2/+2
Change-Id: I63f78f359f55ec15fb3296a1a9ce28c9d01d663b
13 daysgdb: use skip_spaces in info_linker_namespace_commandSimon Marchi1-3/+1
Change-Id: I02c7daed3740e319ee27d3512a2b941f666b103b Approved-By: Andrew Burgess <aburgess@redhat.com>
13 daysgdb: fix formatting in solib.cSimon Marchi1-2/+2
I found these two small nits while working in this file. Change-Id: Ibdaa57262f3fe363b039fbad746e285fa7b52f8b Approved-By: Andrew Burgess <aburgess@redhat.com>
13 daysUpdated translations for various sub-directoriesNick Clifton7-13025/+15433
13 daysRemove steps for adding .dirstamp when creating pre-release tarballNick Clifton1-11/+0
13 daysld: Rename a file on Windows fails if target already existsTorbjörn SVENSSON1-2/+16
To rename a file on Windows, the target name cannot exist. Removing file prior to renaming ensures this is handled. To remove a file on Windows, the file cannot be open. Closing the bfd handle ensures this is handled. Moved call to free on isympp / osympp to after bfd is closed to align with comment earlier in the cmdline_add_object_only_section function. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
13 daysFix failing test: i386-avx-reverseShiven Kashyap2-3/+3
Running the standalone test `gdb.reverse` with the target board configuration `unix/-fPIE/-pie` leads to the following failure: ''' FAIL: gdb.reverse/i386-avx-reverse.exp: verify ymm15 before vbroadcastsd ''' This happens because the test expects values stored in `dyn_buf0`, but instead (in the test source) the address of the buffer itself got broadcast to xmm15 (and thus to ymm15). This happened because the pointer to the start of `dyn_buf0` wasn't dereferenced (see 'vpbroadcast_test' in 'i386-avx-reverse.c'): ''' asm volatile ("vbroadcastss %0, %%xmm15": : "m" (dyn_buf0)); ^ ''' and this consequently lead to the test failing for the next instruction (`vbroadcastsd`), which depended on the correct value being broadcast to the register. Also, updated the corresponding expected output (gdb.reverse/i386-avx-reverse.exp) to match. Tested on x86-64 Linux. Signed-off-by: Shiven Kashyap <shivenkashyap24@gmail.com> Approved-By: Guinevere Larsen <guinevere@redhat.com>
14 daysRISC-V: Don't allocate dynamic relocation if it's section was discardedNelson Chu2-0/+47
14 daysRISC-V: Fix the assert fail when linking discarded sections under -pie for gotNelson Chu7-40/+109
Considering the following case, % cat tmp.s .option pic .text .global _start _start: nop .section .discard.s, "ax" la x1, _start % cat tmp.ld OUTPUT_ARCH(riscv) ENTRY(_start) SECTIONS { /DISCARD/ : { *(.discard.*) } . = 0x10000; .text : { *(.text) } . = 0x20000; .got : { *(.got) *(.got.plt)} . = 0x30000; .data : { *(.data) *(.data.*) } } % riscv64-unknown-linux-gnu-as tmp.s -o tmp.o % riscv64-unknown-linux-gnu-ld -pie -Ttmp.ld tmp.o riscv64-unknown-linux-gnu-ld: BFD (GNU Binutils) 2.44.50.20250624 assertion fail binutils-gdb/bfd/elfnn-riscv.c:3638 This happens when pie and the input sections, which refers to the global symbol by got, are all discarded. Since referenced sections are all discarded, we won't go into relocate_section for those sections, the got entry also won't be initialized. Therefore, we will get assert fail when adding the RELATIVE reloc in the finish_dynamic_symbol. After seeing other target codes, there are two root causes as follows, 1. risc-v may call bfd_elf_link_record_dynamic_symbol in the allocate_dynrelocs for not only undefweak symbols. 2. risc-v is missing the code to add RELATIVE to R_RISCV_GOT entries in the relocate_section if a symbol is not dynamic and is not undefined weak under pic and pie. If we call bfd_elf_link_record_dynamic_symbol, then the global symbol will be forced to dynamic, so the h->dynindx will forced to be a number rather than -1, even it should be -1. Once h->dynindx != -1 and pic/pie, it will go into finish_dynamic_symbol and insert RELATIVE/64 relocs for the got entry; For the above case there are two issues, 1. The global symbol _start is forced to be dynamic in the allocate_dynrelocs. when pie and all the referenced section are discarded, it won't go into relocate_section to initialize the got entry, so it will cause assert fail when adding RELATIVE reloc in the finish_dynamic_symbol. The assert fail represents another problem - if we don't initialize the got entry in the relocate_section under pie, which means we don't need to go into the finish_dynamic_symbol and don't need a RELATIVE reloc for the got entry, it should be NONE reloc. 2. Without linking any discarded section, it originally forces every RELATIVE relocs added for every got by the finish_dynamic_symbol. Even The final result looks correct under pie (genearte a RELATIVE reloc for got entry), not sure if it may cause other problems for some special cases, excpet the above one. Therefore, this patch try to fix the above assert fail, and also clarify the behavior of the allocate_dynrelocs which should only call bfd_elf_link_record_dynamic_symbol for undefweak symbols, and add the missing code to generate RELATIVE reloc to R_RISCV_GOT entries in the relocate_section if a symbol is not dynamic and is not undefined weak under pic and pie. Passed the gcc/binutils regressions of riscv-gnu-toolchain at least.