aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
22 hoursAutomatic date update in version.inHEADmasterGDB Administrator1-1/+1
45 hoursRe: resbin: don't pass NULL as printf %s argAlan Modra1-4/+4
Commit c6c8d0b82175 went completely the wrong way. "key" needs to be NULL as that reads a different type of data. PR 33244 * resbin.c (get_version_header): Don't pass a NULL key on to toosmall. (bin_to_res_version): Restore NULL key cases.
46 hoursAutomatic date update in version.inGDB Administrator1-1/+1
2 daysgdb/MAINTAINERS: Update my email addressJan Vrany1-1/+1
2 daysgprof: Run tst-gmon-gprof-l.sh after tst-gmon-gprof.shH.J. Lu2-2/+6
Both tst-gmon-gprof.sh and tst-gmon-gprof-l.sh generate gmon.out and process it. Run tst-gmon-gprof-l.sh after tst-gmon-gprof.sh to avoid the race condition. * testsuite/Makefile.am (tst-gmon-gprof-l.out): Depend on tst-gmon-gprof.out. * testsuite/Makefile.in: Regenerated. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
3 daysgdbserver: switch to using getopt_long for argument processingAndrew Burgess1-153/+247
Update gdbserver to use getopt_long for argument processing. This turned out to be easier than I expected. Interesting parts of this patch are: I pass '+' as the OPTSTRING to getopt_long, this prevents getopt_long from reordering the contents of ARGV. This is needed so that things like this will work: gdbserver :54321 program --arg1 --arg2 Without the '+', getopt_long will reorder ARGV, moving '--arg1' and '--arg2' forward and handling them as arguments to gdbserver. Because of this (not reordering) and to maintain backward compatibility, we retain a special case to deal with '--attach' which can appear after the PORT, like this: gdbserver :54321 --attach PID I did consider adding a warning to this special case, informing the user that placing --attach after the PORT was deprecated, but in the end I didn't want to really change the behaviour as part of this commit, so I've left that as an optional change for the future. The getopt_long function supports two value passing forms, there is '--option=value', and also '--option value'. Traditionally, gdbserver only supports the first of these. To maintain this behaviour, after the call to getopt_long, I spot if '--option value' was used, and if so, modify the state so that it seems that no value was passed, and that 'value' is the next ARGV entry to be parsed. We could, possibly, remove this code in the future, but that would be a functional change, which is not something I want in this commit. Handling of "-" for stdio connection has now moved out of the argument processing loop as '-' isn't considered a valid option by getopt_long, this is an improvement as all PORT handling is now in one place. I've tried as much as possible to leave user visible functionality unchanged after this commit, and as far as I can tell from testing, nothing has changed. Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdbserver: exit with code 1 after missing packet nameAndrew Burgess1-1/+1
When using the command: $ gdbserver --disable-packet gdbserver lists all the packets that can be disabled, and then exits. I think that this output is a helpful error message that is printed when the user has forgotten to entry a packet name. We get similar output if we run the command: $ gdbserver --disable-packet=foo where gdbserver tells us that 'foo' is invalid, and then lists the packets that we can use. The difference is that, in the first case, gdbserver exits with a code of 0, and in the second, gdbserver exits with a code of 1. I think both these cases should exit with a code of 1. With the exception of '--help' and '--version', where we are asking gdbserver to print some message then exit (which are, and should exit with a code of 0), in all other cases where we do an early exit, I think this is an indication that the user has done something wrong (entered and invalid argument, or missed an argument value), and gdbserver should exit with a non-zero exit code to indicate this. This commit updates the exit code in the above case from 0 to 1. Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdbserver: convert locals to `bool` in captured_mainAndrew Burgess1-11/+10
Within gdbserver/server.cc, in captured_main, convert some locals to bool. Move the declaration of some locals into the body of the function. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
3 daysopcodes/x86: make i386_mnem[] staticJan Beulich3-4/+4
With the tables no longer being part of libopcodes (but rather being compiled directly into gas), this table doesn't need exposing anymore. The declaration cannot be avoided, though, as the first use of the array sits ahead of its definition (in i386-tbl.h).
3 daysopcodes/riscv: make riscv_options[] constJan Beulich1-1/+1
There's no reason to allow the array to be modifiable. In fact the compiler is able to infer this, placing the array in .data.rel.ro, but let's make it explicit.
3 daysopcodes/ppc: make ppc_opts[] static constJan Beulich1-1/+1
There's no reason to allow the array to be modifiable, nor for it to be globally visible.
3 daysopcodes/aarch64: convert print_sme_za_list()'s zan[] / zan_v[]Jan Beulich1-17/+30
Merge them into a single array of struct type. There's further no reason to have the compiler materialize such objects on the stack. And there's also no reason to allow the array(s) to be modifiable. Finally, given how short the strings are, there's little point using more space to store pointers to them (on 64-bit hosts; the situation is a little better on 32-bit ones). While there also correct indentation in adjacent code, and avoid open- coding ARRAY_SIZE().
3 daysopcodes/aarch64: make aarch64_opnd_qualifiers[] static constJan Beulich1-1/+1
There's no reason to allow the array to be modifiable, nor for it to be globally visible.
3 daysopcodes/aarch64: make aarch64_ext_ldst_reglist()'s data[] static constJan Beulich1-1/+1
There's no reason to have the compiler materialize such an object onto the stack. And there's also no reason to allow the array to be modifiable.
3 daysgas: check section size against entry sizeJan Beulich1-0/+4
If a section has a non-zero entry size, its total size would generally better be a multiple of the entry size. Warn if that's not the case.
3 daysUpdate my e-mailLuis Machado1-3/+3
Update some entries in the gdb/MAINTAINERS file.
3 daysgdb/dwarf: sort dwarf2_per_bfd::all_units by (section, offset)Simon Marchi10-299/+414
This patch started as a fix for PR 29518 ("GDB doesn't handle DW_FORM_ref_addr DIE references correctly with .debug_types sections") [1], but the scope has expanded a bit to fix the problem more generally, after I spotted a few issues related to the order of all_units. The first version of this patch is here [2]. PR 29518 shows that dwarf2_find_containing_comp_unit can erroneously find a type unit. The obvious problem is that the dwarf2_find_containing_comp_unit function searches the whole all_units vector (containing both comp and type units), when really it should just search the compilation units. A simple solution would be to make it search the all_comp_units view (which is removed in a patch earlier in this series). I then realized that in DWARF 5, since type units are in .debug_info (versus .debug_types in DWARF 4), type units can be interleaved with comp type in the all_units vector. That would make the all_comp_units and all_type_units views erroneous, and dwarf2_find_containing_comp_unit could still return something wrong. In v1, I added a sort in finalize_all_units to make sure all_units is in the order that dwarf2_find_containing_comp_unit expects: - comp units from the main file - type units from the main file - comp units from the dwz file - type units from the dwz file (not actually supported, see PR 30838) Another problem I spotted is that the .gdb_index reader creates units in this order: - comp units from .gdb_index from main file - comp units from .gdb_index from dwz file - type units from .gdb_index from main file This isn't the same order as above, so it would need the same sort step. Finally, I'm not exactly sure if and when it happens, but it looks like lookup_signatured_type can be called at a later time (after the initial scan and creation of dwarf2_per_cu object creation), when expanding a symtab. And that could lead to the creation of a new type unit (see function add_type_unit), which would place the new type unit at the end of the all_units vector, possibly screwing up the previous order. To handle all this in a nice and generic way, Tom Tromey proposed to change the all_units order, so that units are sorted by section, then section offset. This is what this patch implements. The sorting is done in finalize_all_units. This works well, because when looking up a unit by section offset, the caller knows which section the unit is in. Passing down a (section, section offset) tuple makes it clear and unambiguous what unit the caller is referring to. It should help eliminate some bugs where the callee used the section offset in the wrong section. Passing down the section along with the section offset replaces the "is_dwz" flag passed to dwarf2_find_containing_comp_unit and a bunch of other functions in a more general way. dwarf2_find_containing_comp_unit can now legitimately find and return type units even though it should be needed (type units are typically referred to by signature). But I don't think there is harm for this function to be more generic than needed. I therefore I renamed it to dwarf2_find_containing_unit. The sort criterion for "section" can be anything, as long as we use the same for sorting and searching. In this patch, I use the pointer to dwarf2_section_info, because it's easy. The downside is that the actual order depends on what the memory allocator decided to return, so could change from run to run, or machine to machine. Later, I might change it so that sections are ordered based on their properties, making the order stable across the board. This logic is encapsulated in the all_units_less_than function, so it's easy to change. The .debug_names reader can no longer rely on the order of the all_units vector for its checks, since all_units won't be the same order as found in the .debug_names lists. In fact, even before, it wasn't: this check assumed that .debug_info had all CUs before TUs, and that the index listed them in the exact same order. When I build a file with gcc and "-gdwarf-5 -fdebug-types-section", type units appear first in .debug_info. This caused GDB to reject a .debug_names index that is had produced: $ GDB="./gdb -nx -q --data-directory=data-directory" /home/smarchi/src/binutils-gdb/gdb/contrib/gdb-add-index.sh -dwarf-5 hello.so $ ./gdb -nx -q --data-directory=data-directory hello.so Reading symbols from hello.so... ⚠️ warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names. To make it work, add a new dwarf2_find_unit function that allows looking up a unit by start address (unlike dwarf2_find_containing_unit, which can find by any containing address), and make the .debug_names reader use it. It might make the load time of .debug_names a bit longer (the build and check step is now going to be O(n*log(n)) instead of O(n) where n is the number of units, or something like that), but I think it's important to be correct here. This patch adds a test (gdb.dwarf2/dw-form-ref-addr-with-type-units.exp), which tries to replicate the problem as shown by PR 29518. gdb.base/varval.exp needs a small change, because an error message changes (for the better, I think) gdb.dwarf2/debug-names-non-ascending-cu.exp now fails, because GDB no longer rejects a .debug_names index which lists CUs in a different order than .debug_info. Given the change I did to the .debug_names reader, explained above, I don't think this is a problem anymore (GDB can accept an index like that). I also don't think that DWARF 5 mandates that CUs are in ascending order. Delete this test. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29518 [2] https://inbox.sourceware.org/gdb-patches/20250218193443.118139-1-simon.marchi@efficios.com/ Change-Id: I45f982d824d3842ac1eb73f8cce721a0a24b5faa Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdb/dwarf: sort units when writing indexSimon Marchi1-50/+92
The order of all_units can't be relied on when writing the CU and TU lists to .gdb_index or .debug_names. Both the .gdb_index and .debug_names writers expect that all_units contains comp units followed by type units. As of this commit, when reading a DWARF 5 .debug_info, the all_units vector is ordered based on the order the units appear in .debug_info, where type units can be interleaved with comp units. It probably worked fine with DWARF 4, where type units were in a section of their own (.debug_types). They were read after comp units, and therefore after them in the all_units vector. Change the writers to use a common function that splits the units in two lists (comp units and type units). Sort both lists by section offset. This is more than required, but it should help produce a stable and predictable output. Change-Id: I5a22e2e354145e3d6b5b2822dc2a3af2f9d6bb76 Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdb/dwarf: make .gdb_index reader use its own list of unitsSimon Marchi1-15/+23
The .gdb_index reader currently uses per_bfd::all_units when translating a numerical index (as found in an index entry) to a dwarf2_per_cu. The order of per_bfd::all_units is going to change in a subsequent patch, so the indices as found in the index won't map to the right unit in all_units. Change the .gdb_index reader to maintain its own vector, with the units in the same order as found in the .gdb_index header. This is similar to what the .debug_names reader does. But unlike .debug_names, .gdb_index treats the CUs and TUs as a single list, as far as the numerical indices are concerned, so we only need a single list here (versus two for .debug_names). Change-Id: I235e9b99bf02fc160dfcdaa610c9aca471f298a7 Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdb/dwarf: move index unit vectors to .debug_names reader and use themSimon Marchi2-57/+60
The all_comp_units_index_cus and all_comp_units_index_tus vectors contain the CU and TU lists as found in the .debug_names list. It seems like they are meant to be used by the .debug_names reader when handling a DW_IDX_compile_unit or DW_IDX_type_unit attribute. The value of the attribute would translate directly into an index into one of these vectors. However, it looks like these vectors aren't actually used in practice. They are used in the dwarf2_per_bfd::get_index_{c,t}u methods, which in turn aren't used anywhere. The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the dwarf2_per_bfd::get_unit method, with the assumption that dwarf2_per_bfd::all_units has comp units before type units. This is not the case: the .debug_names reader creates the units in dwarf2_per_bfd::all_units using the create_all_units function, which creates the units in the order found in .debug_info, where type units can be interleaved with comp units. Since those vectors are specific to the .debug_names reader, move them to the mapped_debug_names_reader struct. Then, update the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to actually use them. Change-Id: Ie7db81f4442f634ac6d02280a60c6c671bcd22a5 Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdb/dwarf: remove all_{comp,type}_units viewsSimon Marchi4-18/+9
In DWARF 5, type units appear in the .debug_info section, interleaved with comp units, and the order in all_units reflects that. The all_comp_units and all_type_units views are wrong in that case (all_comp_units contains some type units, and vice-versa). It would be possible to manually sort all_units to ensure that type units follow comp units, but this series takes the approach of sorting the units by section and section offset. Remove those views, and replace their uses with num_comp_units and num_type_units. It appears that the views were only used to know the number of each kind. The finalize_all_units function is now empty, but I am keeping it because a subsequent patch adds a call to std::sort in there to sort the all_units vector. Change-Id: I42a65b6f1b6192957b55cea0e2eaff097e13a33b Approved-By: Tom Tromey <tom@tromey.com>
3 daysgdb/dwarf: track compilation and type unit countSimon Marchi2-8/+12
A subsequent commit will remove the all_comp_units and all_type_units array views, since it's not possible to assume that that all_units vector is segmented between comp and type units. Some callers still need to know the number of each kind, so track that separately. Change-Id: I712fbdfbf10b333c431b688b881cc0987e74f688 Approved-By: Tom Tromey <tom@tromey.com>
3 daysia64 assembler warning breaks ld testsAlan Modra3-3/+6
The "Warning: Explicit stops are ignored in auto mode" results in failures of a number of run_ld_link_tests because the compiler is run using -S and then the resulting .s file assembled without suppplying -x to gas. Fix that problem by adding -x to ASFLAGS for ia64, and tweak the binutils link-order test since the source is used in a ld test too. ld/ * testsuite/config/default.exp: Set ASFLAGS to "-x" for ia64. Remove unnecessary "global". binutils/ * testsuite/binutils-all/link-order.s: Provide explicit stop. * testsuite/binutils-all/objcopy.exp: Pass "-x" when building link-order test for ia64.
3 daysld-elf/shared libpr23161c and pr23161c testsAlan Modra3-24/+7
If I understand these tests correctly it is to ensure that _end, _edata and __bss_start are not made dynamic. The dynamic reloc tests are not really necessary. (We dropped them from pr23161a and pr23161b tests a while ago without removing the -r from readelf invocation.) Dropping the reloc tests allows them to run for more targets. * testsuite/ld-elf/pr23161c.rd: Rewrite. * testsuite/ld-elf/pr23161d.rd: Delete. * testsuite/ld-elf/shared.exp (pr23161a, pr23161b): Remove -r from readelf check. (libpr23161c.so, pr23161c): Likewise, and check expected readelf output using the new pr23161c.rd.
3 daysAutomatic date update in version.inGDB Administrator1-1/+1
3 daysDon't nest double quotes in tuiterm.expTom Tromey1-1/+1
I found a line in tuiterm.exp that causes Emacs paren-matching to go awry. This patch fixes the problem by changing some apparent nested double quotes (which I think isn't really possible in Tcl but this seems to be the intent) to be more correct; which fixes the Emacs issue as well. Approved-By: Tom de Vries <tdevries@suse.de>
3 dayszlib: import zlib-1.3.1 [PR32933]Sam James145-4426/+7065
As done just now on the GCC side in r16-2677-g7a79219383c83c, import zlib-1.3.1.
3 daysstrip: Treat "default" output_target as unspecifiedH.J. Lu2-22/+60
Treat output target as unspecified if it is set to "default". binutils/ PR binutils/33230 * objcopy.c (copy_file): Treat "default" output_target as unspecified. binutils/testsuite/ PR binutils/33230 * binutils-all/x86-64/x86-64.exp (run_pr33230_test): New. Run binutils/33230 tests with readelf if supported. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
4 days[gdb/testsuite] Fix gdb.gdb/python-helper.exp with gdb built with -fltoTom de Vries1-1/+19
With a gdb build with gcc 7.5.0 and "-O2 -flto=auto -g", I run into: ... (outer-gdb) PASS: gdb.gdb/python-helper.exp: print varobj_table print inferior_list $5 = {m_front = 0x212e830, m_back = 0x2e39aa0} (outer-gdb) FAIL: gdb.gdb/python-helper.exp: print inferior_list ... The problem is that the type of inferior_list: ... (outer-gdb) what inferior_list^M type = intrusive_list^M (outer-gdb) ... is not descriptive enough to trigger the pretty pretter. Note that with a gdb build with -O0, we'd get instead: ... (outer-gdb) what inferior_list^M type = intrusive_list<inferior, intrusive_base_node<inferior> > (outer-gdb) ... Fix this by detecting this situation, and declaring the test unsupported. Tested on x86_64-linux.
4 daysstrip: Don't check target_defaulted in input BFDH.J. Lu3-6/+44
The target_defaulted field in BFD is set to true if the target isn't specified. After 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 the target is set to "plugin" if BFD supports plugin when the target isn't specified nor default. Update strip to check the input target, instead of the target_defaulted field in input BFD. PR binutils/33230 * objcopy.c (copy_object): Add a bool argument, target_defaulted, to indicate if the input target isn't specified nor default. Check it instead of ibfd->target_defaulted. (copy_archive): Add a bool argument, target_defaulted, and pass it to copy_object. (copy_file): Set target_defaulted to true if the input target isn't specified and pass it to copy_archive and copy_object. * testsuite/binutils-all/x86-64/pr33230.obj.bz2: New file. * testsuite/binutils-all/x86-64/x86-64.exp: Run PR binutils/33230 tests. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
4 daysAutomatic date update in version.inGDB Administrator1-1/+1
5 daysPR 33229 nds32 gas segfaults on gcc outputAlan Modra4-19/+25
Commit 1ac26e9f7ac2 replaced ISSPACE with is_whitespace, but the former returns true on EOL while the latter does not. Sprinkle is_end_of_stmt tests to fix this bug. The same segfault can be triggered by a ".relax_hint" with no following instructions. Fix that too. * config/tc-nds32.c (nds32_lookup_pseudo_opcode): Use is_end_of_stmt along with is_whitespace. (nds32_relax_relocs, nds32_relax_hint, nds32_flag), (ict_model: Likewise. (nds32_elf_append_relax_relocs): Return on no opcode. * testsuite/gas/nds32/nds32.exp: Find .d files automatically. * testsuite/gas/nds32/pr33229.d, * testsuite/gas/nds32/pr33229.s: New test.
5 daysAutomatic date update in version.inGDB Administrator1-1/+1
5 daysppc _bfd_clear_contentsAlan Modra1-29/+15
ppc32 isn't susceptible to the PR33223 segfault, but could hit a _bfd_clear_contents segfault with a carefully crafted invalid object. * elf32-ppc.c (ARRAY_SIZE): Define. (ppc_elf_howto_init): Use ARRAY_SIZE. (ppc_elf_reloc_name_lookup): Likewise. (ppc_elf_info_to_howto): Likewise, and consolidate error handling. (ppc_elf_check_relocs): Guard against segfaults caused by a NULL howto passed to _bfd_clear_contents. Use ARRAY_SIZE.
5 daysPR 33223 ppc64: segfault on unknown relocationAlan Modra2-20/+22
Bounds check accesses to ppc64_elf_howto_table and don't dereference a NULL howto. I think this catches all cases where that might happen. PR 33223 bfd/ * elf64-ppc.c (ppc64_elf_info_to_howto): Consolidate error handling. (ppc64_elf_check_relocs): Tidy error messages. (ppc64_elf_relocate_section): Don't segfault when attempting to report an unsupported relocation. Don't pass a NULL howto to _bfd_clear_contents. ld/ * testsuite/ld-powerpc/elfv2-2so.d: Adjust to suit error message change.
6 daysld: testsuite: Enable ld-elfweak tests on Solaris/x86Rainer Orth2-2/+7
The ld-elfweak tests are currently only enabled on Solaris/SPARC for no apparent reason. Enabling them on Solaris in general lets them all PASS on both amd64-pc-solaris2.11 and i386-pc-solaris2.11. 2025-07-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> ld: * testsuite/ld-elfweak/elfweak.exp: Enable on *-*-solaris2* rather than sparc*-*-solaris2* only.
6 daysAutomatic date update in version.inGDB Administrator1-1/+1
6 daysld: testsuite: Fix "PR ld/28138 (build only)" on SolarisRainer Orth2-1/+6
The FAIL: PR ld/28138 (build only) test FAILs on Solaris: ld/tmpdir/ld/collect-ld: plugin framework: out of file descriptors. Try using fewer objects/archives ld/tmpdir/ld/collect-ld: cannot find -lgcc: Too many open files [...] I found that the test PASSes when using ulimit -n 21 instead of the current 20. Looking with strace/truss, on Linux/i686 the following files are opened: 301543 openat(AT_FDCWD, "tmpdir/pr28138", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 301543 openat(AT_FDCWD, "/lib/../lib32/crt1.o", O_RDONLY|O_LARGEFILE) = 4 301543 openat(AT_FDCWD, "/lib/../lib32/crt1.o", O_RDONLY|O_LARGEFILE) = 5 301543 openat(AT_FDCWD, "/lib/../lib32/crti.o", O_RDONLY|O_LARGEFILE) = 5 301543 openat(AT_FDCWD, "/lib/../lib32/crti.o", O_RDONLY|O_LARGEFILE) = 6 301543 openat(AT_FDCWD, "lib/gcc/i686-pc-linux-gnu/12.1.0/crtbegin.o", O_RDONLY|O_LARGEFILE) = 6 301543 openat(AT_FDCWD, "lib/gcc/i686-pc-linux-gnu/12.1.0/crtbegin.o", O_RDONLY|O_LARGEFILE) = 7 301543 openat(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY|O_LARGEFILE) = 7 301543 openat(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY|O_LARGEFILE) = 8 301543 openat(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY|O_LARGEFILE) = 8 301543 openat(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY|O_LARGEFILE) = 9 301543 openat(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY|O_LARGEFILE) = 9 301543 openat(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY|O_LARGEFILE) = 10 301543 openat(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY|O_LARGEFILE) = 10 301543 openat(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY|O_LARGEFILE) = 11 301543 openat(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY|O_LARGEFILE) = 11 301543 openat(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY|O_LARGEFILE) = 12 301543 openat(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY|O_LARGEFILE) = 12 301543 openat(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY|O_LARGEFILE) = 13 301543 openat(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY|O_LARGEFILE) = 13 301543 openat(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY|O_LARGEFILE) = 3 301543 openat(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY|O_LARGEFILE) = 3 301543 openat(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY|O_LARGEFILE) = 4 301543 openat(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY|O_LARGEFILE) = 4 301543 openat(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY|O_LARGEFILE) = 5 while on Solaris/i386 there are a couple more: 27726: openat64(AT_FDCWD, "tmpdir/pr28138", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4 27726: openat64(AT_FDCWD, "/usr/lib/crt1.o", O_RDONLY) = 5 27726: openat64(AT_FDCWD, "/usr/lib/crt1.o", O_RDONLY) = 6 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtp.o", O_RDONLY) = 6 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtp.o", O_RDONLY) = 7 27726: openat64(AT_FDCWD, "/usr/lib/crti.o", O_RDONLY) = 7 27726: openat64(AT_FDCWD, "/usr/lib/crti.o", O_RDONLY) = 8 27726: openat64(AT_FDCWD, "/usr/lib/values-Xa.o", O_RDONLY) = 8 27726: openat64(AT_FDCWD, "/usr/lib/values-Xa.o", O_RDONLY) = 9 27726: openat64(AT_FDCWD, "/usr/lib/values-xpg6.o", O_RDONLY) = 9 27726: openat64(AT_FDCWD, "/usr/lib/values-xpg6.o", O_RDONLY) = 10 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtbegin.o", O_RDONLY) = 10 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtbegin.o", O_RDONLY) = 11 27726: openat64(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY) = 11 27726: openat64(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY) = 12 27726: openat64(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY) = 12 27726: openat64(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY) = 13 27726: openat64(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY) = 13 27726: openat64(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY) = 14 27726: openat64(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY) = 14 27726: openat64(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY) = 15 27726: openat64(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY) = 15 27726: openat64(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY) = 16 27726: openat64(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY) = 16 27726: openat64(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY) = 17 27726: openat64(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY) = 17 27726: openat64(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY) = 18 27726: openat64(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY) = 18 27726: openat64(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY) = 19 27726: openat64(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY) = 19 27726: openat64(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY) Err#24 EMFILE While it seems weird that the same files are opened twice for reading, it's no wonder that 20 fds aren't enough on Solaris. To avoid this, I've raised the limit to 25, hoping that this will be enough on more targets. Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. 2025-07-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> ld: * testsuite/ld-plugin/lto.exp (PR ld/28138 test): Raise fd limit to 25.
6 daysAdd forgotten ChangeLog entry for commit ↵Rainer Orth1-0/+5
7c1c13e896c76879bcf3fb29332e0a59918bc9e0.
6 daysld: testsuite: Skip "Run with libpr19553c.so" test on SolarisRainer Orth1-4/+11
The FAIL: Run with libpr19553c.so test FAILs on Solaris (32 and 64-bit, sparc and x86): Running: tmpdir/pr19553c > tmpdir/pr19553c.out diff tmpdir/pr19553c.out /vol/src/gnu/binutils/hg/master/local/ld/testsuite/ld-elf/pr19553c.out 1c1 < pr19553b --- > pr19553c child process exited abnormally The test uses .symver, resulting in versioned symbols which the Solaris ld.so.1 doesn't support and never will. Running it with LD_DEBUG=all shows 26493: 1: symbol=foo; lookup in file=tmpdir/pr19553c [ ELF ] 26493: 1: symbol=foo; lookup in file=tmpdir/libpr19553c.so [ ELF ] 26493: 1: symbol=foo; skipping entry in file=tmpdir/libpr19553c.so, index[7], version=FOO, due to GNU version hidden bit 26493: 1: symbol=foo; continuing lookup in file=tmpdir/libpr19553c.so [ ELF ] 26493: 1: symbol=foo; lookup in file=tmpdir/libpr19553b.so [ ELF ] 26493: 1: binding file=tmpdir/pr19553c to file=tmpdir/libpr19553b.so: symbol 'foo' so this patch skips the test. 2025-07-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> ld: * testsuite/ld-elf/indirect.exp (Run with libpr19553c.so): Skip on *-*-solaris2*.
6 daysAvoid timeouts with gnat-llvm in gdb.ada/operator_call.expTom Tromey1-0/+6
While working on gnat-llvm, gdb.ada/operator_call.exp has many timeouts. This happens because gnat-llvm's DWARF output is still incomplete, and so gdb emits an unexpected error in this test. This patch improves the test by having it recognize this output and issue a failure rather than a timeout. This greatly speeds up testing.
6 dayslibctf: link: rejig lazy opening to not need weak symbolsNick Alcock1-61/+27
The ctf_link_add_ctf API function has a 'lazy opening' feature whereby, if you pass in the file but not a CTF archive, the archive is opened as late as possible during links. This is valuable mostly in cu-mapped links (a feature not accessible via GNU ld), where it ensures that, rather than eventually needing memory for the original link inputs, the smushed-together cu-mapped intermediate outputs, *and* the final output, we only need enough memory for the smushed- together outputs, the final output, and one input, since the inputs can be closed immediately after they are smushed together. (In GNU ld, the feature is useless because it loads all sections into memory anyway.) The lazy-opening feature uses libctf's ctf_open function, which uses BFD: so it is not available in libctf-nobfd -- except that I thought I had a cunning trick, and used a weak symbol so that if you linked libctf-nobfd into your program and then also linked in bfd, the feature stayed enabled. This is silly -- if your program is licensed such that you can link in BFD, you can just link in libctf.so and not bother with libctf-nobfd.so in the first place. Worse, the weak symbol usage broke MacOS builds, since MacOS's system compiler uses a different means of introducing weak symbols. We could test for and use it, but this is the only place in libctf to use weak symbols at all, and the feature of lazy-opening with libctf-nobfd is so marginal we might as well drop it: it's almost certain there are zero users, certainly fewer users than users of MacOS with the system compiler. While we're at it, simplify things by deleting the never-implemented feature (not exposed in the API) to allow linking together raw buffers of CTF data. If we need it we can bring it back, but all it's doing right now is complicating the code to no end at all. libctf/ PR libctf/33194 * ctf-link.c (ctf_open): Delete weak pragma. (ctf_link_add): Fuse with... (ctf_link_add_ctf): ... this function. Drop BUF, N args and corresponding unimplemented feature warnings. Only check NOBFD to see whether lazy loading is available, not PIC as well. (ctf_link_lazy_open): Likewise.
6 daysgas: add missing header guard in tc-<arch>.h filesMatthieu Longo8-3/+19
This patch adds missing header guards in some of the tc-<arch>.h, and merely comments on the corresponding #endif for others. The patch does not aim at being exhaustive, it only touched the files relevant for [1]. [1]: https://inbox.sourceware.org/binutils/20250711112913.2453285-1-matthieu.longo@arm.com/
7 daysAutomatic date update in version.inGDB Administrator1-1/+1
8 daysUpdate release documentation following 2.45 releaseNick Clifton1-25/+29
8 daysAutomatic date update in version.inGDB Administrator1-1/+1
9 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.
9 daysAutomatic date update in version.inGDB Administrator1-1/+1
9 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.
9 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
generated by cgit v1.1 at 2025-08-03 22:02:15 +0000