| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Tidy changes to bfd_check_format_matches made by commit 9b854f169df9
which added a bfd_plugin_specified_p test and commit f752be8f916e
which added an lto_sections_removed arg. Both of these changes are
unnecessary if plugin_format is set to bfd_plugin_no before calling
bfd_check_format. bfd_plugin_no will prevent the plugin object_p
function from returning a match (and in the first case from a segfault
when loading plugins while a plugin is running). The plugin object_p
function already protected itself from recursive calls by setting
bfd_plugin_no before loading a plugin, but commit 9b854f169df9 opened
new bfds so they were unprotected.
It isn't strictly necessary to test for bfd_plugin_no in
bfd_check_format_matches but I kept the check to minimise functional
changes. Close inspection of the patch will notice I've added an
is_linker_input test too. That also isn't strictly necessary, I
think, but the match_count test was for the linker. See commit
999d6dff80fa.
PR 12291
PR 12430
PR 13298
PR 33198
bfd/
* format.c (bfd_check_format_lto): Revert to bfd_check_format.
(bfd_check_format_matches_lto): Revert to bfd_check_format_matches.
Correct comments. Manage both the lto_sections_removed and
bfd_plugin_specified_p cases by testing for bfd_plugin_no.
* plugin.c (bfd_plugin_get_symbols_in_object_only): Set
plugin_format to bfd_plugin_no before checking new bfds.
(try_load_plugin): Comment setting bfd_plugin_no.
(bfd_plugin_specified_p): Delete.
* plugin.h (bfd_plugin_specified_p): Delete.
* bfd-in2.h: Regenerate.
binutils/
* objcopy.c (copy_archive): Replace bfd_check_format_lto calls
with bfd_check_format using plugin_format set to bfd_plugin_no.
(check_format_object): New function.
(copy_file): Use it.
|
|
While trying out gccrs, I noticed that gdb_simple_compile does not use
the ".rs" extension for Rust sources. This patch fixes the problem,
which lets gccrs get a little further in the test suite.
|
|
Most code doesn't use cleanups any more, so remove the include of
cleanups.h from common-defs.h, and then only include that file where
it is truly needed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The ANSI escape sequence translation layer in TUI mode strips italic
or underlined text modes silently. You cannot output text formatted
like that using `TuiWindow.write` in Python at the moment.
Parse the ANSI escape sequences for italic and underlined text into
the `ui_file_style` structure and apply it to the TUI window when
applying styles, similar to preserving the bold/dim state already.
A script like this shows italic and underlined text correctly now.
```python
import gdb
class TestTUIWindow:
_tui_window: gdb.TuiWindow
def __init__(self, tui_window: gdb.TuiWindow) -> None:
self._tui_window = tui_window
self._tui_window.title = "colors test"
def render(self) -> None:
self._tui_window.write("""
\x1b[4mThis is underlined.\x1b[24m And normal text.
\x1b[3mThis is italic.\x1b[23m And normal text.
""", True)
gdb.register_window_type("colortest", TestTUIWindow)
```
And launching it with
```
source the_above_script.py
tui new-layout test colortest 1 cmd 1
layout test
```
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
On x86_64-freebsd, with test-case gdb.base/style.exp I run into:
...
(gdb) print $_colorsupport
[36;49;22;27m$1[m = "monochrome"
(gdb) FAIL: $exp: colorsupport_8color: color support is 8 color
...
Fix this by applying the same fix as for tuiterm: use TERM=ansiw instead of
TERM=ansi for bsd, getting us instead:
...
(gdb) print $_colorsupport
[36;49;22;27m$1[m = "monochrome,ansi_8color"
(gdb) PASS: $exp: colorsupport_8color: color support is 8 color
...
Tested on x86_64-freebsd.
|
|
This patch gives gdbserver the ability to omit the 's' reply to
'vCont?'. This tells gdb that hardware single-step is definitely not
supported, causing it to fall back to using software single-step.
This is useful for testing the earlier change to
maybe_software_singlestep.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When the PikeOS osabi sniffer was added, Pedro suggested that a target
could omit stepping from its vCont? reply packet to tell gdb that
software single-step must be used:
https://sourceware.org/legacy-ml/gdb-patches/2018-09/msg00312.html
This patch implements this idea by moving the call to
target_can_do_single_step into maybe_software_singlestep.
I've also removed some FIXME comments from gdbarch_components.py, and
slightly updated the documentation for gdbarch_software_single_step.
I think these comments are somewhat obsolete now that
target_can_do_single_step exists -- the current approach isn't exactly
what the comments intended, but on the other hand, it exists and
works.
Following review comments from Andrew, this version changes
record-full to use maybe_software_singlestep, and then combines
maybe_software_singlestep with insert_single_step_breakpoint.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28440
|
|
|
|
Make the windres testing both parse .rc files to binary and back
again. It's not possible to compare against the original .rc file
unfortunately, but at least this checks for the segfault fixed by
commit 891d1654d731.
PR 33244
* testsuite/binutils-all/windres/psql.rc: New file.
* testsuite/binutils-all/windres/windres.exp: Do a -J res
-O rc conversion too. Correct verbose message.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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).
|
|
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.
|
|
There's no reason to allow the array to be modifiable, nor for it to be
globally visible.
|
|
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().
|
|
There's no reason to allow the array to be modifiable, nor for it to be
globally visible.
|
|
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.
|
|
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.
|
|
Update some entries in the gdb/MAINTAINERS file.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
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.
|
|
|
|
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>
|
|
As done just now on the GCC side in r16-2677-g7a79219383c83c,
import zlib-1.3.1.
|
|
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>
|
|
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.
|
|
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>
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
7c1c13e896c76879bcf3fb29332e0a59918bc9e0.
|
