aarch64: Support 2024 Debug Architecture system registers.
This patch adds support for following system registers and the spec
can be found here[1].
1. PMBSR_EL12, PMBSR_EL2, PMBSR_EL3, PMBMAR_EL1 depends on FEAT_SPE
and Armv9.5-A architecture and these are enabled by passing
-march=armv9.5-a+profile.
2. TRBSR_EL12, TRBSR_EL2, and TRBSR_EL3 depends Armv9.5-A architecture
and these are enabled by passing -march=armv9.5-a.
3. HFGITR2_EL2 depends on Armv8.8-A architecture and enabled by passing
-march=armv8.8-a.
Kirill Radkin [Tue, 3 Jun 2025 13:48:23 +0000 (16:48 +0300)]
gdbserver: Update require_int function to parse offset for pread packet
Currently gdbserver uses the require_int() function to parse the
requested offset (in vFile::pread packet and the like). This function
allows integers up to 0x7fffffff (to fit in 32-bit int), however the
offset (for the pread system call) has an off_t type which can be
larger than 32-bit.
This patch allows require_int() function to parse offset up to the
maximum value implied by the off_t type.
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: I3691bcc1ab1838c0db7f8b82d297d276a5419c8c
Ezra Sitorus [Thu, 5 Jun 2025 14:27:15 +0000 (15:27 +0100)]
aarch64: Add occmo flag for FEAT_OCCMO
FEAT_OCCMO support was introduced, but the feature flags were missing.
This patch adds these flags, as well as splitting up the tests to test
occmo vs occmo+memtag operands.
Ezra Sitorus [Thu, 19 Jun 2025 09:40:43 +0000 (10:40 +0100)]
aarch64: Support for FEAT_SVE_BFSCALE
FEAT_SVE_BFSCALE introduces the SVE BFSCALE instruction, when the PE is not in
Streaming SVE mode. If FEAT_SME2 is implemented, FEAT_SVE_BFSCALE also
introduces SME multi-vector Z-targeting BFloat16 scaling instructions, BFSCALE
and BFMUL.
Andrew Burgess [Thu, 12 Jun 2025 13:29:16 +0000 (14:29 +0100)]
gdb/python: introduce gdb.warning() function
This commit adds a new gdb.warning() function. This function takes a
string and then calls GDB's internal warning() function. This will
display the string as a warning.
Using gdb.warning() means that the message will get the new emoji
prefix if the user has that feature turned on. Also, the message will
be sent to gdb.STDERR without the user having to remember to print to
the correct stream.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
WANG Xuerui [Tue, 17 Jun 2025 08:12:02 +0000 (16:12 +0800)]
LoongArch: Batch-delete bytes at the end of each relax trip
Previously, memmove and reloc/symbol adjustments happened at each
loongarch_relax_delete_bytes() call, which is O(n^2) time complexity and
leads to unacceptable (multiple hours) linking times for certain inputs
with huge number of relaxable sites -- see the linked issue for details.
To get rid of the quadratic behavior, defer all delete ops to the end of
each relax trip, with the buffer implemented with the splay tree from
libiberty. The individual relaxation handlers are converted to handle
symbol values and relocation offsets as if all preceding deletions
actually happened, by querying a cumulative offset from the splay tree;
the accesses should be efficient because they are mostly sequential
during a relaxation trip. The exact relaxation behavior remains largely
unchanged.
Example running times before and after the change with the test case in
the linked issue (mypy transpiled C), cross-linking on Threadripper
3990X:
Before: 4192.80s user 1.09s system 98% cpu 1:10:53.52 total
After: 1.76s user 0.74s system 98% cpu 2.539 total - ~1/2382 the time!
Also tested with binutils (bootstrapping self), CPython 3.14 and LLVM
20.1.6; all passed the respective test suites.
Fabian Kilger [Wed, 11 Jun 2025 20:52:17 +0000 (22:52 +0200)]
gdb: query inferior's filesystem for build-id debug files
This fixes a bug related to build-id files with linux namespaces.
Specifically, we expect the debug files to be present inside the container,
thus the container filesystem should be queried if the program is running
inside one.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32956 Approved-By: Andrew Burgess <aburgess@redhat.com>
Fabian Kilger [Wed, 11 Jun 2025 20:52:16 +0000 (22:52 +0200)]
gdb: implement linux namespace support for fileio_lstat and vFile::lstat
The new algorithm to look for a build-id-based debug file
(introduced by commit 22836ca88591ac7efacf06d5b6db191763fd8aba)
makes use of fileio_lstat. As lstat was not supported by
linux-namespace.c, all lstat calls would be performed on the host
and not inside the namespace. Fixed by adding namespace lstat
support.
Andrew Burgess [Wed, 11 Jun 2025 14:04:38 +0000 (15:04 +0100)]
gdbserver: fix vFile:stat to actually use 'stat'
This commit continues the work of the previous two commits.
In the following commits I added the target_fileio_stat function, and
the target_ops::fileio_stat member function:
* 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
* 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
* 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
* 22836ca8859 gdb: check for multiple matching build-id files
Unfortunately I messed up, despite being called 'stat' these function
actually performed an 'lstat'. The 'lstat' is the correct (required)
implementation, it's the naming that is wrong.
Additionally, to support remote targets, these commit added the
vFile::stat packet, which again, performed an 'lstat'.
In the previous two commits I changed the GDB code to replace 'stat'
with 'lstat' in the fileio function names. I then added a new
vFile:lstat packet which GDB now uses instead of vFile:stat.
And that just leaves the vFile:stat packet which is, right now,
performing an 'lstat'.
Now, clearly when I wrote this code I fully intended for this packet
to perform an lstat, it's the lstat that I needed. But now, I think,
we should "fix" vFile:stat to actually perform a 'stat'.
This is risky. This is a change in remote protocol behaviour.
Reasons why this might be OK:
- vFile:stat was only added in GDB 16, so it's not been "in the
wild" for too long yet. If we're quick, we might be able to "fix"
this before anyone realises I messed up.
- The documentation for vFile:stat is pretty vague. It certainly
doesn't explicitly say "this does an lstat". Most implementers
would (I think), given the name, start by assuming this should be
a 'stat' (given the name). Only if they ran the full GDB
testsuite, or examined GDB's implementation, would they know to
use lstat.
Reasons why this might not be OK:
- Some other debug client could be connecting to gdbserver, sending
vFile:stat and expecting to get lstat behaviour. This would break
after this patch.
- Some other remote server might have implemented vFile:stat
support, and either figured out, or copied, the lstat behaviour
from gdbserver. This remote server would technically be wrong
after this commit, but as GDB no longer uses vFile:stat, then this
will only become a problem if/when GDB or some other client starts
to use vFile:stat in the future.
Given the vague documentation for vFile:stat, and that it was only
added in GDB 16, I think we should fix it now to perform a 'stat', and
that is what this commit does.
The change in behaviour is documented in the NEWS file. I've improved
the vFile:stat documentation in the manual to better explain what is
expected from this packet, and I've extended the existing test to
cover vFile:stat.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Wed, 11 Jun 2025 19:01:56 +0000 (20:01 +0100)]
gdbserver: add vFile:lstat packet support
In the following commits I added the target_fileio_stat function, and
the target_ops::fileio_stat member function:
* 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
* 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
* 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
* 22836ca8859 gdb: check for multiple matching build-id files
Unfortunately I messed up, despite being called 'stat' these function
actually performed an 'lstat'. The 'lstat' is the correct (required)
implementation, it's the naming that is wrong.
In the previous commit I fixed the naming within GDB, renaming 'stat'
to 'lstat' throughout.
However, in order to support target_fileio_stat (as was) on remote
targets, the above patches added the vFile:stat packet, which actually
performed an 'lstat' call. This is really quite unfortunate, and I'd
like to do as much as I can to try and clean up this mess. But I'm
mindful that changing packets is not really the done thing.
So, this commit doesn't change anything.
Instead, this commit adds vFile:lstat as a new packet.
Currently, this packet is handled identically as vFile:stat, the
packet performs an 'lstat' call.
I then update GDB to send the new vFile:lstat instead of vFile:stat
for the remote_target::fileio_lstat implementation.
After this commit GDB will never send the vFile:stat packet.
However, I have retained the 'set remote hostio-stat-packet' control
flag, just in case someone was trying to set this somewhere.
Then there's one test in the testsuite which used to disable the
vFile:stat packet, that test is updated to now disable vFile:lstat.
There's a new test that does a more direct test of vFile:lstat. This
new test can be extended to also test vFile:stat, but that is left for
the next commit.
And so, after this commit, GDB sends the new vFile:lstat packet in
order to implement target_ops::fileio_lstat. The new packet is more
clearly documented than vFile:stat is. But critically, this change
doesn't risk breaking any other clients or servers that implement
GDB's remote protocol.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Wed, 11 Jun 2025 15:10:26 +0000 (16:10 +0100)]
gdb: rename target_fileio_stat to target_fileio_lstat
In the following commits I added the target_fileio_stat function, and
the target_ops::fileio_stat member function:
* 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
* 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
* 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
* 22836ca8859 gdb: check for multiple matching build-id files
Unfortunately, I messed up when adding this API. The actual
underlying call is lstat, not stat.
This commit tries to clear up some of the confusion by renaming things
to target_fileio_lstat and target_ops::fileio_lstat.
After this change the function names now match the underlying
implementation.
One problem remains though. In order to support target_fileio_stat
for remote target the above patches added the vFile:stat packet to GDB
and gdbserver. The implementation of this packet still does an lstat
though, which is a bit of a shame. I'm going to try and fix that in
later commits.
This commit is just a rename within GDB, there should be no user
visible changes.
Timur [Mon, 26 May 2025 12:43:16 +0000 (15:43 +0300)]
gdb/record: Support csrrci instruction in risc-v
During testing csr instructions in risc-v, it occurs that instruction csrrci
is unsupported for recording process and there is such warning:
'warning: Currently this instruction with len 4(100174f3) is unsupported', so
recording failed. This patch fixes this error.
Tom de Vries [Tue, 17 Jun 2025 06:28:50 +0000 (08:28 +0200)]
[gdb/testsuite] Set interactive-mode to on
With MSYS2 and test-case gdb.ada/assign_1.exp, we get:
...
(gdb) dir^M
Reinitialize source path to empty? (y or n) \
[answered Y; input not from terminal]^M^M
Source directories searched: $cdir;$cwd^M^M
(gdb)
...
GDB automatically answers the query, because interactive-mode is off:
...
(gdb) show interactive-mode^M
Debugger's interactive mode is auto (currently off).^M^M
...
The correct value is on, because GDB was started in a terminal.
For some reason, the auto value of interactive-mode is off instead. According
to this patch [1], gdb doesn't recognize the pipes used by DejaGnu testsuite
as an interactive setup.
Fix this by adding "set interactive-mode on" to INTERNAL_GDBFLAGS, such that
we get:
...
(gdb) dir^M
Reinitialize source path to empty? (y or n) y^M
Source directories searched: $cdir;$cwd^M^M
(gdb)
...
and no longer need fixes like commit be740e7cc62 ("testsuite: skip
confirmation in 'gdb_reinitialize_dir'")
The fix is essentially the same as in aforementioned patch.
For consistency, we apply the fix for all platforms.
Co-Authored-By: Pierre Muller <muller@sourceware.org> Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
Tom de Vries [Tue, 17 Jun 2025 06:28:50 +0000 (08:28 +0200)]
[gdb/testsuite] Set TERM to dumb by default
With MSYS2 and default TERM=xterm-256color (as well as with xterm and ansi), I
get:
...
builtin_spawn gdb -q ...
^[[6n(gdb) ERROR: GDB never initialized.
...
This is not specific to gdb, other tools produce the same CSI sequence, and
consequently we run into trouble in other places (like get_compiler_info).
Fix this by default-setting TERM to dumb.
We do this for all platforms, to avoid test-cases passing on one platform but
failing on another.
For test-cases that set TERM to something other than dumb, handle the CSI
sequence in default_gdb_start.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/33072
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33072
Recent GDB commits added more features related to linker namespaces and
documented them on the manual, but did not add a convenient way for a
user to understand what they are. This commit adds a quick explanation
of what they are.
It also fixes the inconsistency of using "linker namespaces" and
"linkage namespaces", by always using the first form to avoid user
confusion.
- A kernel is launched
- The internal runtime breakpoint is hit during the second
hipLaunchKernelGGL call, which causes
amd_dbgapi_target_breakpoint::check_status to be called
- Meanwhile, all waves of the kernel hit the breakpoint on vectorADD
- amd_dbgapi_target_breakpoint::check_status calls process_event_queue,
which pulls the thousand of breakpoint hit events from the kernel
- As part of handling the breakpoint hit events, we write the PC of the
waves that stopped to decrement it. Because the forward progress
requirement is not disabled, this causes a suspend/resume of the
queue each time, which is time-consuming.
The stack trace where this all happens is:
#32 0x00007ffff6b9abda in amd_dbgapi_write_register (wave_id=..., register_id=..., offset=0, value_size=8, value=0x7fffea9fdcc0) at /home/smarchi/src/amd-dbgapi/src/register.cpp:587
#33 0x00005555588c0bed in amd_dbgapi_target::store_registers (this=0x55555c7b1d20 <the_amd_dbgapi_target>, regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2504
#34 0x000055555a5186a1 in target_store_registers (regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/target.c:3973
#35 0x0000555559fab831 in regcache::raw_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:890
#36 0x0000555559fabd2b in regcache::cooked_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:915
#37 0x0000555559fc3ca5 in regcache::cooked_write<unsigned long, void> (this=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:850
#38 0x0000555559fab09a in regcache_cooked_write_unsigned (regcache=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:858
#39 0x0000555559fb0678 in regcache_write_pc (regcache=0x507000002240, pc=0x7ffff62bd900) at /home/smarchi/src/wt/amd/gdb/regcache.c:1460
#40 0x00005555588bb37d in process_one_event (event_id=..., event_kind=AMD_DBGAPI_EVENT_KIND_WAVE_STOP) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1873
#41 0x00005555588bbf7b in process_event_queue (process_id=..., until_event_kind=AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2006
#42 0x00005555588b1aca in amd_dbgapi_target_breakpoint::check_status (this=0x511000140900, bs=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:890
#43 0x0000555558c50080 in bpstat_stop_status (aspace=0x5070000061b0, bp_addr=0x7fffed0b9ab0, thread=0x518000026c80, ws=..., stop_chain=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/breakpoint.c:6126
#44 0x000055555984f4ff in handle_signal_stop (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:7169
#45 0x000055555984b889 in handle_inferior_event (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:6621
#46 0x000055555983eab6 in fetch_inferior_event () at /home/smarchi/src/wt/amd/gdb/infrun.c:4750
#47 0x00005555597caa5f in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/wt/amd/gdb/inf-loop.c:42
#48 0x00005555588b838e in handle_target_event (client_data=0x0) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1513
Fix that performance problem by disabling the forward progress
requirement in amd_dbgapi_target_breakpoint::check_status, before
calling process_event_queue, so that we can process all events
efficiently.
Since the same performance problem could theoritically happen any time
process_event_queue is called with forward progress requirement enabled,
add an assert to ensure that forward progress requirement is disabled
when process_event_queue is invoked. This makes it necessary to add a
require_forward_progress call to amd_dbgapi_finalize_core_attach. It
looks a bit strange, since core files don't have execution, but it
doesn't hurt.
Add a test that replicates this scenario. The test launches a kernel
that hits a breakpoint (with an always false condition) repeatedly.
Meanwhile, the host process loads an unloads a code object, causing
check_status to be called.
Bug: SWDEV-482511
Change-Id: Ida86340d679e6bd8462712953458c07ba3fd49ec Approved-by: Lancelot Six <lancelot.six@amd.com>
Simon Marchi [Mon, 9 Jun 2025 16:09:01 +0000 (12:09 -0400)]
gdb/amd-dbgapi: factor out require_forward_progress overload to target one inferior
A following patch will want to call require_forward_progress for a given
inferior. Extract a new require_forward_progress overload from the
existing require_forward_progress function that targets a specific
inferior.
Change-Id: I54f42b83eb8443d4d91747ffbc86eaeb017f1e49 Approved-by: Lancelot Six <lancelot.six@amd.com>
Simon Marchi [Mon, 9 Jun 2025 16:09:00 +0000 (12:09 -0400)]
gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_one_event
Pass the amd_dbgapi_inferior_info object from process_event_queue to
process_one_event. Since process_event_queue pulls events for one
specific inferior, we know for which inferior the event is. This
removes the need for process_one_event to do two dbgapi calls to get the
relevant pid. If also removes one inferior lookup.
Change-Id: I22927e4b6251513eb3be95785082058aa3d09954 Approved-by: Lancelot Six <lancelot.six@amd.com>
Simon Marchi [Mon, 9 Jun 2025 16:08:59 +0000 (12:08 -0400)]
gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_event_queue
A following patch will make process_event_queue access a field of
amd_dbgapi_inferior_info. Prepare for this by making
process_event_queue accept an amd_dbgapi_inferior_info object, instead
of a process id.
Change-Id: I9adc491dd1ff64ff74c40aa7662fffb11bd8332b Approved-by: Lancelot Six <lancelot.six@amd.com>
Simon Marchi [Mon, 9 Jun 2025 16:08:58 +0000 (12:08 -0400)]
gdb/amd-dbgapi: add assert in require_forward_progress
I didn't have a problem in this area, but it seems to me that this
pre-condition should always hold. We should only disable forward
progress requirement if the target says it's ok to do so. Otherwise, we
could get in a situation where we wait for events from amd-dbgapi, which
will never arrive, because amd-dbgapi didn't actually resume things.
Change-Id: Ifc49f55c7874924b7c47888b8391a07a01d960fc Approved-by: Lancelot Six <lancelot.six@amd.com>
Tom de Vries [Mon, 16 Jun 2025 13:13:25 +0000 (15:13 +0200)]
[gdb/testsuite] Fix gdb.python/py-source-styling-2.exp with TERM=dumb
When running test-case gdb.python/py-source-styling-2.exp with TERM=dumb, I
get:
...
(gdb) set style enabled on^M
warning: The current terminal doesn't support styling. \
Styled output might not appear as expected.^M
(gdb) FAIL: $exp: set style enabled on
...
Fix this by using with_ansi_styling_terminal on clean_restart.
+#if BFD_SUPPORTS_PLUGINS
+ /* Copy LTO IR file as unknown object. */
+ if (bfd_plugin_target_p (ibfd->xvec))
^^^^ A typo, should be this_element.
+ ok_object = false;
+ else
+#endif
if (ok_object)
{
ok = copy_object (this_element, output_element, input_arch);
to check if the archive element is a LTO IR file. "ibfd" is the archive
BFD. "this_element" should be used to check for LTO IR in the archive
element. Fix it by replacing "ibfd" with "this_element".
PR binutils/33078
* objcopy.c (copy_archive): Correctly check archive element for
LTO IR.
* testsuite/binutils-all/objcopy.exp (strip_test_archive): New.
Run strip_test_archive.
Stafford Horne [Sun, 1 Jun 2025 05:39:01 +0000 (06:39 +0100)]
or1k: Add support for numcores and coreid sprs
These are needed when running GCC tests for newlib toolchains built with
multicore support. Without these SPRs we get the following warnings
when running tests.
spawn or1k-elf-run ./20000112-1.exe^M
WARNING: l.mfspr with invalid SPR address 0x80^M
WARNING: l.mfspr with invalid SPR address 0x81^M
WARNING: l.mfspr with invalid SPR address 0x81^M
WARNING: l.mfspr with invalid SPR address 0x81^M
Support is added by defining the SPRs in the cgen machine definition and
regenerating the machine code. In or1k/or1k.c we initialize NUMCORES to
1 and COREID to 0 as the sim has only one CPU. In or1k/traps.c we allow
returning the NUMCORES and COREID spr values in the mfspr function.
Simon Marchi [Mon, 5 May 2025 20:15:26 +0000 (16:15 -0400)]
gdbsupport: make gdb::parallel_for_each's n parameter a template parameter
This value will likely never change at runtime, so we might as well make
it a template parameter. This has the "advantage" of being able to
remove the unnecessary param from gdb::sequential_for_each.
Change-Id: Ia172ab8e08964e30d4e3378a95ccfa782abce674 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 2 May 2025 17:57:57 +0000 (13:57 -0400)]
gdb: re-work parallel-for-selftests.c
I find this file difficult to work with and modify, due to how it uses
the preprocessor to include itself, to generate variations of the test
functions. Change it to something a bit more C++-y, with a test
function that accepts a callback to invoke the foreach function under
test.
Jan Beulich [Fri, 13 Jun 2025 11:46:30 +0000 (13:46 +0200)]
x86: don't constrain %axl/%cxl
They can be used like their %al/%cl counterparts everywhere else;
there's no apparent reason why they shouldn't be usable as accumulator /
shift count respectively. Enforcing such a restriction only makes
writing heavily macro-ized code more cumbersome.
Jan Beulich [Fri, 13 Jun 2025 11:46:06 +0000 (13:46 +0200)]
x86: swap operands in OUT-with-immediate template
In a number of places we assume that immediates come first in the set of
operands. It is mere luck that so far OUT, having operands the other way
around, wasn't negatively impacted by this.
Leverage this to have a few loops start from the first non-immediate
operand (or in one case to stop there). Note, however, that
process_immext() inserts an immediate last, so especially all output_*()
functions cannot be changed in the same way.
objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x22000000) in group [3]
objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x21000000) in group [3]
objcopy: /tmp/objcopy-poc(OrcError.cpp.o)(.text._ZNK12_GLOBAL__N_116OrcErrorCategory7messageB5cxx11Ei): relocation 29 has invalid symbol index 1160982879
objcopy: /tmp/stv73zYw/OrcError.cpp.o[.text._ZN4llvm3orc8orcErrorENS0_12OrcErrorCodeE]: bad value
instead of
objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x22000000) in group [3]
objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x21000000) in group [3]
objcopy: /tmp/objcopy-poc(OrcError.cpp.o)(.text._ZNK12_GLOBAL__N_116OrcErrorCategory7messageB5cxx11Ei): relocation 29 has invalid symbol index 1160982879
Segmentation fault (core dumped)
PR binutils/33075
* elf.c (elf_map_symbols): Return false if output_section is
NULL.
Jan Beulich [Fri, 13 Jun 2025 06:40:32 +0000 (08:40 +0200)]
x86: refine UD<n> kind-of-insns
While documentation of these continues to be lacking sufficient detail,
it is becoming increasingly clear that in 66f1eba0b7e8 ("x86: correct
UDn") I went too far with requiring operands, to populate a ModR/M byte.
AMD hardware appears to always behave as indicated as "may" in PM 3.36,
which for all practical purposes means there's no ModR/M byte. The SDM
(rev 087) indicates that such behavior can occur on older hardware for
UD0. Re-add an operand-less UD1 form (as well as its UD2B alias), while
newly adding such a form also for UD0. Because of the ambiguity, there's
no good/easy way of handling both possibilities in the disassembler,
which hence remains unaltered.
Further, from all information I'm able to gather, the 0F opcode space
was only introduced with the i286; bump the minimal hardware requirement
for all UD<n> accordingly.
Jan Beulich [Fri, 13 Jun 2025 06:40:01 +0000 (08:40 +0200)]
gas: switch convert_to_bignum() to taking just an expression
Both callers, despite spelling things differently, now pass the same
input for its 2nd parameter. Therefore, as was supposed to be the case
anyway, this 2nd parameter isn't needed anymore - the function can
calculate "sign" all by itself from the incoming expression. Instead
make the function return the resulting value, for emit_expr_with_reloc()
to consume for setting its "extra_digit" local variable.
Jan Beulich [Fri, 13 Jun 2025 06:39:44 +0000 (08:39 +0200)]
gas: also maintain signed-ness for O_big expressions
Interestingly emit_leb128_expr() already assumes X_unsigned is properly
set for O_big. Adjust its conversion-to-bignum to respect the incoming
flag, and have convert_to_bignum() correctly set it on output.
It further can't be quite right that convert_to_bignum() depends on
anything other than the incoming expression. Therefore adjust
emit_expr_with_reloc() to be in line with the other invocation.
This also requires an adjustment for SH, which really should have been
part of 762acf217c40 ("gas: maintain O_constant signedness in more
cases").
Jeremy Drake [Fri, 13 Jun 2025 05:52:47 +0000 (07:52 +0200)]
ld,dlltool: move read-only delayimp data into .rdata
This allows the delay IAT to be in its own section with nothing else, as
required by IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION, documented at
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#load-configuration-layout
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
LIU Hao [Fri, 13 Jun 2025 05:52:29 +0000 (07:52 +0200)]
bfd,ld,dlltool: Emit delay-load import data into its own section
A delay-import symbol (of a function) is resolved when a call to it is made.
The delay loader may overwrite the `__imp_` pointer to the actual function
after it has been resolved, which requires the pointer itself be in a
writeable section.
Previously it was placed in the ordinary Import Address Table (IAT), which
is emitted into the `.idata` section, which had been changed to read-only
in db00f6c3aceabbf03acdb69e74b59b2d2b043cd7, which caused segmentation
faults when functions from delay-import library were called. This is
PR 32675.
This commit makes DLLTOOL emit delay-import IAT into `.didat`, as specified
by Microsoft. Most of the code is copied from `.idata`, except that this
section is writeable. As a side-effect of this, PR 14339 is also fixed.
Reference: https://learn.microsoft.com/en-us/windows/win32/secbp/pe-metadata#import-handling Co-authored-by: Jeremy Drake <sourceware-bugzilla@jdrake.com> Signed-off-by: LIU Hao <lh_mouse@126.com> Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
Klaus Gerlicher [Thu, 12 Jun 2025 15:37:50 +0000 (15:37 +0000)]
gdb, linespec: avoid multiple locations with same PC
Setting a BP on a line like this would incorrectly yield two BP locations:
01 void two () { {int var = 0;} }
(gdb) break 1
Breakpoint 1 at 0x1164: main.cpp:1. (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000001164 in two() at main.cpp:1
1.2 y 0x0000000000001164 in two() at main.cpp:1
In this case decode_digits_ordinary () returns two SALs, exactly matching the
requested line. One for the entry PC and one for the prologue end PC. This
was
tested with GCC, CLANG and ICPX. Subsequent code tries to skip the prologue
on these PCs, which in turn makes them the same.
To fix this, ignore SALs with the same PC and program space when adding to the
list of SALs.
This will then properly set only one location:
(gdb) break 1
Breakpoint 1 at 0x1164: file main.cpp, line 1
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000001164 in two() at main.cpp:1
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 11 Jun 2025 09:20:17 +0000 (10:20 +0100)]
gdb: convert linux-namespaces debug to the new(er) debug scheme
Convert 'set debug linux-namespaces' to the new(er) debug scheme. As
part of this change I converted the mnsh_debug_print_message function,
which previously printed its output, to instead return a std::string,
this string is then printed using linux_namespaces_debug_printf. The
mnsh_debug_print_message function is only used as part of the debug
output.
I also updated one place in the code where debug_linux_namespaces, the
debug control variable, which is a boolean, was assigned an integer.
When debug is turned on then clearly the output is now different, but
in all other cases, there should be no user visible change in GDB
after this commit.
Richard Ball [Thu, 12 Jun 2025 00:39:24 +0000 (01:39 +0100)]
aarch64: Add support for FEAT_FPRCVT
FEAT_FPRCVT introduces new versions of previous instructions.
The instructions are used to convert between floating points and
Integers. These new versions take as operands SIMD&FP registers
for both the source and destination register. FEAT_FPRCVT also
enables the use of some existing AdvSIMD instructions in
streaming mode. However, no changes are needed in gas to support this.
Aaron Griffith [Mon, 9 Jun 2025 19:19:41 +0000 (15:19 -0400)]
gdb: fix size of z80 "add ii,rr" and "ld (ii+d),n" instructions
The tables in z80-tdep.c previously either gave these instructions the
wrong size, or failed to recognize them by using the wrong masks, or
both. The fixed instructions alongside their representation in octal are:
GDB: doc: Improve AArch64 subsubsection titles and index entries in gdb.texinfo
Remove period from subsubsection titles in the AArch64 configuration-specific
subsection, and expand acronyms.
Regarding @cindex entries, remove periods and standardise their order
and the position of "AArch64" to make it easier to find them by
using the index-searching commands of Info readers that offer TAB
completion.
Matthieu Longo [Wed, 21 May 2025 10:08:31 +0000 (11:08 +0100)]
Arm tests: reduce objdump's output and improve some matching patterns
Linker scripts can change the sections order in the output. Some matching
patterns in tests try to detect the end of a section by detecting the
beginning of the next one. However, they mistakenly enforce the name of
the next section without any need. This caused the tests to break due to
minor changes to the linker scripts.
This patch adds '-j <interesting-section>' to the arguments of objdump
to dump only relevant information for the tests. This removed the issue
related to the ordering of the sections. The matching patterns were also
made stricter to match better the expected output.
Pedro Alves [Thu, 1 Jun 2023 17:43:15 +0000 (18:43 +0100)]
gdb testsuite: Introduce allow_multi_inferior_tests and use it throughout
The Windows port does not support multi-process debugging. Testcases
that want to exercise multi-process currently FAIL and some hit
cascading timeouts. Add a new allow_multi_inferior_tests procedure,
meant to be used with require, and sprinkle it throughout testcases as
needed.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I4a10d8f04f9fa10f4b751f140ad0a6d31fbd9dfb
Pedro Alves [Thu, 1 Jun 2023 15:19:03 +0000 (16:19 +0100)]
gdb testsuite: Introduce allow_fork_tests and use it throughout
Cygwin debugging does not support follow fork. There is currently no
interface between the debugger and the Cygwin runtime to be able to
intercept forks and execs. Consequently, testcases that try to
exercise fork/exec all FAIL, and several hit long cascading timeouts.
Add a new allow_fork_tests procedure, meant to be used with require,
and sprinkle it throughout testcases that exercise fork.
Note that some tests currently are skipped on targets other than
Linux, with something like:
# Until "set follow-fork-mode" and "catch vfork" are implemented on
# other targets...
#
if {![istarget "*-linux*"]} {
continue
}
However, some BSD ports also support fork debugging nowadays, and the
testcases were never adjusted... That is why the new allow_fork_tests
procedure doesn't look for linux.
With this patch, on Cygwin, I get this:
$ make check TESTS="*/*fork*.exp"
...
=== gdb Summary ===
# of expected passes 6
# of untested testcases 1
# of unsupported tests 31
Reviewed-By: Keith Seitz <keiths@redhat.com>
Change-Id: I0c5e8c574d1f61b28d370c22a0b0b6bc3efaf978
Pedro Alves [Fri, 2 Jun 2023 00:05:38 +0000 (01:05 +0100)]
gdb.multi/attach-no-multi-process.exp: Detect no remote non-stop
Running gdb.multi/attach-no-multi-process.exp on Cygwin, where
GDBserver does not support non-stop mode, I see:
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: info threads
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)
Let's ignore the first "info threads" fail. The timeouts look like
this:
builtin_spawn /home/alves/gdb-cache-cygwin/gdb/../gdbserver/gdbserver --once --multi localhost:2346
Listening on port 2346
target extended-remote localhost:2346
Remote debugging using localhost:2346
Non-stop mode requested, but remote does not support non-stop
(gdb) gdb_do_cache: can_spawn_for_attach ( )
builtin_spawn /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.multi/attach-no-multi-process/attach-no-multi-process
attach 14540
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
info threads
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)
Note the "Non-stop mode requested, but remote does not support
non-stop" line.
The intro to gdb_target_cmd_ext says:
# gdb_target_cmd_ext
# Send gdb the "target" command. Returns 0 on success, 1 on failure, 2 on
# unsupported.
That's perfect here, we can just use gdb_target_cmd_ext instead of
gdb_target_cmd, and check for 2 (unsupported). That's what this patch
does.
However gdb_target_cmd_ext incorrectly returns 1 instead of 2 for the
case where the remote target says it does not support non-stop. That
is also fixed by this patch.
With this, we no longer get those timeout fails. We get instead:
target extended-remote localhost:2346
Remote debugging using localhost:2346
Non-stop mode requested, but remote does not support non-stop
(gdb) UNSUPPORTED: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: non-stop RSP
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I1ab3162f74200c6c02a17a0600b102d2d12db236
Pedro Alves [Wed, 3 Apr 2024 21:34:47 +0000 (22:34 +0100)]
Convert gdb.base/watchpoint-hw-attach.exp to spawn_wait_for_attach
On Cygwin, starting an inferior under GDB, and detaching it, quitting
GDB, and then closing the shell, like so:
(gdb) start
(gdb) detach
(gdb) quit
# close shell
... hangs the parent shell of GDB (not GDB!) until the inferior
process that was detached (as it is still using the same terminal GDB
was using) exits too.
This leads to odd failures in gdb.base/watchpoint-hw-attach.exp like
so:
detach
Detaching from program: .../outputs/gdb.base/watchpoint-hw-attach/watchpoint-hw-attach, process 16580
[Inferior 1 (process 16580) detached]
(gdb) FAIL: gdb.base/watchpoint-hw-attach.exp: detach
Fix this by converting the testcase to spawn the inferior outside GDB,
with spawn_wait_for_attach.
With this patch, the testcase passes cleanly on Cygwin, for me.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I8e3884073a510d6fd2fff611e1d26fc808adc4fa
ld: arm32: fix segfault when linking foreign BFDs [PR32870]
PR ld/32870
The linker may occasionally need to process a BFD that is from a
non-Arm architecture. There will not be any Arm-specific tdata in
that case, so skip such BFDs when looking for iplt information as the
necessary tdata will not be present.
Tom Tromey [Tue, 10 Jun 2025 13:15:10 +0000 (07:15 -0600)]
Fix Solaris build
Commit 58984e4a ("Use gdb::function_view in iterate_over_threads")
broke the Solaris build. This patch attempts to fix it, changing
find_signalled_thread to have the correct signature, and correcting a
couple of problems in sol_thread_target::get_ada_task_ptid.
Jan Beulich [Wed, 11 Jun 2025 12:32:34 +0000 (14:32 +0200)]
ld/PE: special-case relocation types only for COFF inputs
In 72cd2c709779 ("ld/PE: no base relocs for section (relative) ones") I
made a pre-existing problem quite a bit worse: When looking at a
relocation's (numerical) howto->type, that value is meaningful only if
the object was of corresponding COFF type. ELF objects in particular
have their own enumeration. As it stands, specifically the not entirely
unusual R_X86_64_32 and R_X86_64_32S did no longer have relocations
emitted for them, due to matching R_AMD64_SECTION and R_AMD64_SECREL in
value respectively.
Jan Beulich [Wed, 11 Jun 2025 12:32:13 +0000 (14:32 +0200)]
arm: ignore inapplicable .arch=no...
Unlike for command line options, where a base architecture needs to be
provided explicitly, the .arch directive doesn't have such a
requirement. Therefore it is odd that disabling of an inapplicable
extension isn't silently ignored; claiming "not allowed for the current
base architecture" is at best misleading. Alter the error path to emit a
more "soft" diagnostic in that case instead.
Matthieu Longo [Wed, 21 May 2025 10:20:40 +0000 (11:20 +0100)]
AArch64 variant PCS tests: remove RWX permissions on segments
The symbols of variant PCS functions require special handling. The variant PCS
tests check both the relocation information and the markings in the symbol table.
Those tests dump a lot of addresses, so a custom linker script, variant_pcs.ld
was used to control reliably the addresses of the sections.
However, the linker script does not provide information enough to the linker to
assess the right set of permisssions on segments (i.e. Read/Write/Execute).
This insufficiency caused the linker to bundle all the sections in a same segment
with the union of all the required permissions, i.e. RWX.
A segment with such lax permissions constitutes a security hole, so the linker
emits the following warning message:
<ELF file> has a LOAD segment with RWX permissions.
This warning message is noisy in the tests, and has no reason to exist.
This issue can be addressed in two ways:
- either by providing the right set of permissions on a section so that the
linker assigns them to a segment with compatible permissions.
- or by providing alignment constraints so that the linker can move the sections
automatically to a new segment and set the right permission for non-executable
data.
The second option seems to be the preferred approach, even if not explicitly
recommended. Examples of linker scripts for AArch64 are available at [1].
This patch reorganizes the linker script to eliminate RWX segments by changing
the order of the sections and their offset. The tests needed to be amended to
match the new addresses.
Matthieu Longo [Wed, 21 May 2025 10:19:48 +0000 (11:19 +0100)]
AArch64 BTI/PAC PLT tests: remove RWX permissions on segments
The bti-far.ld and bti-plt.ld scripts don't provide information enough to the
linker to assess the right set of permisssions on segments (i.e. Read/Write/Execute).
This insufficiency caused the linker to bundle all the sections in a same segment
with the union of all the required permissions, i.e. RWX.
A segment with such lax permissions constitutes a security hole, so the linker
emits the following warning message:
<ELF file> has a LOAD segment with RWX permissions.
This warning message is noisy in the tests, and has no reason to exist.
This issue can be addressed in two ways:
- either by providing the right set of permissions on a section so that the
linker assigns them to a segment with compatible permissions.
- or by providing alignment constraints so that the linker can move the sections
automatically to a new segment and set the right permission for non-executable
data.
The second option seems to be the preferred approach, even if not explicitly
recommended. Examples of linker scripts for AArch64 are available at [1].
The fixes in bti-far.ld and bti-plt.ld are the same, except that bti-far.ld also
contains a ".far" section, to make sure that it generates the trampolines correctly.
Matthieu Longo [Wed, 21 May 2025 10:18:48 +0000 (11:18 +0100)]
AArch64 tests: remove RWX permissions on segments
aarch64.ld is the linker script used by most of the relocation tests in AArch64
testsuite. The script does not provide information enough to the linker to assess
the right set of permisssions on segments (i.e. Read/Write/Execute).
This insufficiency caused the linker to bundle all the sections in a same segment
with the union of all the required permissions, i.e. RWX.
A segment with such lax permissions constitutes a security hole, so the linker
emits the following warning message:
<ELF file> has a LOAD segment with RWX permissions.
This warning message is noisy in the tests, and has no reason to exist.
This issue can be addressed in two ways:
- either by providing the right set of permissions on a section so that the
linker assigns them to a segment with compatible permissions.
- or by providing alignment constraints so that the linker can move the sections
automatically to a new segment and set the right permission for non-executable
data.
The second option seems to be the preferred approach, even if not explicitly
recommended. Examples of linker scripts for AArch64 are available at [1].
Alan Modra [Mon, 9 Jun 2025 05:30:30 +0000 (15:00 +0930)]
gas md_apply_fix bad casts
ns32k and z8k cast a valueT pointer to a long pointer when loading
md_apply_fix's value. That's quite wrong if the types have different
sizes, as they may eg. on a 32-bit host with 64-bit bfd support.
sparc also loads the value via a cast pointer, but at least in that
case the cast is to the same size pointer. None of these casts are
needed. Get rid of them.
Alan Modra [Tue, 10 Jun 2025 10:59:33 +0000 (20:29 +0930)]
loongarch gcc-4.5 build fixes
Yet another case of missing fields in struct initialisation, which
I've replaced with a memset, and some complaints about identifiers
shadowing global declarations. Fixing the shadowing in
loongarch-parse.y is easy. This one isn't so easy:
gas/expr.c: In function 'expr':
gas/expr.c:1891:12: error: declaration of 'is_unsigned' shadows a global declaration
include/opcode/loongarch.h:224:14: error: shadowed declaration is here
opcode/loongarch.h declares lots of stuff that shouldn't be made
available to generic gas code, so I've removed that header from
tc-loongarch.h and moved the parts of TC_FORCE_RELOCATION_SUB_LOCAL
and TC_FORCE_RELOCATION_SUB_LOCAL that need LARCH_opts to functions
in tc-loongarch.c
* config/loongarch-parse.y (loongarch_parse_expr): Rename
param to avoid shadowing.
* config/tc-loongarch.c (loongarch_assemble_INSNs): Use memset
rather than struct initialisation.
(loongarch_force_relocation_sub_local): New function.
(loongarch_force_relocation_sub_same): Likewise.
* config/tc-loongarch.h: Don't include opcode/loongarch.h.
(loongarch_force_relocation_sub_local): Declare, and..
(TC_FORCE_RELOCATION_SUB_LOCAL): ..use here.
(loongarch_force_relocation_sub_same): Declare, and..
(TC_FORCE_RELOCATION_SUB_SAME): ..use here.
Alan Modra [Tue, 10 Jun 2025 10:58:42 +0000 (20:28 +0930)]
kvx gcc-4.5 build fixes
More missing struct initialisers, for expressionS vars that in this
case don't need to be initialised. Also an error: redefinition of
typedef 'symbolS'. OK, so don't use a typedef.
Alan Modra [Tue, 10 Jun 2025 09:03:04 +0000 (18:33 +0930)]
csky gcc-4.5 build fix
gcc-4.5 warns about missing csky_cpus struct initialisers. Fix that
by providing everything in the init macros and the zero sentinel,
rather than just a single {0} as allowed by C99.
Alan Modra [Mon, 9 Jun 2025 11:04:02 +0000 (20:34 +0930)]
gas: xtensa build failure with --enable-64-bit-bfd
A 32-bit host with --enable-64-bit-bfd --target=xtensa-lx106-elf give:
gas/config/tc-xtensa.c: In function ‘xg_get_best_chain_entry’:
gas/config/tc-xtensa.c:7689:11: error: absolute value function ‘labs’ given an argument of type ‘offsetT’ {aka ‘long long int’} but has parameter of type ‘long int’ which may cause truncation of value [-Werror=absolute-value]
7689 | if (labs (off) >= J_RANGE - J_MARGIN)
| ^~~~
Let's not use labs. Unlike labs vma_abs deliberately returns an
unsigned value, and does the negation in an unsigned type so that
signed overflow can't happen.
* config/tc-xtensa.c (vma_abs): New function.
(xg_get_best_chain_entry, xg_get_fulcrum, xg_find_best_trampoline),
(xg_is_relaxable_fixup): Use in place of labs.
Matthieu Longo [Wed, 21 May 2025 10:13:33 +0000 (11:13 +0100)]
AArch64, Arm and TIC6x tests: fix typo in linker scripts
The linker scripts for AArch64 and TIC6x were probably originally copied from
Arm testsuite, and contain the same typo in the name of the attributes section.
This patch fixes the typo across all the testsuites.
Simon Marchi [Tue, 10 Jun 2025 03:07:04 +0000 (23:07 -0400)]
gdb/dwarf2: remove erroneous comment in open_and_init_dwo_file
When writing commit 28f15782adab ("gdb/dwarf: read multiple .debug_info.dwo
sections"), I initially thought that the gcc behavior of producing multiple
.debug_info.dwo sections was a bug (it is not). I updated the commit
message, but it looks like this comment stayed. Remove it, since it can
be misleading.
Change-Id: I027712d44b778e836f41afbfafab993da02726ef Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 5 Jun 2025 19:18:43 +0000 (15:18 -0400)]
gdb/solib-svr4: remove svr4_have_link_map_offsets
While C++ifying the solib code, I concluded that all arches that use
SVR4 libraries do provide link map offsets, so I think this function is
unnecessary now.
Change-Id: Ifaae2560d92f658df3724def6219e2f89054e4b7 Approved-By: Tom Tromey <tom@tromey.com>
Here, the breakpoint only got one location because both the in-charge
and the not-in-charge dtors are identical and got the same address:
$ nm -A ./testsuite/outputs/gdb.cp/cpexprs/cpexprs| c++filt |grep "~base"
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
While on Cygwin, we get two locations for the same breakpoint, which
the testcase isn't expecting:
Thread 1 "cpexprs" hit Breakpoint 117.1, base::~base (this=0x7ffffcaf8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
135 ~base (void) { } // base::~base
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to base::~base
We got two locations because the in-charge and the not-in-charge dtors
have different addresses:
$ nm -A outputs/gdb.cp/cpexprs/cpexprs.exe | c++filt | grep "~base"
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402680 T base::~base()
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402690 T base::~base()
On Cygwin, we also see the typical failure due to not expecting the
inferior to be multi-threaded:
(gdb) continue
Continuing.
[New Thread 628.0xe08]
Thread 1 "cpexprs" hit Breakpoint 200, test_function (argc=1, argv=0x7ffffcc20) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:336
336 derived d;
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to test_function for policyd3::~policyd
Both issues are fixed by this patch, and now the testcase passes
cleanly on Cygwin, for me.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Change-Id: If7eb95d595f083f36dfebf9045c0fc40ef5c5df1
Pedro Alves [Fri, 23 Jun 2023 20:01:39 +0000 (21:01 +0100)]
gdb.threads/thread-execl, don't re-exec forever
I noticed on Cygwin, gdb.thread/thread-execl.exp would hang, (not that
surprising since we can't follow-exec on Cygwin). Looking at the
process list running on the machine, we end up with a thread-execl.exe
process constantly respawning another process [1].
We see the same constant-reexec if we launch gdb.thread/thread-execl
manually on the shell:
Pedro Alves [Mon, 26 Jun 2023 12:56:26 +0000 (13:56 +0100)]
Support core dumping testcases with Cygwin's dumper
Cygwin supports dumping ELF cores via a dumper.exe utility, see
https://www.cygwin.com/cygwin-ug-net/dumper.html.
When I run a testcase that has the "kernel" generate a corefile, like
gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and
generates an ELF core file, however, the testsuite doesn't find the
generated core:
foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" {
Note that that isn't looking for "${binfile}.core" inside
${coredir}... That is fixed in this patch.
However, that still isn't sufficient for Cygwin + dumper, as in that
case the core is going to be called foo.exe.core, not foo.core. Fix
that by looking for foo.exe.core in the core dir as well.
With this, gdb.base/corefile.exp and other tests that use core_find
now run. They don't pass cleanly, but at least now they're exercised.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e
Pedro Alves [Mon, 26 Jun 2023 20:03:32 +0000 (21:03 +0100)]
Adjust gdb.base/sigall.exp for Cygwin
The gdb.base/sigall.exp testcase has many FAILs on Cygwin currently.
From:
Thread 1 "sigall" received signal SIGPWR, Power fail/restart.
0x00007ffeac9ed134 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) FAIL: gdb.base/sigall.exp: get signal LOST
we see two issues. The test is expecting "Program received ..." which
only appears if the inferior is single-threaded. All Cygwin inferiors
are multi-threaded, because both Windows and the Cygwin runtime spawn
a few helper threads.
And then, SIGLOST is the same as SIGPWR on Cygwin. The testcase
already knows to treat them the same on SPARC64 GNU/Linux. We just
need to extend the relevant code to treat Cygwin the same.
With this, the test passes cleanly on Cygwin.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ie3553d043f4aeafafc011347b6cb61ed58501667
projects / thirdparty / binutils-gdb.git / log
