Keith Seitz [Mon, 12 May 2025 16:28:02 +0000 (09:28 -0700)]
[PATCH] Add syscall tests when following/detaching from fork
breakpoints/13457 discusses issues with syscall catchpoints when
following forks, lamenting that there is no coverage for the
various permutations of `follow-fork-mode' and `detach-on-fork'.
This is an attempt to try and cover some of this ground. Unfortunately
the state of syscall support when detaching after the fork is
very, very inconsistent across various architectures. [I've tested
extensively Fedora/RHEL platforms.]
Right now, the only reliable platform to run tests on is x86_64/i?86
for the specific case where we do not detach from the fork. Consequently,
this patch limits testing to those architectures.
I have updated breakpoints/13457 with my findings on failures with the
detaching case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13457 Approved-By: Andrew Burgess <aburgess@redhat.com>
Ezra Sitorus [Fri, 2 May 2025 17:08:21 +0000 (18:08 +0100)]
aarch64: Support for FEAT_RME_GPC3
FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces
a method for defining a set of windows in the memory map for which
Granule Protection Checks are skipped, and instead applies a set of
default settings associated with the window.
This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to
access this sysreg since this feature is optional from armv9.5-a.
Ezra Sitorus [Fri, 2 May 2025 16:14:07 +0000 (17:14 +0100)]
aarch64: Support for FEAT_OCCMO
FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces
system instructions that provides software with a mechanism to publish
writes to the Outer cache level.
Patrick Monnerat [Mon, 12 May 2025 15:36:17 +0000 (17:36 +0200)]
gdbsupport/event-loop: do not truncate poll timeouts to lower second
In update_wait_timeout function, microseconds were not taken into account
in poll timeout computation, resulting in 100% cpu time consumption in
the event loop while waiting for a sub-second timeout.
This patch adds the microseconds converted to milliseconds in poll
timeout computation. Conversion by excess (ceil) is performed to
avoid the same problem with sub-millisecond timeouts too.
Andrew Burgess [Wed, 7 May 2025 10:00:13 +0000 (11:00 +0100)]
gdb: pass std::string from linux_find_memory_regions_full
Update linux_find_memory_region_ftype to take 'const std::string &'
instead of 'const char *', update the two functions which are passed
as callbacks to linux_find_memory_regions_full.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 7 May 2025 09:53:41 +0000 (10:53 +0100)]
gdb: move extra checks into dump_note_entry_p
Now that dump_note_entry_p is always called (see previous commit), we
can move some of the checks out of linux_make_mappings_callback into
dump_note_entry_p.
The checks only exist in linux_make_mappings_callback because, before
the previous commit, we couldn't be sure that dump_note_entry_p would
be called or not, so linux_make_mappings_callback had to run its own
checks.
Now that dump_note_entry_p is always called we can rely on that
function to filter out which mappings should result in an NT_FILE
entry, and linux_make_mappings_callback can just create an entry for
everything it is passed.
As a result of this change I was able to remove the inode argument
from linux_make_mappings_callback and
linux_find_memory_regions_thunk. The inode check has now moved to
dump_note_entry_p.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 7 May 2025 09:33:09 +0000 (10:33 +0100)]
gdb: always call should_dump_mapping_p during core file creation
This commit moves the logic for whether should_dump_mapping_p is
called out of linux_find_memory_regions_full and pushes it down into
the two callback functions that are used as the should_dump_mapping_p
callback; `dump_mapping_p` and `dump_note_entry_p`.
Older Linux kernels don't make the 'Anonymous' information available
in the smaps file, and currently, GDB handles this by not calling the
should_dump_mapping_p callback in linux_find_memory_regions_full,
instead the answer is hard-coded to true.
This is (maybe) fine for dump_mapping_p, but for dump_note_entry_p,
this choice makes little sense. The dump_note_entry_p function
doesn't even use the anonymous mapping information.
I propose that the 'has_anonymous' check should be moved out of
linux_find_memory_regions_full, and pushed into dump_mapping_p. Then
in dump_note_entry_p there will be no has_anonymous check; it just
isn't needed.
This allows linux_find_memory_regions_full to be simplified a little,
and will allow some additional clean ups in
linux_make_mappings_callback, which is the partner function to
dump_note_entry_p (see linux_make_mappings_corefile_notes), now that
we know dump_note_entry_p is always called. This follow on clean up
will be done in a later commit in this series.
Looking at dump_mapping_p, I do wonder if the ::has_anonymous check
could be moved later in the function. The first few checks in
dump_mapping_p don't rely on the anonymous information, so running
them might give better results. However, the lack of the anonymous
information is only for older kernels, so testing any changes in this
area would likely require spinning up an older kernel, and as the
years pass, we likely care about this case less. So for now I've left
the ::has_anonymous check as the first thing in dump_mapping_p as this
keeps the existing behaviour.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 7 May 2025 09:22:37 +0000 (10:22 +0100)]
gdb: pass struct smaps_data to linux_dump_mapping_p_ftype
Simplify the argument passing in linux_find_memory_regions_full when
calling the should_dump_mapping_p callback. Instead of pulling all
the components from the smaps_data object and passing them separately,
just pass the smaps_data object.
I think this change is justified on its own; the code seems cleaner,
and easier to read to my eye. But additionally, in a later commit in
this series I want to pass smaps_data::has_anonymous to the
should_dump_mapping_p callback, which would mean adding yet another
argument, and I think the argument list is already long enough.
Changing the function now to pass the smaps_data object means that I
will already have the ::has_anonymous field available in the later
commit.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb: add '-stopped' and '-running' options to "info threads"
Add two options to "info threads": `-stopped` and `-running`.
The purpose of these options is to filter the output of the command.
The `-stopped` option means "print stopped threads only" and,
similarly, `-running` means "print the running threads only". When
both options are provided by the user, the indication is that the user
wants the union. That is, the output contains both stopped and
running threads.
Suppose we have an application with 5 threads, 2 of which have hit a
breakpoint. The "info threads" command in the non-stop mode gives:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7d99740 (running)
2 Thread 0x7ffff7d98700 something () at file.c:30
3 Thread 0x7ffff7597700 (running)
4 Thread 0x7ffff6d96700 something () at file.c:30
5 Thread 0x7ffff6595700 (running)
(gdb)
Using the "-stopped" flag, we get
(gdb) info threads -stopped
Id Target Id Frame
2 Thread 0x7ffff7d98700 something () at file.c:30
4 Thread 0x7ffff6d96700 something () at file.c:30
(gdb)
Using the "-running" flag, we get
(gdb) info threads -running
Id Target Id Frame
* 1 Thread 0x7ffff7d99740 (running)
3 Thread 0x7ffff7597700 (running)
5 Thread 0x7ffff6595700 (running)
(gdb)
Using both flags prints all:
(gdb) info threads -stopped -running
Id Target Id Frame
* 1 Thread 0x7ffff7d99740 (running)
2 Thread 0x7ffff7d98700 something () at file.c:30
3 Thread 0x7ffff7597700 (running)
4 Thread 0x7ffff6d96700 something () at file.c:30
5 Thread 0x7ffff6595700 (running)
(gdb)
When combined with a thread ID, filtering applies to those threads that
are matched by the ID.
(gdb) info threads 3
Id Target Id Frame
3 Thread 0x7ffff7597700 (running)
(gdb) info threads -stopped 3
No threads matched.
(gdb)
Regression-tested on X86_64 Linux.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-by: Pedro Alves <pedro@palves.net
gdb: update "info threads" output when no threads match the arguments
If "info threads" is provided with the thread ID argument but no such
threads matching the thread ID(s) are found, GDB prints
No threads match '<ID...>'.
Update this output to the more generalized
No threads matched.
The intention is that the next patch, and potentially future ones,
will extend the command with more filter/match arguments. We cannot
customize the output to each such argument. Hence, be more generic.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-by: Pedro Alves <pedro@palves.net
gdb: pass info_threads_opts to print_thread_info_1
The "info threads" command tracks its options in a struct named
'info_threads_opts', which currently has only one option. Pass the
whole options object to helper functions, instead of passing
the option value individually. This is a refactoring to make adding
more options easier.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-by: Pedro Alves <pedro@palves.net
Alan Modra [Fri, 9 May 2025 03:46:24 +0000 (13:16 +0930)]
msan: use of uninitialised data in get_cie_info
This completely bogus oss-fuzz x86 testcase results in a read from an
uninitialised (at the time check_eh_frame is called) part of an insn
frag:
.section .debug_frame
orl $1,x
.long x
.uleb128 0,x,0
x:
Fix the problem by verifying the assumption in get_cie_info that a CIE
starts at the beginning of .eh_frame or .debug_frame. Or at least
exclude silliness involving instructions placed there. That seems a
useful sanity check. Also sanity check sizes of initial FDE fields.
Yes, this doesn't completely stop the problem since you could place an
insn with a relocated field later in the CIE. If fuzzers find such a
testcase I'll ignore it.
* ehopt.c (struct cie_info): Add "f" field.
(get_cie_info): Return a bool. Verify frag at start of chain
is one with the CIE size found by check_eh_frame.
(check_eh_frame): Save CIE start frag. Only accept 4 or 8
byte fields in state_saw_size, state_saw_cie_offset and
state_saw_pc_begin. Formatting. Localise "fix" variable.
Tom Tromey [Fri, 9 May 2025 19:39:55 +0000 (13:39 -0600)]
Move "show style sources" documentation
I noticed that I had inadvertently put the "set style warning-prefix"
documentation between the paragraph for "set style sources" and the
paragraph for "show style sources". This patch moves the latter up a
bit to clean this up.
Alice Carlotti [Sun, 20 Apr 2025 20:42:39 +0000 (21:42 +0100)]
aarch64: Mark predicate-as-counter pseudo instructions
Using explicit pseudo aliases is clearer and more consistent with other
instruction aliases.
This does not change behaviour. For the non-alias instructions
(everything except mov) we already picked the first matching entry for
disassembly by default. For mov we picked the last matching aliased
entry, which remained the original alias since do_misc_decoding doesn't
recognise OP_MOV_PN_PN.
Alice Carlotti [Thu, 17 Apr 2025 19:42:32 +0000 (20:42 +0100)]
aarch64: Mark clearbhb as a pseudo instruction
This was an early name for the clrbhb hint instruction. Some software
was written with the old name before it was renamed, so we support it
for assembly but should never use it in disassembly.
This patch has no functional change, because we already pick (by
default) the last matching alias in the opcode table, and clrbhb is
listed later than clearbhb.
Alice Carlotti [Sun, 20 Apr 2025 22:02:01 +0000 (23:02 +0100)]
aarch64: Add new test advsimd-copy.d
Only smov and the second dup variant were previously untested. However,
the only test for umov was a disassembly test with -M no-aliases, and
the first dup variant was only tested in assembly in diagnostic.d with
the non-architectural syntax `dup v0.2d, v1.2d[0]`.
Alice Carlotti [Sun, 20 Apr 2025 21:57:53 +0000 (22:57 +0100)]
aarch64: Add new test advsimd-two-reg-misc.d
sqabs, abs, not, mvn, sqneg and neg were already tested, and cmeq was
already assembled in an error test (sve-reg-diagnostic.d), but they are
all included here as part of the same encoding group.
Alice Carlotti [Sun, 20 Apr 2025 16:38:59 +0000 (17:38 +0100)]
aarch64: Add missing widening fmops test
Also remove the valid instructions from the test for invalid
instructions - this meant that the instruction was previously being
tested for assembly but not disassembly.
Alice Carlotti [Mon, 7 Apr 2025 19:21:07 +0000 (20:21 +0100)]
aarch64: Eliminate AARCH64_OPND_SVE_ADDR_R
Adjust parsing for AARCH64_OPND_SVE_ADDR_RR{_LSL*} operands to accept
implicit XZR offsets. Add new AARCH64_OPND_SVE_ADDR_RM{_LSL*} operands
to support instructions where an XZR offset is allowed but must be
specified explicitly. This allows the removal of the duplicate opcode
table entries using AARCH64_OPND_SVE_ADDR_R.
Alice Carlotti [Tue, 8 Apr 2025 16:30:39 +0000 (17:30 +0100)]
aarch64: Disallow invalid SVE addressing modes
The fix for PR22988 in 2018 added a new operand AARCH64_OPND_SVE_ADDR_R
to support implicit XZR offsets, but this fix had several flaws that
meant it accepted several invalid addressing modes:
1. The base register type wasn't properly checked when the optional
register offset was omitted. This meant that
ldff1b {z1.s}, p1/z,[z1.d]
was parsed as if it were
ldff1b z1.d, p1/z, [x1.d, xzr].
2. The explicit offset parsing didn't include a shift type, so the new
operand would incorrectly parse
ldff1h{z0.s}, p0/z, [x0, x0]
as if it were
ldff1h{z0.s}, p0/z, [x0, x0, lsl #1].
3. Regardless of the above correctness issues, support for implicit
offsets should have been added by amending the operands in the existing
opcode table entries, instead of adding new duplicate table entires.
Issue 1 can be fixed by using an "if" instead of an "else if" in
parse_operands, while issue 2 can be fixed by failing when the first
condition is false. This patch applies just these two fixes, leaving
issue 3 to be addressed in a subsequent more invasive patch.
The instructions removed from the test sme-5.d are architecturally
invalid. The new tests cover all of the affected ldff1 variants; the
issue also affected SME ZA ld1*/st1* instructions using the same operand
type.
Tsukasa OI [Fri, 9 May 2025 09:34:48 +0000 (17:34 +0800)]
RISC-V: Base for complex extension implications
Thanks to the commit 48558a5e5471 ("RISC-V: Allow nested implications for
extensions"), we can write complex extension implications in theory.
However, to actually do that, we need to pass more information to
check_func.
For example, we want to imply 'Zcf' from 'F' if and only if the 'Zce'
extension is also enabled and XLEN is 32. Passing rps is a way to
enable this.
This commit prepares for such complex extension implications.
The augmented hypervisor extension 'sha'[1] is a new profile-defined extension
that captures the full set of features that are mandated to be supported along
with the H extension.
* NEWS: New extension.
* testsuite/gas/riscv/imply.d: New test for sha.
* testsuite/gas/riscv/imply.s: Ditto.
* testsuite/gas/riscv/march-help.l: New extension.
* cpu-riscv.c: New option.
* cpu-riscv.h (enum riscv_spec_class): Ditto.
binutils/ChangeLog:
* doc/binutils.texi: New option.
gas/ChangeLog:
* NEWS: Add priv-1.13 support.
* config/tc-riscv.c: New option.
* configure: Ditto.
* configure.ac: Ditto.
* testsuite/gas/riscv/csr-version-1p10.d: New CSR.
* testsuite/gas/riscv/csr-version-1p10.l: New warning.
* testsuite/gas/riscv/csr-version-1p11.d: New CSR.
* testsuite/gas/riscv/csr-version-1p11.l: New warning.
* testsuite/gas/riscv/csr-version-1p12.d: New CSR.
* testsuite/gas/riscv/csr-version-1p12.l: New warning.
* testsuite/gas/riscv/csr.s: New CSR.
* testsuite/gas/riscv/attribute-15.d: New test.
* testsuite/gas/riscv/attribute-16.d: New test.
* testsuite/gas/riscv/csr-version-1p13.d: New test.
* testsuite/gas/riscv/csr-version-1p13.l: New test.
include/ChangeLog:
* opcode/riscv-opc.h (CSR_MEDELEGH): New CSR.
(CSR_HEDELEGH): Ditto.
(DECLARE_CSR): Ditto.
Tom Tromey [Sat, 19 Apr 2025 18:40:18 +0000 (12:40 -0600)]
Move substitute_path_component
This moves substitute_path_component out of utils.c. I considered
making a new file for this (still could if someone wants that), but
since the only caller is in auto-load.c, I moved it there instead.
I've also moved the tests into auto-load.c as well. This way
substitute_path_component can be static.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Wed, 7 May 2025 23:50:23 +0000 (09:20 +0930)]
windres: buffer overflow
bin_to_res_menuexitems can be called with random data offsets (and thus
remaining lengths), confusing code that expects 4-byte aligned data.
Prevent an item length adjustment for alignment exceeding the
remaining length and then overflowing.
Tom Tromey [Sun, 4 May 2025 14:39:15 +0000 (08:39 -0600)]
Remove kfail from templates.exp
templates.exp has one remaining kfail. However, the output in
question has been stabilized ever since the cp-name-parser.y work --
the test just wasn't updated.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8617 Reviewed-By: Keith Seitz <keiths@redhat.com>
This change was causing unexpected mappings to be included in the core
files generated by GDB, which was triggering warnings when GDB opened
a core file, like this:
warning: Can't open file [stack] during file-backed mapping note processing
warning: Can't open file [vvar] during file-backed mapping note processing
For now I'm reverting the above commit and will come to the list again
when I have a solution that addresses the original issue without also
including the unexpected mappings.
Tom Tromey [Fri, 18 Apr 2025 15:28:13 +0000 (09:28 -0600)]
Handle field with dynamic bit offset
I discovered that GCC emitted incorrect DWARF for the test case
included in this patch. Eric wrote a fix for GCC, but then he found
that gdb crashed on the resulting file.
This test has a field that is at a non-constant bit offset from the
start of the type. DWARF 5 does not allow for this situation (I've
sent a report to the DWARF list), but DWARF 3 did allow for this via a
combination of an expression for the byte offset and then the use of
DW_AT_bit_offset. This looks like:
Now, that combination is not fully general, in that the bit offset
must be a constant -- only the byte offset may really vary. However,
I couldn't come up with a situation where full generality is needed,
mainly because GNAT won't seem to pack fields into the padding of a
variable-length array.
Meanwhile, the reason for the gdb crash is that the code handling
DW_AT_bit_offset assumes that the byte offset is a constant. This
causes an assertion failure.
This patch arranges for DW_AT_bit_offset to be applied during field
resolution, when needed.
Tom Tromey [Fri, 18 Apr 2025 14:54:52 +0000 (08:54 -0600)]
Introduce apply_bit_offset_to_field helper function
This patch makes a new function, apply_bit_offset_to_field, that is
used to handle the logic of DW_AT_bit_offset. Currently there is just
a single caller, but the next patch will change this.
Tom Tromey [Fri, 18 Apr 2025 14:22:24 +0000 (08:22 -0600)]
Use OBSTACK_ZALLOC when allocating batons
I found some places in dwarf2/read.c that allocate a location baton,
but fail to initialize one of the fields. It seems safer to me to use
OBSTACK_ZALLOC here, so this patch makes this change. This will be
useful in a subsequent patch as well, where a new field is added to
one of the batons.
Tom Tromey [Thu, 17 Apr 2025 20:48:24 +0000 (14:48 -0600)]
Clean up handle_member_location
This removes a redundant check from handle_member_location, and also
changes the complaint -- currently it will issue the "complex
location" complaint, but really what is happening here is an
unrecognized form.
Tom Tromey [Tue, 15 Apr 2025 15:08:52 +0000 (09:08 -0600)]
Handle dynamic field properties
I found a situation where gdb could not properly decode an Ada type.
In this first scenario, the discriminant of a type is a bit-field.
PROP_ADDR_OFFSET does not handle this situation, because it only
allows an offset -- not a bit-size.
My original approach to this just added a bit size as well, but after
some discussion with Eric Botcazou, we found another failing case: a
tagged type can have a second discriminant that appears at a variable
offset.
So, this patch changes this code to accept a general 'struct field'
instead of trying to replicate the field-finding machinery by itself.
This is handled at property-evaluation time by simply using a 'field'
and resolving its dynamic properties. Then the usual field-extraction
function is called to get the value.
Because the baton now just holds a field, I renamed PROP_ADDR_OFFSET
to PROP_FIELD.
The DWARF reader now defers filling in the property baton until the
fields have been attached to the type.
Finally, I noticed that if the discriminant field has a biased
representation, then unpack_field_as_long would not handle this
either. This bug is also fixed here, and the test case checks this.
Tom Tromey [Wed, 16 Apr 2025 20:58:06 +0000 (14:58 -0600)]
Add resolve_dynamic_field
The final patch in this series will change one dynamic property
approach to use a struct field rather than an offset and a field type.
This is convenient because the reference in DWARF is indeed to a field
-- and this approach lets us reuse the field-extraction logic that
already exists in gdb.
However, the field in question may have dynamic properties which must
be resolved before it can be used. This patch prepares for this by
introducing a separate resolve_dynamic_field function.
This patch should cause no visible changes to behavior.
Tom Tromey [Wed, 16 Apr 2025 21:18:43 +0000 (15:18 -0600)]
Constify property_addr_info
This changes most places to use a const property_addr_info. This
seems more correct to me because normally the user of a
property_addr_info should not modify it. Furthermore, some functions
already take a const object, and for a subsequent patch it is
convenient if other functions do as well.
Lancelot SIX [Tue, 6 May 2025 10:39:55 +0000 (11:39 +0100)]
gdb/testsuite: Add require allow_hipcc_tests in gdb.rocm/mi-attach.exp
The gdb.rocm/mi-attach.exp test is missing a proper `require` check to
ensure that the current configuration can run ROCm tests. This issue
has been reported by Baris.
This patch adds the missing `allow_hipcc_tests` requirement, and also
adds `load_lib rocm.exp` to enable this test.
Change-Id: Ie136adfc2d0854268b92af5c4df2dd0334dce259 Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 11 Mar 2025 14:12:45 +0000 (14:12 +0000)]
gdb: support zero inode in generate-core-file command
It is possible, when creating a shared memory segment (i.e. with
shmget), that the id of the segment will be zero.
When looking at the segment in /proc/PID/smaps, the inode field of the
entry holds the shared memory segment id.
And so, it can be the case that an entry (in the smaps file) will have
an inode of zero.
When GDB generates a core file, with the generate-core-file (or its
gcore alias) command, the shared memory segment should be written into
the core file.
Fedora GDB has, since 2008, carried a patch that tests this case.
There is no fix for GDB associated with the test, and unfortunately,
the motivation for the test has been lost to the mists of time. This
likely means that a fix was merged upstream without a suitable test,
but I've not been able to find and relevant commit. The test seems to
be checking that the shared memory segment with id zero, is being
written to the core file.
While looking at this test and trying to work out if it should be
posted upstream, I saw that GDB does appear to write the shared memory
segment into the core file (as expected), which is good. However, GDB
still isn't getting this case exactly right.
In gcore_memory_sections (gcore.c) we call back into linux-tdep.c (via
the gdbarch_find_memory_regions call) to correctly write the shared
memory segment into the core file, however, in
linux_make_mappings_corefile_notes, when we use
linux_find_memory_regions_full to create the NT_FILE note, we call
back into linux_make_mappings_callback for each mapping, and in here
we reject any mapping with a zero inode.
The result of this, is that, for a shared memory segment with a
non-zero id, after loading the core file, the shared memory segment
will appear in the 'proc info mappings' output. But, for a shared
memory segment with a zero id, the segment will not appear in the
'proc info mappings' output.
I propose fixing this by not checking the inode in
linux_make_mappings_callback. The inode check was in place since the
code was originally added in commit 451b7c33cb3c9ec6272c36870 (in
2012).
The test for this bug, based on the original Fedora patch, can be
found on the mailing list here:
I have not committed this test into the tree though because the test
was just too unreliable. User space doesn't have any control over the
shared memory id, so all we can do is spam out requests for new shared
memory segments and hope that we eventually get the zero id.
Obviously, this can fail; the zero id might already be in use by some
long running process, or the kernel, for whatever reason, might choose
to never allocate the zero id. The test I posted (see above thread)
did work more than 50% of the time, but it was far closer to a 50%
success rate than 100%, and I really don't like introducing unreliable
tests.
Add a new gcore_cmd_available predicate proc that can be used in a
'requires' line, and make use of it in a few tests.
All of the tests I have modified call gdb_gcore_cmd as one of their
first actions and exit if the gcore command is not available, so it
makes sense (I think) to move the gcore command check into a requires
call.
There should be no change in what is actually run after this commit.
Andrew Burgess [Tue, 29 Apr 2025 16:57:06 +0000 (17:57 +0100)]
gdb/python/guile: check if styling is disabled in Color.escape_sequence
I noticed that the gdb.Color.escape_sequence() method would produce an
escape sequence even when styling is disabled.
I think this is the wrong choice. Ideally, when styling is
disabled (e.g. with 'set style enabled off'), GDB should not be
producing styled output.
If a GDB extension is using gdb.Color to apply styling to the output,
then currently, the extension should be checking 'show style enabled'
any time Color.escape_sequence() is used. This means lots of code
duplication, and the possibility that some locations will be missed,
which means disabling styling no longer does what it says.
I propose that Color.escape_sequence() should return the empty string
if styling is disabled. A Python extension can then do:
python
c_none = gdb.Color('none')
c_red = gdb.Color('red')
print(c_red.escape_sequence(True)
+ "Text in red."
+ c_none.escape_sequence(True))
end
If styling is enable this will print some red text. And if styling is
disabled, then it will print text in the terminal's default color.
Alan Modra [Tue, 6 May 2025 05:21:31 +0000 (14:51 +0930)]
gas: input_scrub buffers
This tidies freeing of input_scrub buffers on failure paths, making
input_scrub_end iterate over any input_scrub_push'd files or string
buffers to clean up memory.
* input-scrub.c (input_scrub_free): New function.
(input_scrub_pop): Call it rather than input_scrub_end.
(input_scrub_end): Iterate over next_saved_file freeing
buffers.
(input_scrub_next_buffer): Move sb_kill to input_scrub_free.
Alan Modra [Fri, 2 May 2025 03:12:32 +0000 (12:42 +0930)]
windres_get_* functions
windres_get_32 and similar have a length parameter that in most cases
is just the required length, so it is redundant. The few cases where
a variable length is passed are all in resrc.c. So, get rid of the
length parameter and introduce wrappers in resrc.c to check the
length.
Tom Tromey [Fri, 2 May 2025 17:03:07 +0000 (11:03 -0600)]
Fix sign of Ada rational constants
My earlier patch commit 0c03db90 ("Use correct sign in get_mpz") was
(very) incorrect. It changed get_mpz to check for a strict sign when
examining part of an Ada rational constant. However, in Ada the
"delta" for a fixed-point type must be positive, and so the components
of the rational representation will be positive.
This patch corrects the error. It also renames the get_mpz function,
in case anyone is tempted to reuse this code for another purpose.
Finally, this pulls over the test from the internal AdaCore test suite
that found this issue.
class Reloc is not used after commit 13f614be23a gprofng: Refactor readSymSec for using BFD's asymbol struct
Many common macros were defined in different sources.
Sometimes a macro was used, sometimes a macros value was used.
Removed unused macros and include files.
gprofng/ChangeLog
2025-05-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* common/gp-experiment.h: Define variables that are passed to
libcollector. Remove unused macros.
* libcollector/collector.c: Cleanup macros.
* libcollector/descendants.h: Likewise.
* libcollector/envmgmt.c: Likewise.
* libcollector/linetrace.c: Likewise.
* src/collect.h: Likewise.
* src/envsets.cc: Likewise.
* src/gp-collect-app.cc: Likewise.
* src/Stabs.cc: Remove class Reloc.
* src/Stabs.h: Likewise.
* src/ipcio.cc: Remove unused include files.
On x86_64-cygwin, with test-case gdb.tui/tui-layout-asm.exp I run into:
...
WARNING: The following failure is probably due to the TUI window
width. See the comments in the test script for more
details.
FAIL: $exp: scroll to end of assembler (scroll failed)
...
The problem is as follows.
On the TUI screen, we have:
1 | 0x1004010ff <__gdb_set_unbuffered_output+95> nop |
2 | 0x100401100 <__cxa_atexit> jmp *0x6fc2(%rip) # 0x10040 |
...
We send the down key, which should have the effect of scrolling up. So, we
expect that the second line moves to the first line.
That seems to be the case indeed:
...
1 | 0x100401100 <__cxa_atexit> jmp *0x6fc2(%rip) # 0x1004080c8 <__imp___cxa_ |
...
but the line has changed somewhat, so the matching fails.
We could increase the width of the screen, as suggested in the test-case, but
I think that approach is fragile.
Instead, fix this by relaxing the matching: just check that the line before
scrolling is fully contained in the line after scrolling, or the other way
around.
Doing so gets us the next failure:
...
FAIL: $exp: scroll to end of assembler (too much assembler)
...
The test-case states:
...
if { $down_count > 250 } {
# Maybe we should accept this as a pass in case a target
# really does have loads of assembler to scroll through.
fail "$testname (too much assembler)"
...
and I agree, so fix this by issuing a pass.
This results in the test-case taking ~20 seconds, so reduce the maximum number
of scrolls from 250 to 25, bringing that down to ~10 seconds.
Tom de Vries [Fri, 2 May 2025 20:21:36 +0000 (22:21 +0200)]
[gdb/symtab] Throw DWARF error on out-of-bounds DW_FORM_strx
With the test-case contained in the patch, and gdb build with
-fsanitize=address we get:
...
==23678==ERROR: AddressSanitizer: heap-buffer-overflow ...^M
READ of size 1 at 0x6020000c30dc thread T3^[[1m^[[0m^M
ptype global_var^M
#0 0x2c6a40b in bfd_getl32 bfd/libbfd.c:846^M
#1 0x168f96c in read_str_index gdb/dwarf2/read.c:15349^M
...
The executable contains an out-of-bounds DW_FORM_strx attribute:
...
$ readelf -wi $exec
<2eb> DW_AT_name :readelf: Warning: string index of 1 converts to \
an offset of 0xc which is too big for section .debug_str
(indexed string: 0x1): <string index too big>
...
and read_str_index doesn't check for this:
...
info_ptr = (str_offsets_section->buffer
+ str_offsets_base
+ str_index * offset_size);
if (offset_size == 4)
str_offset = bfd_get_32 (abfd, info_ptr);
...
and consequently reads out-of-bounds.
Fix this in read_str_index by checking for the out-of-bounds condition and
throwing a DWARF error:
...
(gdb) ptype global_var
DWARF Error: Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing \
outside of .debug_str_offsets section in CU at offset 0x2d7 \
[in module dw-form-strx-out-of-bounds]
No symbol "global_var" in current context.
(gdb)
...
projects / thirdparty / binutils-gdb.git / log
