Tom de Vries [Tue, 17 Feb 2026 18:20:50 +0000 (19:20 +0100)]
[gdb/testsuite] Fix some incorrect uses of decimal
Dejagnu defines $decimal as:
...
set decimal "\[0-9\]+"
...
If we add an equivalent definition in lib/gdb.exp:
...
set decimal "(?:\[0-9\]+)"
...
we run into this type of ERRORs:
...
couldn't compile regular expression pattern: parentheses () not balanced
...
This is due to using "\[$decimal\]" instead of "\\\[$decimal\\]" or
"[subst_var {\[$decimal\]}]".
Add such definitions of decimal and hex, and apply the same technique to
positive and octal.
Kevin Buettner [Thu, 29 Jan 2026 22:09:24 +0000 (15:09 -0700)]
gcore: Handle unreadable pages within readable memory regions
GLIBC 2.42 changed how thread stack guard pages are implemented [2].
In GLIBC 2.41 and earlier, guard pages were set up using mprotect() to
mark guard regions with no permissions. Once configured, guard pages
were visible as separate entries in /proc/PID/maps with no permissions
(i.e. they're inaccessible). In GLIBC 2.42, guard pages are
installed using the kernel's MADV_GUARD_INSTALL mechanism [1], which
marks them at the page table entry (PTE) level within the existing
mapping.
As a consequence, guard pages do not appear as separate entries in
/proc/PID/maps, but remain as part of the containing mapping. Moreover,
thread stacks from multiple mmap() calls may be merged into a single
virtual memory area (VMA) with read and write permissions since there's
no guard page VMA to separate them. These guard pages cannot be
distinguished by examining VMA listings but do return EIO when read
from /proc/PID/mem.
GDB's gcore code reads /proc/PID/smaps to discover memory regions and
creates one BFD section per mapping. (On linux, this is performed in
linux_find_memory_regions_full in linux-tdep.c.) With the old layout,
memory areas with guard pages appeared separately with no permissions,
which were filtered out. Each thread stack became its own section
containing only readable data. With the new layout, using
MADV_GUARD_INSTALL instead of the older mechanism, it's often the case
that thread stacks created with multiple calls to mmap() are exposed
as a single mapping appearing in /proc/PID/smaps with read and write
permissions. Should that happen, GDB's code creates a single section
covering all thread stacks and their guard pages. (Even if each
thread stack appears in its own mapping, the fact remains that there
will be an inaccessible portion of the mapping. When one or more
thread stacks are coalesced into a single mapping, there will be
several inaccessible "holes" representing the guard pages.)
When gcore_copy_callback copies section contents, it reads memory in
1MB (MAX_COPY_BYTES) chunks. If any page in the chunk is a guard page,
the call to target_read_memory() fails. The old code responded by
breaking out of the copy loop, abandoning the entire section. This
prevents correct copying of thread stack data, resulting in core files
with zero-filled thread stacks, resulting in nearly empty backtraces.
Fix this by falling back to page-by-page reading when a 1MB chunk read
fails. Individual pages that cannot be read are filled with zeros,
allowing the remaining readable memory to be captured.
I also considered a simpler change using the value of
FALLBACK_PAGE_SIZE (4096) as the read size instead of MAX_COPY_BYTES
(1MB). This would avoid the fallback logic but would cause up to 256x
more syscalls. The proposed approach also allows meaningful warnings:
we warn only if an entire region is unreadable (indicating a real
problem), whereas per-page reads would make it harder to distinguish
guard page failures from actual errors. Since guard pages are at
offset 0 for downward-growing stacks, a large target_read_memory()
fails early at the first unreadable byte anyway.
With this fix, I see 16 failures resolved in the following test cases:
Looking at just one of these, from gdb.log without the fix, I see:
thread apply 5 backtrace
Thread 5 (LWP 3414829):
#0 0x00007ffff7d1d982 in __syscall_cancel_arch () from /lib64/libc.so.6
#1 0x0000000000000000 in ?? ()
(gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: thread apply 5 backtrace
And this is what it looks like with the fix in place (some paths have
been shortened):
thread apply 5 backtrace
Thread 5 (Thread 0x7fffeffff6c0 (LWP 1282651) "threadcrash"):
#0 0x00007ffff7d1d982 in __syscall_cancel_arch () from /lib64/libc.so.6
#1 0x00007ffff7d11c3c in __internal_syscall_cancel () from /lib64/libc.so.6
#2 0x00007ffff7d61b62 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6
#3 0x00007ffff7d6db37 in nanosleep () from /lib64/libc.so.6
#4 0x00007ffff7d8008e in sleep () from /lib64/libc.so.6
#5 0x00000000004006a8 in do_syscall_task (location=NORMAL) at threadcrash.c:158
#6 0x0000000000400885 in thread_function (arg=0x404340) at threadcrash.c:277
#7 0x00007ffff7d15464 in start_thread () from /lib64/libc.so.6
#8 0x00007ffff7d985ac in __clone3 () from /lib64/libc.so.6
(gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior: thread apply 5 backtrace
Regression testing on Fedora 42 (glibc 2.41) shows no new failures.
The v1 patch used SPARSE_BLOCK_SIZE as the fallback size. While it
was the correct size, it's used for an entirely different purpose
elsewhere in this file. This v2 commit introduces the constant
FALLBACK_PAGE_SIZE instead.
Tom de Vries [Tue, 17 Feb 2026 14:45:23 +0000 (15:45 +0100)]
[gdb/doc] Improve info line command documentation
The "info line" command can be used with or without arguments.
About using it without arguments, the documentation [1] says the following:
...
info line
With no locspec, information about the current source line is printed.
...
After info line, using info line again without specifying a location will
display information about the next source line.
...
That does not describe the fact that the command may also show the last line
listed:
...
(gdb) info line
No line number information available.
(gdb) list main
20 #include "interps.h"
21 #include "run-on-main-thread.h"
22
23 int
24 main (int argc, char **argv)
25 {
26 /* The first call to is_main_thread () should be from the main thread.
27 If this is the first call, then that requirement is fulfilled here.
28 If this is not the first call, then this verifies that the first call
29 fulfilled that requirement. */
(gdb) info line
Line 29 of "gdb/gdb.c" is at address 0x419684 <main(int, char**)+30>
but contains no code.
(gdb)
...
Update the documentation to list this additional functionality.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33783
Tom de Vries [Tue, 17 Feb 2026 14:31:32 +0000 (15:31 +0100)]
[gdb/build] Require makeinfo 5.0
Building GDB documentation in the info format requires makeinfo 5.0 [1].
Bail out when trying to use an older makeinfo version.
I tested this by requiring 7.0 in two setups that have respectively makeinfo
7.1 and 6.5.
In the 7.1 case I got (make output):
...
makeinfo-wrapper.sh 7 0 makeinfo ... -o gdb.info gdb/doc/gdb.texinfo
makeinfo-wrapper.sh 7 0 makeinfo ... -o annotate.info gdb/doc/annotate.texinfo
rluser.texi:2: warning: @setfilename after the first element
...
and in the 6.5 case I got instead:
...
makeinfo-wrapper.sh 7 0 makeinfo ... -o gdb.info gdb/doc/gdb.texinfo
makeinfo-wrapper.sh 7 0 makeinfo ... -o annotate.info gdb/doc/annotate.texinfo
makeinfo is too old, have 6.5, require 7.0. Info documentation will not be build.
makeinfo is too old, have 6.5, require 7.0. Info documentation will not be build.
...
Checked new file gdb/doc/makeinfo-wrapper.sh with shellcheck.
Changes in v2:
- handle version line 'texi2any (GNU texinfo) 7.2.90+nc'
Changes in v3:
- handle version line 'texi2any (GNU texinfo) 5.0+dev'
LD/testsuite: Enable execution with remote targets
Lift target execution limitation from `run_ld_link_exec_tests' procedure
and also handle remote targets, albeit in a restricted way, as follows.
Numerous test cases have been written such that they refer to a shared
library using a relative path, precluding the use of the runtime library
search path for the dependency to be found at run time. Consequently a
test affected has to be run on the target such that the shared library
required is present at the same relative path rooted at the program's
current working directory.
Additionally any shared library dependencies are not handled across the
test suite in an organised way, so test invocations only have names of
direct dependencies buried within the linker options supplied.
Therefore assert that the linker test directory is located at the same
absolute path both on the test host and the test target, typically via
sharing the directory over NFS, and use the DejaGNU `remotedir' feature
to start execution on the target with that location as the test case's
current working directory.
Complementing `check_compiler_available' procedure for a compilation
check implement `check_execution_available' that checks whether an
executable built the same way can actually successfully run on the
target.
LD/testsuite: Factor out compilation of a dummy executable
There is a dummy executable compiled for the purpose of determining
whether a target compiler is available that can produce a runnable
program. This is now going to be also used to determine whether a
program produced this way can be executed on the target, so take the
relevant pieces from `check_compiler_available' procedure and factor
them out to `make_dummy_target_executable' procedure leaving the
executable produced in place and returning its name upon successful
compilation. This executable needs to be discarded by the caller once
no longer needed. No functional change overall.
Alan Modra [Mon, 16 Feb 2026 23:29:37 +0000 (09:59 +1030)]
gas: abort in new_logical_line_flags
.linefile 0.
hits the "case 1 << 3" abort in new_logical_line_flags with line_number
of -1.
Similar to commit b60f6a628897, this fixes the abort by extending the
meaning of .linefile in user code to restore the physical line for
".linefile 0 .".
* input-scrub.c (new_logical_line_flags <case 1<<3>): Don't
abort on negative line number, instead restore physical line
for ".linefile 0".
Alan Modra [Mon, 16 Feb 2026 23:29:13 +0000 (09:59 +1030)]
gas: macros nested too deep error
.macro r;r;.endm;r
Currently reports:
nest.s: Assembler messages:
nest.s:2: Fatal error: macros nested too deeply
nest.s:2: Info: macro invoked from here
nest.s:2: Info: macro invoked from here
...
nest.s:2:<much indenting> Info: macro invoked from here
nest.s:1:<much indenting> Info: macro invoked from here
This patch corrects the line number reported, and downgrades the error
from as_fatal to as_bad.
* input-scrub.c (input_scrub_include_sb): Report "macros
nested too deeply" using as_bad.
* macro.c (buffer_and_nest): Only bump line number in .lineinfo
if we have a '\n'.
Alan Modra [Mon, 16 Feb 2026 23:27:52 +0000 (09:57 +1030)]
gas: further limit .rept count
gas currently limits a rept count at 0x7fffffff. With a minimal rept
body this requires at least 2G * 16 due to the .linefile directive
added by buffer_and_nest. I'm inclined to think 32G is excessive.
This patch limits the total memory used by rept to 4G (2G on 32-bit
systems). That of course reduces allowed repeat counts by a factor of
at least 8, and note that the file name affects the max repeat.
The patch also changes the repeat count to 1 rather than 0 when
we hit the limit, so that the body of the rept is not entirely ignored.
Nested rept can still easily cause OOM of course.
* read.c (do_repeat): Limit allowed repeat count based on
total memory needed.
Tom Tromey [Tue, 27 Jan 2026 03:49:26 +0000 (20:49 -0700)]
Don't use .debug_names if .debug_aranges is missing
gdb's .debug_names reader depends on .debug_aranges as well, because
if the ranges are missing, it won't be able to create a map from PC to
CU.
However, this requirement isn't enforced by gdb. I no longer recall
know why, but I can see in commit b371f07c ("Rewrite .debug_names
reader") that I made this choice on purpose:
In v1 of this patch, I made the new reader more strict about requiring
.debug_aranges. In v2, I've backed this out and kept the previous
logic. This solved a few test failures, though it's arguably not the
right approach.
However, the current setup now seems clearly incorrect to me. And, it
was causing problems for another patch I'm working on.
Fixing this required patching a few tests to add a .debug_aranges
section. I've also updated the intro comment to
read_addrmap_from_aranges to reflect how it ought to be used.
Regression tested on x86-64 Fedora 41 with both the default and the
cc-with-debug-names target boards.
Matthew Lugg [Fri, 6 Feb 2026 12:27:16 +0000 (12:27 +0000)]
gdb/dwarf2: skip unrecognised extended opcodes in line-number programs
Although the DWARF 5 specification does not outright state that
consumers should ignore unrecognised opcodes, it does make sure that
this is possible (by always encoding the length of operands), and in
fact states the following:
> The DWARF format is organized so that a consumer can skip over data
> which it does not recognize. This may allow a consumer to read and
> process files generated according to a later version of this standard
> or which contain vendor extensions, albeit possibly in a degraded
> manner.
In addition, it is mentioned in the body of DWARF Issue 180426.2 that
producers can, today, include padding bytes in line number programs by
emitting an unused extended opcode:
> In a related thread on dwarf-discuss, Cary pointed out that given how
> DWARF works, any undefined extended opcode could be used for this
> purpose. [...] consumers already know how to skip an unrecognized
> extended opcode.
Previously, if GDB encountered an unknown extended opcode in a DWARF
line number program, it would stop evaluating the program with an error.
This commit causes it to instead skip the extended opcode, leaving the
virtual machine state unmodified. As well as being supported by the
quotes above, this is consistent with GDB's *existing* handling of the
case where a *standard* LNP opcode is unrecognised.
The motivation for this change is binaries emitted by the Zig compiler,
which currently uses extended opcode 0 for padding bytes (the use case
being addressed in DWARF 6 by the DWARF issue referenced above). LLDB is
capable of parsing these line number programs, but GDB was not prior to
this commit.
Tested by running the test suite (including the added test case) and
confirming that every test which previously passed continues to pass.
Also manually tested on a binary produced by the Zig compiler, where
previously GDB was missing some line number information, but now has
complete and correct information.
Simon Marchi [Fri, 13 Feb 2026 19:17:40 +0000 (14:17 -0500)]
binutils: fix C23 -Wdiscarded-qualifiers errors
When compiling with gcc 15, I get these:
CC prdbg.o
/home/simark/src/binutils-gdb/binutils/prdbg.c: In function ‘tg_start_function’:
/home/simark/src/binutils-gdb/binutils/prdbg.c:2658:11: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
2658 | sep = strchr (name, '(');
| ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:1220: prdbg.o] Error 1
CC addr2line.o
/home/simark/src/binutils-gdb/binutils/addr2line.c: In function ‘translate_addresses’:
/home/simark/src/binutils-gdb/binutils/addr2line.c:390:21: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
390 | h = strrchr (filename, '/');
| ^
cc1: all warnings being treated as errors
make[2]: *** [Makefile:1220: addr2line.o] Error 1
CC nm.o
/home/simark/src/binutils-gdb/binutils/nm.c: In function ‘print_symname’:
/home/simark/src/binutils-gdb/binutils/nm.c:689:21: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
689 | char *atver = strchr (name, '@');
| ^~~~~~
cc1: all warnings being treated as errors
I think they are related to the fact that strchr having changed to
return const when passed a const.
Tom Tromey [Tue, 10 Feb 2026 14:47:42 +0000 (07:47 -0700)]
Handle fixed-point types in amd64_classify
gdb.ada/fixed_points_function.exp was failing when compiled with
gnat-llvm. Debugging showed that this was a gdb bug that was hidden
by differences in the DWARF generated by gcc and gnat-llvm.
In particular, gcc emitted a DW_TAG_subrange_type (a subrange of the
fixed-point type) for the function's parameter type, whereas gnat-llvm
used a fixed-point type directly.
Then, the test failed because amd64_classify recognizes subrange types
but not fixed-point types. Under the hood, fixed-point types are
really just integers, so the fix is to handle these directly in
amd64_classify.
Approved-By: Christina Schimpe <christina.schimpe@intel.com>
Simon Marchi [Mon, 26 Jan 2026 06:15:19 +0000 (01:15 -0500)]
gdb/dwarf: fix DW_OP_call{2,4} in .dwo files
Bug 31772 shows a failure of gdb.ada/finish-var-size.exp when ran with
the fission board, modified to generate DWARF 5. Ultimately, the
problem shows up when executing a DW_OP_call{2,4} operation from a .dwo
file.
The DW_OP_call{2,4} ops receive a CU-relative offset. Function
dwarf2_fetch_die_loc_cu_off receives that offset and transforms it in a
section-relative offset by adding the section offset of the containing
CU:
The problem is that `per_cu->sect_off ()` returns the offset of the
skeleton CU in the main file, when what we really want is the offset of
the split unit in the .dwo file.
To obtain that, we need to get the loaded CU (dwarf2_cu), from which we
can know if the DIEs were actually read from a .dwo file or not. And if
so, get the section offset of the dwo unit, rather than the skeleton
unit.
Calling load_cu here does not have a negative performance impact, because
it would be called by dwarf2_fetch_die_loc_sect_off anyway.
Add a section_offset method to dwarf2_cu to get the effective section
offset of the unit. This mirrors what we do for the section in
dwarf2_cu::section.
Add a test that reproduces this exact case.
GDB does not support DW_OP_call_ref, so don't test that. It would also
be unexpected anyway to have cross-unit references in a .dwo file (but
no completely unthinkable, given we support having multiple CUs in a .dwo
file).
Change-Id: If5faac252b32ed9751d29681590b668225708275
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31772 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 9 Feb 2026 19:15:00 +0000 (14:15 -0500)]
gdb: use gdb::unordered_string_map throughout
Change all uses of
gdb::unordered_map<string, T>
to
gdb::unordered_string_map<T>
Using unordered_string_map avoids constructing a temporary std::string
(possibly with dynamic allocation) when looking up values from
`const char *`.
I don't see any downsides to using unordered_string_map over
unordered_map, even if all the lookups are done using existing
std::string objects that would be built anyway.
I think there are places where we could refactor the code to avoid
constructing unnecessary std::string objects, but that is out of scope
for this patch.
There should be no change of behavior with this patch.
Change-Id: Ic4df78b97f2755d5821bb66942b9e4d9a79a3dc5 Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Mon, 9 Feb 2026 19:17:53 +0000 (14:17 -0500)]
gdbsupport: add gdb::unordered_string_map
It occurred to me that when we use a
gdb::unordered_map<std::string, T>
we construct a temporary std::string for each lookup from a
`const char *`, possibly doing dynamic allocation. This is really
unnecessary, because it's easy to compare an existing `const char *` (or
std::string_view) with an std::string. This can therefore be avoided by
having transparent hash and eq types.
Because this is a common enough case, add it to
gdbsupport/unordered_map.h, so it can easily be reused. Define the
gdb::unordered_string_map type, which uses hash and eq types that work
on std::string_view. Both `const char *` and `std::string` can
implicitly be converted to std::string_view, so this should be
sufficient.
Change-Id: Id93448d831696d25472f13c15212f13712ad8492 Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Fri, 13 Feb 2026 03:47:37 +0000 (22:47 -0500)]
gdb/elfread: add debug output for GNU ifunc resolution
Add some debug prints throughout the ifunc resolution code, to be able
to better understand what GDB does. Add the new "set debug gnu-ifunc"
knob to control it.
Add the debug_prefixed_printf_cond_func macro to implement
gnu_ifunc_debug_printf_func, that takes an explicit function name. This
is needed to avoid showing "operator()" as the function name in the
debug message.
Here is a sample session with the new debug output enabled.
(gdb) b the_function
[gnu-ifunc] elf_gnu_ifunc_resolve_name: resolving name "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolve_by_cache: resolving "the_function" by cache
[gnu-ifunc] elf_gnu_ifunc_resolve_by_cache: cache miss for "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: resolving "the_function" by GOT
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: GOT entry "the_function@got.plt" points to 0x7ffff7fb7036
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fb7036
[gnu-ifunc] elf_gnu_ifunc_record_cache: minimal symbol "the_function@plt" at 0x7ffff7fb7030 does not match addr 0x7ffff7fb7036, not caching
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: GOT entry "the_function@got.plt" points to 0x7ffff7fb2036
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fb2036
[gnu-ifunc] elf_gnu_ifunc_record_cache: minimal symbol "the_function@plt" at 0x7ffff7fb2030 does not match addr 0x7ffff7fb2036, not caching
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: failed to resolve "the_function" by GOT
[gnu-ifunc] elf_gnu_ifunc_resolve_name: failed to resolve name "the_function"
Breakpoint 2 at gnu-indirect-function resolver at 0x7ffff7fa80e9
(gdb) c
Continuing.
[gnu-ifunc] elf_gnu_ifunc_resolver_stop: stop on resolver for "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolver_stop: created resolver return breakpoint at 0x7ffff7fd7186
[gnu-ifunc] elf_gnu_ifunc_resolver_return_stop: stop on resolver return
[gnu-ifunc] elf_gnu_ifunc_resolver_return_stop: resolver for "the_function" returned resolved address=0x7ffff7fad0e9, resolved pc=0x7ffff7fad0e9
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fad0e9
[gnu-ifunc] elf_gnu_ifunc_record_cache: cached "the_function" -> 0x7ffff7fad0e9 in objfile /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/ifunc-resolver/libimpl.so
Delete the ARM sub-directory of the SIM directory.
the arm simulator was removed from the sim/ directory. GDB has now
been updated to remove its support for the arm simulator, and as a
result, this header file is no longer used by anyone. Lets delete it.
There should be no user visible changes after this commit.
gdb: fix 'info frame' for tail calls with no debug information
And playing with the test binary from that commit in the TUI.
Unlike the problem fixed by this earlier commit, the TUI status bar
function name is wrong for tail call functions both with and without
DWARF.
The problem is in the function tui_get_function_from_frame (in
tui/tui-status.c), which the TUI uses to get the function name that
will be displayed. This function calls print_address_symbolic passing
in the result of a call to get_frame_pc to get the actual function
name.
The problem is that for a tail calls, get_frame_pc will return a pc
outside the current function. Fix this by switching to use the
function get_frame_address_in_block instead.
I wanted the tests for this fix to live in gdb.tui/ as the code being
fixed is very TUI specific. As a result this does mean that the
tailcall-msym.exp test is copied from gdb.base/ (see the earlier
commit), but I don't see this as a huge problem.
There's an additional test that creates a tail call function using the
DWARF assembler, this tests the with DWARF case.
One maybe surprising change in this commit is the one to lib/gdb.exp.
This was needed because of the use of 'runto callee' in the new
tests. As we're running in TUI mode, styling will be enabled in the
output. Now most TUI tests compile "normal" .c files into an
executable with file and line debug information. As a result, when we
hit a breakpoint we see GDB output like:
Breakpoint 1, function () at file.c:25
The pattern that matches this within 'proc runto' (lib/gdb.exp)
uses '.*' to match both the function name and the filename. This
means that the styling escape sequences are also matched.
However, when building the tests added in this commit, which lack file
and line debug information, we get a breakpoint hit line like this:
Breakpoint 1, 0x000000000040110a in callee ()
The pattern in 'proc runto' that matches this uses '[0-9xa-f]*' to
match the hex address string. As a consequence, if the address is
styled, then this pattern no longer matches.
To work around this I've added an optional pattern which should match
any ansi styling escape sequence before and after the address. This
should not cause any problems for unstyled testing, but now allows
this pattern to match if styling is enabled.
Andrew Burgess [Sun, 19 Nov 2023 15:24:59 +0000 (15:24 +0000)]
gdb/gdbserver: move argument setting complexity into gdbsupport/
This commit removes some uses of gdb::argv_vec from GDB.
The gdb::argv_vec class exists in part due to our need to convert from
one container type to another in a few places, and I think by using
templates we can push this conversion down into
gdbsupport/common-inferior.{cc,h} and remove the conversion logic from
higher level code in GDB. This should make core GDB simpler.
For examples of this simplification, see python/py-inferior.c,
remote.c, and unittests/remote-arg-selftests.c, where this commit has
allowed for the removal of some code that only exists in order to
convert the container type.
Ideally I'd like to see all uses of gdb::argv_vec removed, but I'm
still not sure about the use in nat/fork-inferior.c, I think its use
there might be the best solution, so for now at least, I have no plans
to touch that code.
There should be no user visible changes after this commit.
Improve test-case gdb.testsuite/quotemeta.exp by:
- catching errors in check_quotemeta
- logging argument and results of calling quotemeta using verbose -log
- renaming quotemeta_fail to check_quotemeta_fail for consistency with
check_quotemeta
- reducing escaping using {}
- adding a missing test checking "@bad-name"
Tiezhu Yang [Sat, 31 Jan 2026 08:24:07 +0000 (16:24 +0800)]
gdb: Fix unexpected failures in breakpoint-in-ro-region.exp
Currently, there is no support for hardware breakpoints on a virtual
machine of LoongArch. When unseting CONFIG_HAVE_HW_BREAKPOINT of the
Linux kernel, there is also no support for hardware breakpoints on a
physical machine of LoongArch.
For the above cases, when executing:
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.base/breakpoint-in-ro-region.exp"
there are 4 unexpected failures:
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: thread advanced
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: thread advanced
By the way, there are no failures when executing:
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
Here are the gdb log messages if no support for hardware breakpoints:
(1) make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
```
(gdb) hbreak *0x120000628^M
No hardware breakpoint support in the target.^M
(gdb) UNSUPPORTED: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (no support)
si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) UNSUPPORTED: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region (cannot insert hw break)
```
(2) make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.base/breakpoint-in-ro-region.exp"
si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0:Remote failure reply: 01.^M
^M
(gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region
```
The outputs of "hbreak" and "si" commands are different between gdb and
gdbserver, it should check "Cannot insert hardware breakpoint" anyway.
In my opinion, this fix is not only for LoongArch but also for the other
arch that does not support hardware breakpoints. For example, if disable
CONFIG_PERF_EVENTS, then CONFIG_HAVE_HW_BREAKPOINT will be not set due to
select HAVE_HW_BREAKPOINT if PERF_EVENTS
in arch/loongarch/Kconfig of the Linux kernel code, it can reproduce the
unexpected failures.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33845 Co-developed-by: Miao Wang <shankerwangmiao@gmail.com> Signed-off-by: Miao Wang <shankerwangmiao@gmail.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: Tom Tromey <tom@tromey.com>
Tiezhu Yang [Sat, 31 Jan 2026 08:24:06 +0000 (16:24 +0800)]
gdb: Make test result accurate in breakpoint-in-ro-region.exp
Currently, if no support for hardware breakpoints, when executing:
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
the test results of "hbreak" and "si" command are "PASS":
```
(gdb) hbreak *0x120000628^M
No hardware breakpoint support in the target.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (no support)
si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region (cannot insert hw break)
```
This is not accurate, obviously it should be "UNSUPPORTED".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33845 Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 13 Feb 2026 09:19:39 +0000 (10:19 +0100)]
gprof: fix testsuite with older glibc
It is quite sad that 2.46 has again shipped with this breakage. Short of
those responsible taking care, use the workaround that was suggested in
https://sourceware.org/pipermail/binutils/2025-April/140316.html.
Jan Beulich [Fri, 13 Feb 2026 09:19:23 +0000 (10:19 +0100)]
ld: move symlink-ing of ldscripts a little earlier
Following up commit a29a6230b820 "PR 33629 ldscripts symlink in .libs/
created too late", move the symlink-ing ahead of the linking of the final
binary, to eliminate the slim chance of the build being interrupted (or
failing) at that (so far) final step. If that happened, a subsequent make
invocation with no other changes made would then not re-attempt this step.
Necessarily with this the test for the existence of the binary needs to be
removed. Perhaps that shouldn't have been there anyway, the more that the
check was lacking $(EXEEXT).
Tom Tromey [Thu, 5 Feb 2026 20:51:07 +0000 (13:51 -0700)]
Handle wide characters that cannot be converted
The internal AdaCore test suite found a bug with the char-printing
changes: on Windows, it is possible to have a wide character (in our
case, 0xBEEF) that is "printable" (as determined by iswprint) but
which cannot be converted to the current host charset.
This in turn would result in strange output like:
$2 = 48879 '\357\276'
where what we would expect in Ada would be:
$2 = 48879 '["00beef"]'
A similar problem could occur for C on Windows. There, the character
boundaries appeared lost to the user, so rather than '\xbeef' the user
would see '\357\276'.
This patch fixes this problem by checking the convertibility of a wide
character before printing it.
New in v3: Correctly check result of wcrtomb
New in v2: Skip the new check if the host encoding is UTF-8.
However, the test case is constructed so that "Center" has multiple
meanings: it might name the enumerator here:
type Posn is (Left, Center, Right);
or it might refer to this variable:
Center : Pck.Posn := Pck.Right;
The correct answer in this case is to pick the enumerator, because
that is the array's index type.
Originally I didn't fix this problem and instead used a kfail.
However, this same problem turned up again (in a slightly different
form) when the libgnat debuginfo was installed.
This patch fixes the bug by introducing new code in
ada_name_association::assign to handle the enumeration case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33896
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33898 Tested-By: Tom de Vries <tdevries@suse.de>
Jens Remus [Thu, 12 Feb 2026 12:44:01 +0000 (13:44 +0100)]
s390: Simplify linker libgot-1 tests
This applies Alan's x86 commit df865c395a62 ("libgot-1 testcases")
simplifications to the respective s390 linker tests. With Alan's words:
There is no need for multiple tests of readelf --got-contents,
nor should the matching be so strict that changes in section layout
force editing of the testsuite.
ld/testsuite/
* ld-s390/binutils.exp (libgot-1*): Reduce number of tests.
* ld-s390/libgot_64-1.rd: New test.
* ld-s390/libgot_64-1a.rd: Remove.
* ld-s390/libgot_64-1b.rd: Likewise.
* ld-s390/libgot_64-1c.rd: Likewise.
* ld-s390/libgot_64-1d.rd: Likewise.
Tom Tromey [Thu, 5 Feb 2026 18:17:22 +0000 (11:17 -0700)]
Fix copyright dates for new files
I forgot to add 2026 to a copyright date in a file I recently
committed (but had originally submitted in 2025). Thinking this might
have happened before, I re-ran gdb/copyright.py and it pointed out a
surprising number of such changes.
Tom Tromey [Fri, 21 Sep 2018 15:46:35 +0000 (09:46 -0600)]
Add .clang-format
This patch adds a .clang-format file to the gdb repository.
The resulting reformatting is what I'd describe as "ok but not great".
There are a few variances from our normal style, some discussed in
comments in the file, and some in the bug.
I've somewhat come around to the idea that some ugliness is
acceptable, particularly because I regularly see code that's already
ugly anyway -- either in formatting or along some other dimension.
I don't know of a way to enforce a particular version. I have only
tried clang-format 18 with this particular file, though Kevin Buettner
reported trying 19-21 as well. I've documented this in the file.
I used "AllowShortFunctionsOnASingleLine: InlineOnly" as previously
discussed. I feel that the spirit of the GNU style is that vertical
space is free, and we should use "None" here. (This goes against
something we previously decided on the list, though.)
The file is in the root directory for ease of use.
For the time being you should not bulk reformat files. I think we
should have a flag day for this, but at some later point. See the
earlier discussion for details.
New in v4:
* Comment fixes
* Remove ForEachMacros - no longer correct
* Remove IncludeCategories - no longer correct
New in v5:
* More fixes to the comments
New in v6:
* Removed 'StatementMacros' setting, we're no longer using
PyObject_HEAD
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30098 Approved-by: Kevin Buettner <kevinb@redhat.com>
This commit introduced a non backward compatible change to how GDB
handled skip files. Something like:
skip -gfile dir/*.c
no longer matches every file within 'dir/', but now matches every file
in 'dir/' and within every sub-directory of 'dir/', which might not be
what the user wanted.
The original intention behind the commit is solid, we just need to
find a better implementation.
(gdb) bt
#0 0x00000001000008d4 in main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.opt/empty-inline-cxx.cc:63
(gdb) FAIL: gdb.opt/empty-inline-cxx.exp: opt_level=Og: backtrace in main
This is almost correct, except the test is not expecting the
"0x00000001000008d4 in" part. This first backtrace is done
immediately after the 'runto_main' call so the fact that we're not
stopped exactly at the start of line 63 is a little strange, but isn't
a critical part of this test. As such I've updated the test pattern
to accept an optional address within the backtrace.
This failure was brought to my attention in this mailing list post:
Alan Modra [Wed, 11 Feb 2026 05:01:33 +0000 (15:31 +1030)]
Free sframe encoder context
Like the patch to free sframe decoder data, this also needs to ensure
the function doing the free is passed the actual context address.
bfd/
* elf-sframe.c (_bfd_elf_write_section_sframe): Don't pass
address of local var to sframe_encoder_free, pass the actual
context address.
* elf64-s390.c (elf_s390_link_hash_table_free): New function.
(elf_s390_link_hash_table_create): Set hash_table_free. Tidy
zmalloc call.
(_bfd_s390_elf_write_sframe_plt): Don't pass address of local
var to sframe_encoder_free, pass the actual context address.
* elflink.c: Include sframe-api.h.
(_bfd_elf_link_hash_table_free): Free sframe encoder data.
* elfxx-x86.c (elf_x86_link_hash_table_free): Likewise.
(_bfd_x86_elf_write_sframe_plt): Don't pass address of local
var to sframe_encoder_free, pass the actual context address.
libsframe/
* sframe.c (sframe_encode): Free context on error return path.
Alan Modra [Wed, 11 Feb 2026 05:00:40 +0000 (15:30 +1030)]
Free sframe context memory on bfd_close
Call sframe_decoder_free in _bfd_elf_free_cached_info and correct
other calls to sframe_decoder_free so that sfd_info->stf_ctx is
cleared. If sfd_info->stf_ctx isn't cleared we get double frees.
* elf-sframe.c (sframe_decode): Do not pass local var sfd_ctx
address to sframe_decoder_free, pass the actual context address.
(_bfd_elf_merge_section_sframe): Likewise.
* elf.c: Include sframe-api.h.
(_bfd_elf_free_cached_info): Free sframe info.
Alan Modra [Wed, 11 Feb 2026 05:00:24 +0000 (15:30 +1030)]
Double-free sframe_decode tempbuf
If an error occurs after assigning tempbuf to dctx->sfd_buf, then
tempbuf will be freed twice. Avoid that by moving tempbuf and its
free on errors into the block where it is used.
Jan Vrany [Tue, 10 Feb 2026 19:30:03 +0000 (19:30 +0000)]
gdb/testsuite: remove timeout setting from gdb.base/chng-syms.exp
Test gdb.base/chng-syms.exp sets timeout to 10 seconds unconditionally.
Not only this is not necessary as the default timeout seems to be the
same, it may actually lower the timeout if set in site.exp (which is
the common technique to setup testsuite on slow machines).
Simon Marchi [Mon, 9 Feb 2026 21:27:04 +0000 (16:27 -0500)]
gdb/testsuite: do not force -static in gdb.ada/mi_ex_cond.exp
When running gdb.ada/mi_ex_cond.exp on Debian 13, I get:
-catch-exception -c "i = 2" -e constraint_error
^error,msg="Your Ada runtime appears to be missing some debugging information.\nCannot insert Ada exception catchpoint in this configuration."
(gdb)
FAIL: gdb.ada/mi_ex_cond.exp: catch C_E if i = 2 (unexpected output)
And this is despite having the check "gnat_runtime_has_debug_info" at
the top of the file.
The problem is that the "gnat_runtime_has_debug_info" is done using the
toolchain's default mode, regarding linking to a static or shared
libgnat. On Debian, the default is specificalyl changed to be shared
[1].
However, the test forces linking to a static libgnat. The result is
that gnat_runtime_has_debug_info passes, seeing that when linking
against libgnat.so, debug info is available (distributed as separate
debug info, in /usr/lib/debug). But then, the test explicitly builds
against a static libgnat, and then fails because debug info is not
found.
I propose to remove that "force static" part of the test. It was added
in the test in the original commit that introduced it [2] without
explanation. Not forcing it makes more sense to me:
gnat_runtime_has_debug_info checks if, when using the default linking
mode of the toolchain, debug info can be found. And then, not
specifying anything to gdb_compile_ada builds the test binary with the
default mode of the toolchain. So the two are coherent.
With this patch, I see the failures shown by Tom Tromey in this patch
[3], and with his patch applied, the test passes fine.
Tom Tromey [Mon, 9 Feb 2026 19:17:17 +0000 (12:17 -0700)]
Minor Ada test fix for gnat-llvm
gdb.ada/char_enum_overload.exp fails because LLVM optimizes away the
necessary function parameters. Adding a couple of calls to Do_Nothing
makes this test work.
aarch64: Add the missing tests for TLBI <operation> vmallws2e1
In the support for FEAT_TLBID feature patch, few <operation>
variants are added to the aarch64_sys_regs_tlbi table,
and that patch was missing the tests for following <operation>
variants, which are covered in this patch.
Alan Modra [Tue, 10 Feb 2026 00:16:47 +0000 (10:46 +1030)]
tidy elf attr error handling
Add a missing error check, and make another error check a little more
stringent. If it were ever possible for oav2_parse_attr to return
zero, the loop would not terminate.
* elf-attrs.c (oav2_parse_subsection): Check read_ntbs return
for errors. Tidy loop reading attrs, and error on <= 0.
Alan Modra [Tue, 10 Feb 2026 00:04:48 +0000 (10:34 +1030)]
PR 33858 Object Attributes v2 memory leaks
It is possble for elf_object_p to hit errors after or during the loop
processing sections with bfd_section_from_shdr. That means we might
have some object attributes malloc'd. They need cleaning up in
elf_object_p because bfd_check_format_matches only handles tidying of
bfd_alloc memory.
* elfcode.h (elf_object_p): Free object attributes on failure.
Tom Tromey [Mon, 9 Feb 2026 03:52:04 +0000 (20:52 -0700)]
Fix gdb.ada/mi_ex_cond.exp when libgnat debuginfo is installed
When libgnat debuginfo is installed, gdb.ada/mi_ex_cond.exp will fail.
I tracked this down to two problems:
1. The MI output has changed a little. This probably wasn't noticed
because this test only works when libgnat debuginfo is available,
which isn't the norm. This patch updates the expected output.
2. The variable "I" in the test triggers the Ada disambiguation menu,
because some variables named "I" are visible in libgnat. While at
its root this is a deeper problem in the Ada support, it's
complicated to fix this. Since this isn't the point of the test,
this patch just renames the variable in question.
There are some other Ada tests that fail in this setup, but I think
they are a bit more complicated to fix.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Sun, 8 Feb 2026 22:04:11 +0000 (17:04 -0500)]
gdb/registry: add registry::key::try_emplace
We have many times the pattern:
current_source_location *loc
= current_source_key.get (pspace);
if (loc == nullptr)
loc = current_source_key.emplace (pspace);
return loc;
I thought it would be nice to have it directly part of registry::key.
Add a try_emplace method, which is like emplace, except that it returns
the existing data, if any. The try_emplace name comes from similar
methods in std::map or gdb::unordered_map
(ankerl::unordered_dense::map).
Replace as many callers as I could find to use it.
Change-Id: I21f922ca065a354f041caaf70484d6cfbcbb76ed Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sun, 8 Feb 2026 22:04:10 +0000 (17:04 -0500)]
gdb/registry: make registry::key::emplace return a reference
Since we use C++ and not C, I think that we should gradually move to
using references for things that can never be nullptr. One example of
this is the return value of the emplace method.
Change it to return a reference, and (to keep the patch straightforward)
update all callers to take the address. More patches could follow to
propagate the use of references further.
Change-Id: I725539694cf496f8288918cc29d7aaae9aca2292 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sun, 8 Feb 2026 22:04:09 +0000 (17:04 -0500)]
gdb/guile: wrap scm-arch.c per-arch data in a structure
scm-arch.c uses "void" as a registry data type here:
/* Use a 'void *' here because it isn't guaranteed that SCM is a
pointer. */
static const registry<gdbarch>::key<void, gdb::noop_deleter<void>>
arch_object_data;
This conflicts with my subsequent patch that makes the emplace method
return a reference because it's not valid to have `void &`.
Circumvent the problem by defining a structure type to use in the
registry, instead of storing the SCM directly. I think that makes the
code more straightforward and less hacky anyway (at the cost of one
extra allocate per gdbarch that you would use in your Guile code...).
Change-Id: I8d92234a9b0384098fa066dc79a42195dee7ca04 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 16 Jan 2026 16:19:09 +0000 (09:19 -0700)]
Use std::make_unique with ui_files
This changes a couple of spots to use std::make_unique rather than
'new'. This is a bit more idiomatic. I've only touched code
involving ui_file here, there are plenty more changes like this that
could be made, but I considered those unrelated to this series.
Tom Tromey [Wed, 10 Dec 2025 09:24:13 +0000 (02:24 -0700)]
Warn if log file changed while logging
PR gdb/33531 points out that while some "set logging" commands will
warn if you attempt to change settings when logging is already active,
"set logging file" does not. This patch corrects this oversight.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33531 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sat, 6 Dec 2025 21:12:37 +0000 (15:12 -0600)]
Rewrite output redirection and logging
This patch changes how gdb output redirection is done.
Currently, output is done via the UI. gdb_stdout, for example, is a
define the expands to an lvalue referencing a field in the current UI.
When redirecting, this field may temporarily be reset; and when
logging is enabled or disabled, this is also done.
This has lead to bugs where the combination of redirection and logging
results in use-after-free. Crashes are readily observable; see the
new test cases.
This patch upends this. Now, gdb_stdout is simply an rvalue, and
refers to the current interpreter. The interpreter provides ui_files
that do whatever rewriting is needed (mostly for MI); then output is
forward to the current UI via an indirection (see the new
ui::passthrough_file).
The ui provides paging, logging, timestamps, and the final stream that
writes to an actual file descriptor.
Redirection is handled at the ui layer. Rather than changing the
output pipeline, new ui_files are simply swapped in by rewriting
pointers, hopefully with a scoped_restore.
Redirecting at the ui layer means that interpreter rewriting is still
applied when capturing output. This fixes one of the reported bugs.
Not changing the pipeline means that the problems with the combination
of redirect and logging simply vanish. Logging just changes a flag
and doesn't involve object destruction.
Tom Tromey [Sat, 6 Dec 2025 21:35:24 +0000 (15:35 -0600)]
Add a new logging_file implementation
This adds a new logging_file subclass of ui_file. This new subclass
handles the details of logging, by consulting the relevant globals.
I think a dependency on globals is warranted here, because the logging
settings themselves are global.
The idea of this approach is that rather than modifying the output
pipeline in response to logging commands, a logging_file will simply
always be in the pipeline, and will then react to the appropriate
settings. ("Appropriate" because there are tests that the logger
doesn't immediately react to changes, so it captures settings at the
moment logging starts.)
The new code isn't actually used yet -- nothing in this patch
constructs a logging_file. It's separate for easier review.
Tom Tromey [Tue, 9 Dec 2025 15:38:30 +0000 (08:38 -0700)]
Remove m_applied_style from ui_file
While working on this series, I found a number of odd styling issues
recurred. For instance, the issue where the pager would lose track
and style subsequent output incorrectly reappeared.
It turned out that different ui_file objects in the output pipeline
would get confused about their current style. And, looking deeper at
this, I realized that mainly it is the pager that really needs to
track the current style at all. All the other file implementations
can be purely reactive (except the buffered stream code, as Andrew
pointed out).
This patch moves m_applied_style from ui_file and into pager_file.
This necessitated making ui_file::vprintf virtual, so that the base
class could pass in the "plain" style as the starting point, whereas
the pager could use the applied style. (I did not investigate whether
this was truly necessary, and I somewhat suspect it might not be.)
This straightforward approach caused some regressions, mostly
involving extra ANSI escapes being emitted. I fixed most of these by
arranging for ui_out::call_do_message to track styles a little more
thoroughly.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Thu, 11 Dec 2025 22:12:30 +0000 (15:12 -0700)]
Rewrite cli-style.c:do_show
IMO it looks a little nicer if cli-style.c:do_show uses a single
printf to display its output. This is also slightly more
i18-friendly.
I noticed this while debugging a case where multiple redundant ANSI
escapes were sent. In conjunction with a subsequent patch, this
approach happens to fix that problem. FWIW I don't consider such
redundancies to be bugs, but it was convenient to change this one.
Tom Tromey [Tue, 9 Dec 2025 16:37:26 +0000 (09:37 -0700)]
Restore ui_file::can_page
A while back, I removed the ui_file::can_page method. It wasn't
needed for a while, due to how output redirections were done.
With the new approach in this series, it's convenient to have this
method again, because the pipeline downstream from the pager won't
change when logging -- the logging filter will be enabled or disabled
without reconfiguring the pipeline. This method lets the pager adapt
correctly.
Tom Tromey [Sat, 17 Jan 2026 16:09:22 +0000 (09:09 -0700)]
Remove gdb_stdtargin
gdb_stdtargin is only used in a single place; and, strangely, does not
follow the current UI. This patch removes the global and changes the
one user to use gdb_stdin instead.
Tom Tromey [Sun, 7 Dec 2025 00:55:20 +0000 (18:55 -0600)]
Move buffered stream to new files
The buffered stream code is currently in ui-out.h and ui-out.c, which
seems weird because it seems more like a low-level ui-file idea (for
the most part, it does also affect some ui_out).
This patch moves the declarations to a new header file,
buffered-streams.h and the implementation to buffered-streams.c. This
seems cleaner to me.
Tom Tromey [Sun, 7 Dec 2025 23:29:17 +0000 (17:29 -0600)]
Move stdtarg to ui
Currently, most of the output streams are handled by the UI -- with
the sole exception of gdb_stdtarg. This doesn't make sense to me, and
it is is useful in the longer term to make it per-UI so that the
logging approach can be uniform across all streams. So, this moves it
to the UI, following the implementation approach of all other output
streams.
Tom Tromey [Mon, 9 Feb 2026 14:33:59 +0000 (07:33 -0700)]
Remove unused local variable from c_type_print_base_struct_union
In my earlier patch to remove TYPE_FN_FIELD_STUB, I didn't notice that
the local variable mangled_name_holder is now unused and can be
removed. The compiler didn't notice, either, I assume because it has
a constructor and destructor.
projects / thirdparty / binutils-gdb.git / log
