Pedro Alves [Fri, 8 Aug 2025 23:03:28 +0000 (00:03 +0100)]
MSYS2+MinGW testing: Unix <-> Windows path conversion
On an MSYS2 system, I have:
# which tclsh
/mingw64/bin/tclsh
# which tclsh86
/mingw64/bin/tclsh86
# which tclsh8.6
/usr/bin/tclsh8.6
# which expect
/usr/bin/expect
The ones under /usr/bin are MSYS2 programs (linked with msys-2.0.dll).
I.e., they are really Cygwin (unix) ports of the programs.
The ones under /mingw64 are native Windows programs (NOT linked with
msys-2.0.dll). You can check that with CYGWIN/MSYS2 ldd.
The MSYS2/Cygwin port of TCL (and thus expect) does not treat a file
name that starts with a drive letter as an absolute file name, while
the native/MinGW port does. Vis:
# cat file-join.exp
puts [file join c:/ d:/]
# /mingw64/bin/tclsh.exe file-join.exp
d:/
# /mingw64/bin/tclsh86.exe file-join.exp
d:/
# /usr/bin/expect.exe file-join.exp
c:/d:
# /usr/bin/tclsh8.6.exe file-join.exp
c:/d:
When running the testsuite under MSYS2 to test mingw32 (Windows
native) GDB, we use MSYS2 expect (there is no MinGW port of expect
AFAIK). Any TCL file manipulation routine will thus not consider
drive letters special, and just treats them as relative file names.
This results in several cases of the testsuite passing to GDB broken
file names, like:
"C:/foo/C:/foo/bar"
or:
"/c/foo/C:/foo/bar"
E.g., there is a "file join" in standard_output_file that results in
this:
(gdb) file C:/gdb/build/outputs/gdb.base/info_sources_2/C:/gdb/build/outputs/gdb.base/info_sources_2/info_sources_2
C:/gdb/build/outputs/gdb.base/info_sources_2/C:/gdb/build/outputs/gdb.base/info_sources_2/info_sources_2: No such file or directory.
(gdb) ERROR: (info_sources_2) No such file or directory
delete breakpoints
The bad "file join" comes from clean_restart $binfile, where $binfile
is an absolute host file name (thus has a drive letter), clean_restart
doing:
set binfile [standard_output_file ${executable}]
return [gdb_load ${binfile}]
and standard_output_file doing:
# If running on MinGW, replace /c/foo with c:/foo
if { [ishost *-*-mingw*] } {
set dir [exec sh -c "cd ${dir} && pwd -W"]
}
return [file join $dir $basename]
Here, BASENAME was already an absolute file name that starts with a
drive letter, but "file join" treated it as a relative file name.
Another spot where we mishandle Unix vs drive letter file names, is in
the "dir" command that we issue when starting every testcase under
GDB. We currently always pass the file name as seen from the build
machine (i.e., from MSYS2), which is a Unix file name that native
Windows GDB does not understand, resulting in:
(gdb) dir /c/gdb/src/gdb/testsuite/gdb.rocm
warning: /c/gdb/src/gdb/testsuite/gdb.rocm: No such file or directory
Source directories searched: /c/gdb/src/gdb/testsuite/gdb.rocm;$cdir;$cwd
This patch introduces a systematic approach to handle all this, by
introducing the concepts of build file names (what DejaGnu sees) vs
host file names (what GDB sees).
This patches implements that in the following way:
standard_output_file currently converts the file name to a Windows
file name, using the "cd $dir; pwd -W" trick. standard_output_file is
used pervasively, so I think it should keep the semantics that it
returns a host file name.
Note there is already a preexisting host_standard_output_file
procedure. The difference to standard_output_file is that
host_standard_output_file handles remote hosts, while
standard_output_file assumes the build and host machines share a
filesystem. The MSYS2 Unix path vs MinGW GDB drive letter case fall
in the "shared filesystem" bucket. An NFS mount on the host at the
same mount point as on the build machine falls in that bucket too.
2) - Introduce build_standard_output_file
In some places, we are calling standard_output_file to find the
build-side file name, most often just to find the standard output
directory file name, and then immediately use that file name with TCL
file manipulation procedures, to do some file manipulation on the
build machine. clean_standard_output_dir is an example of such a
case. That code path is responsible for this bogus 'rm -rf' in
current MSYS2 testing:
Running /c/gdb/src/gdb/testsuite/gdb.base/break.exp ...
Executing on build: rm -rf /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-tests...
For these cases, add a variant of standard_output_file called
build_standard_output_file. The main difference to
standard_output_file is that it doesn't do the "cd $dir; pwd -W"
trick. I.e., it returns a path on the build machine.
3) Introduce host_file_sanitize
In some cases, we read an absolute file name out of GDB's output, and
then want to compare it against some other file name. The file name
may originally come from the DWARF, and sometimes may have forward
slashes, and other times, it may have backward slashes. Or the drive
letter may be uppercase, or it may be lowercase. To make comparisons
easier, add a new host_file_sanitize procedure, that normalizes
slashes, and uppercases the drive letter. It does no other
normalization. Particularly, it does not turn a relative file name
into an absolute file name.
It's arguable whether GDB itself should do this sanitization. I
suspect it should. I personally dislike seeing backward slashes in
e.g., "info shared" output, or worse, mixed backward and forward
slashes. Still, I propose starting with a testsuite adjustment that
moves us forward, and handle that separately. I won't be surprised if
we need the new routine for some cases even if we adjust GDB.
4) build_file_normalize / host_file_normalize
In several places in the testsuite, we call "file normalize" on some
file name. If we pass it a drive-letter file name, that TCL procedure
treats the passed in file name as a relative file name, so produces
something like /c/foo/C:/foo/bar.txt.
If the context calls for a build file name, then the "file normalize"
call should produce /c/foo/bar.txt. If OTOH we need a host file name,
then it should produce "C:/foo/bar.txt". Handle this by adding two
procedures that wrap "file normalize":
- build_file_normalize
- host_file_normalize
Initialy I implemented them in a very simple way, calling into
cygpath:
"cygpath" is a utility that comes OOTB with both Cygwin and MSYS2,
that does Windows <-> Cygwin file name conversion.
This works well, but because running the testsuite on Windows is so
slow, I thought of trying to avoid or minimize the cost of calling an
external utility ("cygpath").
On my system, calling into cygpath takes between 200ms to 350ms, and
these smallish costs (OK, not so small!) can creep up and compound an
already bad situation. Note that the current call to "cd $dir; pwd
-W" has about the same cost as a "cygpath" call (though a little bit
cheaper).
So with this patch, we actually don't call cygpath at all, and no
longer use the "cd $dir; pwd -W" trick. Instead we run the "mount"
command once, and cache the mapping (via gdb_caching_proc) between
Windows file names and Unix mount points, and then use that mapping in
host_file_normalize and build_file_normalize, to do the Windows <=>
Unix file name conversions ourselves.
One other small advantage here is that this approach works the same
for 'cygwin x mingw' testing [1], and 'msys x mingw' testing, while
"pwd -W" only works on MSYS2.
So I think the end result is that we should end up faster (or less
slow) than the current state.
(No, I don't have actual timings for the effect over a whole testsuite
run.)
5) Introduce host_file_join
For the "file join" call done from within standard_output_file (and
probably in future other places), since that procedure works with host
file names, add a new host_file_join procedure that is a wrapper
around "file join" that is aware of Windows drive letters.
======
With the infrastructure described above in place, the "dir" case is
fixed by simply calling host_file_normalize on the directory name,
before passing it to GDB. That turns:
(gdb) dir /c/gdb/src/gdb/testsuite/gdb.base
warning: /c/gdb/src/gdb/testsuite/gdb.base: No such file or directory
Source directories searched: /c/gdb/src/gdb/testsuite/gdb.base;$cdir;$cwd
Into:
(gdb) dir C:/gdb/src/gdb/testsuite/gdb.base
Source directories searched: C:/gdb/src/gdb/testsuite/gdb.base;$cdir;$cwd
Running the testsuite on GNU/Linux reveals that that change requires
tweaks to gdb.guile/scm-parameter.exp and gdb.python/py-parameter.exp,
to run the expected directory by host_file_normalize too, so that it
matches the directory we initially pass GDB at startup time. Without
that fix, there could be a mismatch if the GDB sources path has a
symlink component, which now gets resolved by the host_file_normalize
call.
The theory is that most standard_output_file uses will not need to be
adjusted.
I grepped for "file normalize" and "file join", to find cases that
might need adjustment, and fixed those that required fixing. The
fixes are included in this patch, to make it easier to reason about
the overall change. E.g., in gdb.base/fullname.exp, without the fix,
we get:
Running /c/gdb/src/gdb/testsuite/gdb.base/fullname.exp ...
ERROR: tcl error sourcing /c/gdb/src/gdb/testsuite/gdb.base/fullname.exp.
ERROR: tcl error code NONE
ERROR: C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/fullname/tmp-fullname.c not a subdir of /c/msys2/home/alves/gdb/build-testsuite
In gdb.base/source-dir.exp, we have several issues. E.g., we see the
"/c/foo/c:/foo" problem there too:
dir /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs
warning: /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs: No such file or directory
Source directories searched: /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs;$cdir;$cwd
(gdb) PASS: gdb.base/source-dir.exp: setup source path search directory
...
Executing on host: x86_64-w64-mingw32-gcc \
-fno-stack-protector \
/c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/macro-source-path/cwd/macro-source-path.c ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
... and we need to handle Unix file names that we pass to the compiler
(on the build side), vs file names that GDB prints out (the host
side).
Similarly in the other testcases.
I haven't yet tried to do a full testsuite run on MSYS2, and I'm quite
confident there will be more places that will need similar adjustment,
but I'd like to land the infrastructure early, so that the rest of the
testsuite can be adjusted incrementally, and others can help.
Simon Marchi [Thu, 14 Aug 2025 20:13:01 +0000 (16:13 -0400)]
gdb/copyright.py: print notice about files that print copyright at runtime
During the last new year process, it seems that we forgot to update the
copyright notices printed by the various programs (see 713b99a9398 "gdb,
gdbserver: update copyright years in copyright notices"). Change
gdb/copyright.py to print a message about this. For a procedure that
happens once a year, this seems sufficient to me, but if someone wants
to automate it I won't object.
While at it, change the formatting of the previous message, to match the
formatting of the first message (making it end with a colon).
Change-Id: I330f566221d102bab0a953bc324127f2466dd5cf Approved-By: Tom Tromey <tom@tromey.com>
There are a good number of testcases in the testsuite that use alarm()
as a watchdog that aborts the test if something goes wrong.
alarm()/SIG_ALRM do not exist on (native) Windows, so those tests fail
to compile there.
For example, testing with x86_64-w64-mingw32-gcc, we see:
Running /c/rocgdb/src/gdb/testsuite/gdb.base/attach.exp ...
gdb compile failed, C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c: In function 'main':
C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c:17:3: error: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
17 | alarm (60);
| ^~~~~
While testing with a clang configured to default to
x86_64-pc-windows-msvc, which uses the C/C++ runtime headers from
Visual Studio and has no unistd.h, we get:
Running /c/rocgdb/src/gdb/testsuite/gdb.base/attach.exp ...
gdb compile failed, C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c:8:10: fatal error: 'unistd.h' file not found
8 | #include <unistd.h>
| ^~~~~~~~~~
Handle this by adding a new testsuite/lib/gdb_watchdog.h header that
defines a new gdb_watchdog function, which wraps alarm on Unix-like
systems, and uses a timer on Windows.
This patch adjusts gdb.base/attach.c as example of usage. Testing
gdb.base/attach.exp with clang/x86_64-pc-windows-msvc required a
related portability tweak to can_spawn_for_attach, to not rely on
unistd.h on Windows.
gdb.rocm/mi-attach.cpp is another example adjusted, one which always
runs with clang configured as x86_64-pc-windows-msvc on Windows (via
hipcc).
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I3b07bcb60de039d34888ef3494a5000de4471951
Pedro Alves [Wed, 13 Aug 2025 00:21:10 +0000 (01:21 +0100)]
Automatically handle includes in testsuite/lib/
Instead of manually calling lappend_include_file in every testcase
that needs to include a file in testsuite/lib/, handle testsuite/lib/
includes automatically in gdb_compile.
As an example, gdb.base/backtrace.exp is adjusted to no longer
explicitly call lappend_include_file for testsuite/lib/attributes.h.
Some namespace IDs for the dynamic linker entries (ld-linux) are wrong
(I placed a ! next to those that are wrong).
The dynamic linker is special: it is loaded only once (notice how all
ld-linux entries have the same addresses), but it is visible in all
namespaces. It is therefore listed separately in all namespaces.
The problem happens like this:
- for each solib, print_solib_list_table calls solib_ops::find_solib_ns
to get the namespace ID to print
- svr4_solib_ops::find_solib_ns calls find_debug_base_for_solib
- find_debug_base_for_solib iterates on the list of solibs in all
namespaces, looking for a match for the given solib. For this, it
uses svr4_same, which compares two SOs by name and low address.
Because there are entries for the dynamic linker in all namespaces,
with the same low address, find_debug_base_for_solib is unable to
distinguish them, and sometimes returns the wrong namespace.
To fix this, save in lm_info_svr4 the debug base address that this
lm/solib comes from, as a way to distinguish two solibs that would be
otherwise identical.
The code changes are:
- Add a constructor to lm_info_svr4 accepting the debug base. Update
all callers, which sometimes requires passing down the debug base.
- Modify find_debug_base_for_solib to return the debug base directly
from lm_info_svr4.
- Modify svr4_same to consider the debug base value of the two
libraries before saying they are the same. While at it, move the
address checks before the name check, since they are likely less
expensive to do.
- Modify svr4_solib_ops::default_debug_base to update the debug base of
existing solibs when the default debug base becomes known.
I found the last point to be necessary, because when running an
inferior, we list the shared libraries very early (before the first
instruction):
#0 svr4_solib_ops::current_sos (this=0x7c1ff1e09710)
#1 0x00005555643c774e in update_solib_list (from_tty=0)
#2 0x00005555643ca377 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
#3 0x0000555564335585 in svr4_solib_ops::enable_break (this=0x7c1ff1e09710, info=0x7d2ff1de8c40, from_tty=0)
#4 0x000055556433c85c in svr4_solib_ops::create_inferior_hook (this=0x7c1ff1e09710, from_tty=0)
#5 0x00005555643d22cb in solib_create_inferior_hook (from_tty=0)
#6 0x000055556337071b in post_create_inferior (from_tty=0, set_pspace_solib_ops=true)
#7 0x00005555633726a2 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL)
#8 0x0000555563372b35 in run_command (args=0x0, from_tty=0)
At this point, the dynamic linker hasn't yet filled the DT_DEBUG slot,
which normally points at the base of r_debug. Since we're unable to
list shared libraries at this point, we go through
svr4_solib_ops::default_sos, which creates an solib entry for the
dynamic linker. At this point, we have no choice but to create it with
a debug base of 0 (or some other value that indicates "unknown"). If we
left it as-is, then it would later not be recognized to be part of any
existing namespace and that would cause problems down the line.
With this change, the namespaces of the dynamic linker become correct.
I was not sure if the code in library_list_start_library was conflating
debug base and lmid. The documentation says this about the "lmid" field
in the response of a qxfer:libraries-svr4:read packet:
lmid, which is an identifier for a linker namespace, such as the
memory address of the r_debug object that contains this namespace’s
load map or the namespace identifier returned by dlinfo (3).
When I read "lmid", I typically think about "the namespace identifier
returned by dlinfo (3)". In library_list_start_library, we use the
value of the "lmid" attribute as the debug base address. This is the
case even before this patch, since we do:
solist = &list->solib_lists[lmid];
The key for the solib_lists map is documented as being the debug base
address. In practice, GDBserver uses the debug base address for the
"lmid" field, so we're good for now.
If the remote side instead used "the namespace identifier returned by
dlinfo (3)" (which in practice with glibc are sequential integers
starting at 0), I think we would be mostly fine. If we use the qxfer
packet to read the libraries, we normally won't use the namespace base
address to do any memory reads, as all the information comes from the
XML. There might be some problems however because we treat the
namespace 0 specially, for instance in
svr4_solib_ops::update_incremental. In that case, we might need a
different way of indicating that the remote side does not give namespace
information than using namespace 0. This is just a thought for the
future.
I improved the existing test gdb.base/dlmopen-ns-ids.exp to verify that
"info sharedlibrary" does not show duplicate libraries, duplicate
meaning same address range, namespace and name.
Simon Marchi [Tue, 22 Jul 2025 19:08:40 +0000 (15:08 -0400)]
gdb/solib-svr4: centralize fetching of default debug base
When running an inferior, solib_ops_svr4::current_sos is called very
early, at a point where the default debug base is not yet accessible.
The inferior is stopped at its entry point, before the dynamic linker
had the time to fill the DT_DEBUG slot. It only becomes available a
little bit later. In a following patch, I will want to do some action
when the debug base becomes known (namely, update the debug base in the
previously created lm_info_svr4 instances).
For this reason, add the svr4_solib_ops::default_debug_base method to
centralize where we fetch the default debug base. I will then be able
to add my code there, when detecting the debug base changes.
This patch brings the following behavior change: since all
svr4_solib_ops entry points now use svr4_solib_ops::default_debug_base
to get the debug base value, they will now all re-fetch the value from
the inferior. Previously, this was not done consistently, only in two
spots. It seems to me like it would be good to be consistent about
that, because we can't really predict which methods will get called in
which order in all scenarios.
Some internal methods still access svr4_info::default_debug_base
directly, because it is assumed that their caller would have used
svr4_solib_ops::default_debug_base, updating the value in
svr4_info::default_debug_base if necessary.
Simon Marchi [Tue, 15 Jul 2025 15:52:32 +0000 (11:52 -0400)]
gdb: make iterate_over_objfiles_in_search_order methods of program_space and solib_ops
Change the "iterate over objfiles in search order" operation from a
gdbarch method to methods on both program_space and solib_ops.
The first motivation for this is that I want to encapsulate solib-svr4's
data into svr4_solib_ops (in a subsequent series), instead of it being
in a separate structure (svr4_info). It is awkward to do so as long as
there are entry points that aren't the public solib_ops interface.
The second motivation is my project of making it able to have multiple
solib_ops per program space (which should be the subject of said
subsequent series), to better support heterogenousa systems (like ROCm,
with CPU and GPU in the same inferior). When we have this, when stopped
in GPU code, it won't make sense to ask the host's architecture to do
the iteration, as the logic could be different for the GPU architecture.
Instead, program_space::iterate_over_objfiles_in_search_order will be
responsible to delegate to the various solib_ops using a logic that is
yet to be determined.
I included this patch in this series (rather than the following one)
so that svr4_solib_ops::iterate_over_objfiles_in_search_order can access
svr4_solib_ops::default_debug_base, introduced in a later patch in this
series.
default_iterate_over_objfiles_in_search_order becomes the default
implementation of solib_ops::iterate_over_objfiles_in_search_order.
As far as I know, all architectures using
svr4_iterate_over_objfiles_in_search_order also use solib_ops_svr4, so I
don't expect this patch to cause behavior changes.
Simon Marchi [Mon, 21 Jul 2025 15:38:30 +0000 (11:38 -0400)]
gdb/solib: save program space in solib_ops
In some subsequent patches, solib_ops methods will need to access the
program space they were created for. We currently access the program
space using "current_program_space", but it would better to remember the
program space at construction time instead.
Simon Marchi [Wed, 23 Jul 2025 18:11:39 +0000 (14:11 -0400)]
gdb/solib: adjust info linker-namespaces/sharedlibrary format
I would like to propose some minor changes to the format of "info linker
namespaces" and "info sharedlibrary", to make it a bit tidier and less
chatty.
Here are the current formats (I replaced empty lines with dots, so that
git doesn't collapse them):
(gdb) info linker-namespaces
There are 3 linker namespaces loaded
There are 5 libraries loaded in linker namespace [[0]]
Displaying libraries for linker namespace [[0]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7e94000 0x00007ffff7f8c000 Yes /usr/lib/libm.so.6
0x00007ffff7ca4000 0x00007ffff7e94000 Yes /usr/lib/libc.so.6
0x00007ffff7fad000 0x00007ffff7fb2000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so
0x00007ffff7fa8000 0x00007ffff7fad000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so
.
.
There are 6 libraries loaded in linker namespace [[1]]
Displaying libraries for linker namespace [[1]]:
From To Syms Read Shared Object Library
0x00007ffff7fb7000 0x00007ffff7fbc000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so
0x00007ffff7fb2000 0x00007ffff7fb7000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so
0x00007ffff7b79000 0x00007ffff7c71000 Yes /usr/lib/libm.so.6
0x00007ffff7989000 0x00007ffff7b79000 Yes /usr/lib/libc.so.6
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /usr/lib/ld-linux-x86-64.so.2
0x00007ffff7f99000 0x00007ffff7f9e000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so
.
.
There are 5 libraries loaded in linker namespace [[2]]
Displaying libraries for linker namespace [[2]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /usr/lib/ld-linux-x86-64.so.2
0x00007ffff7fa3000 0x00007ffff7fa8000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so
0x00007ffff7f9e000 0x00007ffff7fa3000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so
0x00007ffff7891000 0x00007ffff7989000 Yes /usr/lib/libm.so.6
0x00007ffff76a1000 0x00007ffff7891000 Yes /usr/lib/libc.so.6
(gdb) info sharedlibrary
From To NS Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 [[0]] Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7e94000 0x00007ffff7f8c000 [[0]] Yes /usr/lib/libm.so.6
0x00007ffff7ca4000 0x00007ffff7e94000 [[0]] Yes /usr/lib/libc.so.6
0x00007ffff7fb7000 0x00007ffff7fbc000 [[1]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so
0x00007ffff7fb2000 0x00007ffff7fb7000 [[1]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so
0x00007ffff7b79000 0x00007ffff7c71000 [[1]] Yes /usr/lib/libm.so.6
0x00007ffff7989000 0x00007ffff7b79000 [[1]] Yes /usr/lib/libc.so.6
0x00007ffff7fc6000 0x00007ffff7fff000 [[1]] Yes /usr/lib/ld-linux-x86-64.so.2
0x00007ffff7fad000 0x00007ffff7fb2000 [[0]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so
0x00007ffff7fa8000 0x00007ffff7fad000 [[0]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so
0x00007ffff7fa3000 0x00007ffff7fa8000 [[2]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so
0x00007ffff7f9e000 0x00007ffff7fa3000 [[2]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so
0x00007ffff7891000 0x00007ffff7989000 [[2]] Yes /usr/lib/libm.so.6
0x00007ffff76a1000 0x00007ffff7891000 [[2]] Yes /usr/lib/libc.so.6
0x00007ffff7fc6000 0x00007ffff7fff000 [[1]] Yes /usr/lib/ld-linux-x86-64.so.2
0x00007ffff7f99000 0x00007ffff7f9e000 [[1]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so
Here is what I would change:
- I find that the [[...]] notation used everywhere is heavy and noisy.
I understand that this is the (proposed) notation for specifying a
namespace id in an expression. But I don't think it's useful to
print those brackets everywhere (when it's obvious from the context
that the number is a namespace id). I would remove them from the
messages and from the tables.
- I find these lines a bit too verbose:
There are X libraries loaded in linker namespace [[Y]]
Displaying libraries for linker namespace [[Y]]:
I think they can be condensed to a single line, without loss of
information (I think that printing the number of libs in each
namespace is not essential, but I don't really mind, so I left it
there).
- I would add an empty line after the "There are N linker namespaces
loaded" message, to visually separate it from the first group. I
would also finish that line with a period.
- There are two empty lines between each group I think that one empty
line is sufficient to do a visual separation.
Here's how it looks with this patch:
(gdb) info linker-namespaces
There are 3 linker namespaces loaded.
Simon Marchi [Thu, 17 Jul 2025 19:58:05 +0000 (15:58 -0400)]
gdb/solib: don't check filename when checking for duplicate solib
On Arch Linux, I get:
FAIL: gdb.base/dlmopen-ns-ids.exp: reopen a namespace
The symptom observed is that after stepping over the last dlmopen of the
test, "info sharedlibrary" does not show the library just opened. After
digging, I found that when stepping over that dlmopen call, the shlib
event breakpoint (that GDB inserts in glibc to get notified of dynamic
linker activity) does not get hit. I then saw that after the previous
dlclose, the shlib event breakpoints were suddenly all marked as
pending:
(gdb) maintenance info breakpoints
Num Type Disp Enb Address What
-1 shlib events keep n <PENDING>
-1.1 y- <PENDING>
The root cause of this problem is the fact that the dynamic linker path
specified in binaries contains a symlink:
$ readelf --program-headers /bin/ls | grep "Requesting program interpreter"
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ ls -l /lib64
lrwxrwxrwx 1 root root 7 May 3 15:26 /lib64 -> usr/lib
$ realpath /lib64/ld-linux-x86-64.so.2
/usr/lib/ld-linux-x86-64.so.2
As a result, the instances of the dynamic linker in the non-base
namespace have the real path instead of the original path:
Notice that all instances of the dynamic loader have the same address
range. This is expected: the dynamic loader is really loaded just once
in memory, it's just that it's visible in the various namespaces, so
listed multiple times. Also, notice that the last three specify
namespace 1... seems like a separate bug to me (ignore it for now).
The fact that the paths differ between the first one and the subsequent
ones is not something we control: we receive those paths as-is from the
glibc link map.
Since these multiple solib entries are really the same mapping, we would
expect this code in solib_read_symbols to associate them to the same
objfile:
/* Have we already loaded this shared object? */
so.objfile = nullptr;
for (objfile *objfile : current_program_space->objfiles ())
{
if (filename_cmp (objfile_name (objfile), so.name.c_str ())
== 0
&& objfile->addr_low == so.addr_low)
{
so.objfile = objfile;
break;
}
}
But because the filenames differ, we end up creating two different
objfiles with the same symbols, same address ranges, etc. I would guess
that this is not a state we want.
When the dlclose call closes the last library from the non-base
namespace, the dynamic linker entry for that namespace is also
removed. From GDB's point of view, it just looks like an solib getting
unloaded. In update_solib_list, we have this code to check if the
objfile behind the solib is used by other solibs, and avoid deleting the
objfile if so:
/* Notify any observer that the shared object has been
unloaded before we remove it from GDB's tables. */
notify_solib_unloaded (current_program_space, *gdb_iter,
still_in_use, false);
/* Unless the user loaded it explicitly, free SO's objfile. */
if (gdb_iter->objfile != nullptr
&& !(gdb_iter->objfile->flags & OBJF_USERLOADED)
&& !still_in_use)
gdb_iter->objfile->unlink ();
Because this is the last solib to use that objfile instance, the objfile
is deleted. In the process, disable_breakpoints_in_unloaded_shlib (in
breakpoint.c) is called. The breakpoint locations for the shlib event
breakpoints get marked as "shlib_disabled", which then causes them (I
suppose) to not get inserted and be marked as pending. And then, when
stepping on the subsequent dlmopen call, GDB misses the load of the new
library.
It seems clear to me that, at least, the duplicate objfile detection in
solib_read_symbols needs to be fixed. Right now, to conclude that an
solib matches an existing objfile, it checks that:
- the two have equivalent paths (filename_cmp)
- the two have the same "low" address
In this patch, I remove the filename check. This makes it such that all
the solibs for dynamic linker entries will share the same objfile.
This assumes that no two different solibs / objfiles will have the same
low address. At first glance, it seems like a reasonable assumption to
make, but I don't know if there are some corner cases where this is not
true.
To fix my specific case, I could change the code to resolve the symlinks
and realize that these are all the same file. But I don't think it
would work in a general way. For example, if debugging remotely and
using the target: filesystem, we would need to resolve the symlink on
the target, and I don't think we can do that today (there is no
readlink/realpath operation in the target file I/O).
With this patch, gdb.base/dlmopen-ns-ids.exp passes cleanly:
Simon Marchi [Wed, 23 Jul 2025 15:33:59 +0000 (11:33 -0400)]
gdb/solib-svr4: make "lmid" XML attribute optional
When connecting to a GDBserver 12, which doesn't have support for
non-default linker namespaces and the "lmid" attribute in the
qxfer:libraries-svr4:read response, I get:
(gdb) c
Continuing.
⚠️ warning: while parsing target library list (at line 1): Required attribute "lmid" of <library> not specified
Given the code in library_list_start_library, I understand that the
"lmid" attribute is meant to be optional. Mark it as optional in the
attribute descriptions, to avoid this warning.
Simon Marchi [Fri, 18 Jul 2025 13:10:35 +0000 (09:10 -0400)]
gdb/testsuite: handle dynamic linker path with symlink in dlmopen tests
On my Arch Linux system*, the dynamic linker path specified in ELF
binaries contains a symlink:
$ readelf --program-headers /bin/ls | grep "Requesting program interpreter"
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ ls -l /lib64
lrwxrwxrwx 1 root root 7 May 3 15:26 /lib64 -> usr/lib
$ realpath /lib64/ld-linux-x86-64.so.2
/usr/lib/ld-linux-x86-64.so.2
Because of this, some dlmopen tests think that the dynamic linker
doesn't appear multiple times, when it in fact does (under two different
names), and some parts of the test are disabled:
UNSUPPORTED: gdb.base/dlmopen.exp: test_solib_unmap_events: multiple copies of the dynamic linker not found
Make the tests compute the real path of the dynamic linker and accept
that as valid path for the dynamic linker.
With this patch, I go from
# of expected passes 92
to
# of expected passes 98
* On my Ubuntu 24.04 system, the dynamic linker appears to be a symlink
too, but the glibc is too old to show the dynamic linker in the
non-default namespace.
Rainer Orth [Fri, 22 Aug 2025 09:04:51 +0000 (11:04 +0200)]
ld: testsuite: Only xfail "shared (non PIC)" etc. on 64-bit Solaris
Once the ld-shared tests run on both Solaris/SPARC and x86, two tests
XPASS on 32-bit Solaris, both SPARC and x86 (pre-existing on SPARC,
newly revealed on x86):
which can be traced in the mmapobj(2) implementation to the
requirement that a shared object's p_vaddr needs to be 0, which in
this test is intentionally not the case.
* The other two XFAIL's are 64-bit only and for another reason:
ld.so.1: shnp: fatal: relocation error: R_SPARC_H44: file tmpdir/shnp.so: symbol shlibvar2: value 0x3fffffffb9c does not fit
On amd64, shmpnp.so fails to link:
ld/tmpdir/ld/collect-ld: tmpdir/sh1np.o: relocation R_X86_64_32S against symbol `shlib_shlibvar1' can not be used when making a shared object; recompile with -fPIC
ld/tmpdir/ld/collect-ld: failed to set dynamic section sizes: bad value
In both cases, this happens with -z text, too, so the comments are
bogus. Instead, the issue that the code needs to be PIC.
So I'm updating the comments accordingly.
Tested on sparc{v9,}-sun-solaris2.11 and {amd64,i386}-pc-solaris2.11.
Jan Beulich [Fri, 22 Aug 2025 05:56:59 +0000 (07:56 +0200)]
MAINTAINERS: move Jim Wilson to Past Maintainers
..., effectively yielding IA-64 maintainer-less, as per his request:
https://sourceware.org/pipermail/binutils/2025-August/143393.html
https://sourceware.org/pipermail/binutils/2025-August/143491.html
Jim - thanks much for your past work.
Jan Beulich [Fri, 22 Aug 2025 05:56:28 +0000 (07:56 +0200)]
gas: make as_tsktsk() output more as_warn()-like
The lack of a uniform "Warning: " prefix can be irritating. Re-use
as_warn_internal(), by moving the warning count increment into the pre-
existing callers (where the flag_no_warnings checks also are). At the
same time keep the listing_warning() invocation at its place - listings
certainly should have such warnings reproduced as well.
While there also drop the unnecessary forward declarations of static
functions.
Jan Beulich [Fri, 22 Aug 2025 05:53:19 +0000 (07:53 +0200)]
ld/aarch64: prune a PE/COFF test
Expecting ___tls_end__ there is entirely random, when there are multiple
symbols all at the same address. Help objdump to pick the intended
symbol, by making it global and giving it a type.
Lulu Cai [Sat, 16 Aug 2025 03:48:32 +0000 (11:48 +0800)]
LoongArch: Improve the reliability of test cases
Fix PR ld/31101
In some distributions, GCC enables --as-needed by default, which
may prevent linking to necessary dynamic libraries and cause test
failures. When tests require the host GCC, use the --no-as-needed
option and place the necessary dynamic libraries after the object
files. This prevents test failures and improves the test case
reliability.
H.J. Lu [Wed, 20 Aug 2025 19:27:53 +0000 (12:27 -0700)]
elf: Clear entsize when clearing SEC_MERGE|SEC_STRINGS
When generating an output from input SEC_MERGE|SEC_STRINGS sections with
different entsizes, we clear the SEC_MERGE|SEC_STRINGS bits. We also need
to clear entsize.
PR ld/33291
* ldlang.c (lang_add_section): Clearing entsize when clearing
SEC_MERGE|SEC_STRINGS.
* testsuite/ld-elf/pr33291.d: New file.
* testsuite/ld-elf/pr33291a.s: Likewise.
* testsuite/ld-elf/pr33291b.s: Likewise.
H.J. Lu [Sun, 17 Aug 2025 22:22:22 +0000 (15:22 -0700)]
i386: Add GLIBC_ABI_GNU_TLS version dependency
On Linux/i386, programs and shared libraries compiled with
-mtls-dialect=gnu may fail silently at run-time against glibc without
the GNU TLS run-time fix for:
Add the --gnu-tls-tag option to x86-64 ELF linker to add the
GLIBC_ABI_GNU_TLS version dependency in output programs and shared
libraries when linking against glibc if input relocatable object files
call ___tls_get_addr. The output will fail to load and run at run-time
against glibc which doesn't define the GLIBC_ABI_GNU_TLS version.
Add the --enable-gnu-tls-tag configure option to enable --gnu-tls-tag
by default. If unspecified, linker will add the GLIBC_ABI_GNU_TLS
version dependency if input call ___tls_get_addr and libc.so defines
the GLIBC_ABI_GNU2_TLS version.
bfd/
PR ld/33287
* elf-linker-x86.h (elf_linker_x86_params): Add
gnu_tls_version_tag.
* elf32-i386.c (elf_backend_add_glibc_version_dependency): Add
GLIBC_ABI_GNU_TLS support.
* elfxx-x86.c (_bfd_x86_elf_link_check_relocs): Set
has_tls_get_addr_call to 1 if ___tls_get_addr is used.
* elfxx-x86.h (elf_x86_link_hash_table): Add has_tls_get_addr_call.
H.J. Lu [Sun, 17 Aug 2025 17:09:25 +0000 (10:09 -0700)]
x86-64: Add GLIBC_ABI_DT_X86_64_PLT version dependency
On Linux/x86-64, programs and shared libraries created with -z mark-plt
have the GLIBC_2.36 version tag dependency since -z mark-plt uses the
r_addend field of the R_X86_64_JUMP_SLOT relocation to store the offset
of the indirect branch instruction. Glibc versions which don't have the
commit added to glibc 2.36:
x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT
we can add GLIBC_ABI_DT_X86_64_PLT version tag dependency, instead of
GLIBC_2.36 version tag dependency.
PR ld/33213
* elf-bfd.h (_bfd_elf_link_add_glibc_version_dependency): Change
return type to bool.
* elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency): Add
GLIBC_ABI_DT_X86_64_PLT version tag dependency, instead of,
GLIBC_2.36 version tag dependency, for -z mark-plt if libc.so
defines GLIBC_ABI_DT_X86_64_PLT version tag.
* elflink.c (_bfd_elf_link_add_glibc_version_dependency): Change
return type to bool. Return false if elf_link_add_glibc_verneed
returns false.
H.J. Lu [Fri, 4 Jul 2025 00:39:03 +0000 (08:39 +0800)]
x86: Add GLIBC_ABI_GNU2_TLS version dependency
On Linux/x86, programs and shared libraries compiled with
-mtls-dialect=gnu2 may fail silently at run-time against glibc without
the GNU2 TLS run-time fixes for:
A version tag, GLIBC_ABI_GNU2_TLS, has been added to glibc to indicate
that glibc has the working GNU2 TLS run-time. Add the --gnu2-tls-tag
option to i386/x86-64 ELF linker to add the GLIBC_ABI_GNU2_TLS version
dependency in output programs and shared libraries when linking against
glibc if input relocatable object files have R_386_TLS_DESC_CALL or
R_X86_64_TLSDESC_CALL relocation. The output will fail to load and run
at run-time against glibc which doesn't define the GLIBC_ABI_GNU2_TLS
version.
Add the --enable-gnu2-tls-tag configure option to enable --gnu2-tls-tag
by default. If unspecified, linker will add the GLIBC_ABI_GNU2_TLS
version dependency if input object files have R_386_TLS_DESC_CALL or
R_X86_64_TLSDESC_CALL relocation and libc.so defines the GLIBC_ABI_GNU2_TLS
version.
Update elf_link_add_glibc_verneed to properly add the GLIBC_2.36 version
dependency when -z mark-plt -z nopack-relative-relocs passed to x86-64
ELF linker.
bfd/
PR ld/33130
* elf-bfd.h (_bfd_elf_link_add_glibc_version_dependency): Add
a pointer to bool argument.
* elf-linker-x86.h (elf_linker_x86_params): Add
gnu2_tls_version_tag.
* elf32-i386.c (elf_i386_scan_relocs): Set has_tls_desc_call to
1 for R_386_TLS_DESC_CALL.
(elf_i386_add_glibc_version_dependency): New. Undef before
FreeBSD support.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Set has_tls_desc_call
to 1 for R_X86_64_TLSDESC_CALL.
(elf_x86_64_add_glibc_version_dependency): Add GLIBC_ABI_GNU2_TLS
version dependency if GLIBC_ABI_GNU2_TLS dependency isn't disabled
and has_tlsdesc_call isn't 0.
(elf_backend_add_glibc_version_dependency): Undef before FreeBSD
support and redefine for elf32-x86-64.
* elflink.c (elf_link_add_glibc_verneed): Changed to return bool.
Remove the pointer to elf_find_verdep_info argument. Add a
pointer to bool argument, auto_version. Return true if linked
against glibc. Otherwise return false. If the version dependency
is added, set *auto_version to true. If *auto_version is true,
add the version dependency only if libc.so defines the version.
(_bfd_elf_link_add_glibc_version_dependency): Add a pointer to
bool argument and pass it to elf_link_add_glibc_verneed.
(_bfd_elf_link_add_dt_relr_dependency): Pass NULL to
_bfd_elf_link_add_glibc_version_dependency.
* elfxx-x86.h (elf_x86_link_hash_table): Add has_tls_desc_call.
H.J. Lu [Tue, 19 Aug 2025 11:59:10 +0000 (04:59 -0700)]
ld: Compile some tests with -mdirect-extern-access
When GCC enables -mno-direct-extern-access by default, some tests fail
without -mdirect-extern-access. Define DIRECT_EXTERN_ACCESS_CFLAGS
to compile these tests with -mdirect-extern-access. Also pass
"-z noindirect-extern-access" to linker to support the C library
compiled with -mno-direct-extern-access.
PR ld/33267
* testsuite/config/default.exp (DIRECT_EXTERN_ACCESS_CFLAGS): New.
* testsuite/ld-elf/linux-x86.exp: Compile some tests with
$DIRECT_EXTERN_ACCESS_CFLAGS.
* testsuite/ld-elfvers/vers.exp (need_direct_extern_access): New
for i?86.
Compile tests with $need_direct_extern_access.
* testsuite/ld-i386/i386.exp: Compile some tests with
$DIRECT_EXTERN_ACCESS_CFLAGS.
* testsuite/ld-ifunc/ifunc.exp (need_direct_extern_access): New
for i?86.
Compile tests with $need_direct_extern_access.
* testsuite/ld-shared/shared.exp (need_direct_extern_access): New
for i?86.
Compile tests with $need_direct_extern_access.
* testsuite/ld-srec/srec.exp (CFLAGS_FOR_TARGET_TEST): Add
$DIRECT_EXTERN_ACCESS_CFLAGS.
(CXXFLAGS_FOR_TARGET_TEST): Likewise.
* testsuite/ld-vsb/vsb.exp (need_direct_extern_access): New
for i?86.
Compile tests with $need_direct_extern_access.
* testsuite/ld-x86-64/x86-64.exp: Compile some tests with
$DIRECT_EXTERN_ACCESS_CFLAGS and link some tests with
"-Wl,-z,noindirect-extern-access".
Co-Authored-By: Sam James <sam@gentoo.org> Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Signed-off-by: Sam James <sam@gentoo.org>
Guinevere Larsen [Thu, 14 Aug 2025 14:25:38 +0000 (11:25 -0300)]
gdb: rework _active_linker_namespaces variable
This commit reworks the _active_linker_namespaces convenience variable
following Simon's feedback here:
https://sourceware.org/pipermail/gdb-patches/2025-August/219938.html
This patch implements the renaming to _linker_namespace_count (following
the standard set by _inferior_thread_count) and makes the convenience
variable more resilient in the multi-inferior case by providing a new
function, solib_linker_namespace_count, which counts gets the count of
namespaces using the solib_ops of the provided program_space
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Nelson Chu [Wed, 20 Aug 2025 09:47:14 +0000 (17:47 +0800)]
RISC-V: PR33216, Fixed gcc testcases failed for commit 28520d7
I made a stupid mistake in the commit 28520d7, allow to assemble slli/srli/srai
with 0 immediate to hint c.slli/c.srli/c.srai. These hints will be regared as
illegal instruction for gdb and qemu, so at least I got following gcc testcases
failed,
=== g++: Unexpected fails for rv64gc lp64d medlow ===
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test
=== gfortran: Unexpected fails for rv64gc lp64d medlow ===
FAIL: gfortran.dg/leadz_trailz_2.f90 -O0 execution test
=== gcc: Unexpected fails for rv64gc lp64d medlow ===
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test
So we should just allow c.slli/c.srli/c.srai with zero immediate as hints, but
don't allow slli/srli/srai with zero immediate.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Only allow c.slli/c.srli/c.srai
with zero immediate as hints, but don't allow slli/srli/srai with
zero immediate.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
opcodes/
PR 33216
* riscv-opc.c (match_slli_as_c_slli): Added back.
(match_srxi_as_c_srxi): Likewise.
(riscv_opcodes): Only allow c.slli/c.srli/c.srai with zero immediate
as hints, but don't allow slli/srli/srai with zero immediate.
Pietro Monteiro [Wed, 20 Aug 2025 00:34:03 +0000 (20:34 -0400)]
Remove autoconf macro AC_HEADER_STDC
Stop using AC_HEADER_STDC since it is no longer supported in autoconf
2.72+. We require a C++ compiler that supports c++17, it's probably
safe to assume that the C compiler fully supports C89.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Indu Bhagat [Tue, 19 Aug 2025 16:54:15 +0000 (09:54 -0700)]
gas: testsuite: fix regression in cfi-common-10.d
A previous commit 09292f4ae2c introduced the new test cfi-common-10.d.
The testcase needs some adjustments for it to be useful on a variety of
targets.
Andrew Burgess [Mon, 18 Aug 2025 10:49:21 +0000 (11:49 +0100)]
gdb: remove some unnecessary watchpoint_addr_within_range overrides
While looking at the watchpoint code, I realised that AArch64, ARM,
and Loongarch all override watchpoint_addr_within_range with an
implementation that is the same as the default (but with the logic
written slightly differently).
Compare the deleted functions to default_watchpoint_addr_within_range
in target.c.
The only other targets that override watchpoint_addr_within_range are
ppc_linux_nat_target and remote_target, in both cases the
implementation is different to the default.
Lets remove these unnecessary overrides, and just use the default.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 14 Aug 2025 20:14:06 +0000 (16:14 -0400)]
gdb: rename address_class -> location_class
The enum address_class and related fields and methods seem misnamed to
me. Generalize it to "location_class". The enumerators in
address_class are already prefixed with LOC, so the new name seems
logical to me. Rename related fields and methods as well.
Plus, address_class could easily be mistaken for other unrelated things
named "address class" in GDB or DWARF.
Tested by rebuilding.
Change-Id: I0dca3738df412b350715286c608041b08e9b4d82 Approved-by: Kevin Buettner <kevinb@redhat.com>
I spotted this while reviewing a patch adding a new
gdbarch_software_single_step implementation. I find the name
"software_single_step" a bit misleading or unclear. It makes it sounds
as if the function executed a single step. In reality, this function
returns the possible next PCs for current instructions.
We have a similar concept in GDBserver:
linux_process_target::low_get_next_pcs. I like that name, it's clear
and straight to the point.
Rename gdbarch_software_single_step to gdbarch_get_next_pcs. I find
this name more indicative of what happens.
There is some code for ARM shared between GDB and GDBserver to implement
both sides, also called "get next pcs", so I think it all fits well
together.
Tested by rebuilding.
Change-Id: Ide74011a5034ba11117b7e7c865a093ef0b1dece Approved-by: Kevin Buettner <kevinb@redhat.com> Acked-by: Luis Machado <luis.machado.foss@gmail.com>
Rainer Orth [Tue, 19 Aug 2025 13:38:55 +0000 (15:38 +0200)]
ld: testsuite: Mark vers26b3 unsupported on x86_64
After enabling the ld-elfvers tests on Solaris/x86, one of them FAILs on
Solaris/amd64 only:
FAIL: vers26b3
/ld-new: tmpdir/vers26b3.o: relocation R_X86_64_32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC
./ld-new: failed to set dynamic section sizes: bad value
The error is strange: vers26b3.o *was* compiled with -fPIC and repeating
the link with /bin/ld just works. However, the resulting vers26b3.so
fails to load:
$ ldd -r tmpdir/vers26b3.so
[...]
ld.so.1: vers26b3.so.ld: fatal: relocation error: R_AMD64_32: file tmpdir/vers26b3.so.ld: symbol foo: value 0x7fff34d00830 does not fit
When running the test on Linux/x86_64, it fails with the same ld message
as above, so the test is marked unsupported for both Linux/x86_64 and
Solaris/amd64.
Tested on {amd64,i386}-pc-solaris2.11 and {x86_64,i686}-pc-linux-gnu.
Rainer Orth [Tue, 19 Aug 2025 13:34:44 +0000 (15:34 +0200)]
ld: testsuite: Fix ld-elfvers tests on Solaris
All ld-elfvers tests FAIL on Solaris/SPARC, always with the same failure
mode:
FAIL: vers1
./ld-new: _etext: undefined version: vers1.so
./ld-new: _end: undefined version: vers1.so
./ld-new: _edata: undefined version: vers1.so
./ld-new: failed to set dynamic section sizes: bad value
This is due to the use of --no-undefined-version, the error being
emitted by bfd/elflink.c (bfd_elf_size_dynamic_sections). The affected
symbols are mandated by the Solaris ABI in versioned shared objects and
are generated by ld/emultempl/solaris2.em
(elf_solaris2_before_allocation). The check in
bfd_elf_size_dynamic_sections fails since for the base version (vers1.so),
both symver and script are 0:
Given that those symbols are generated internally by ld, it seems
sensible to set script = 1 for them.
This patch does just that, at the same time enabling the tests for
Solaris/x86. Not doing this before looks like an oversight: there's no
difference between SPARC and x86 in this regard.
This introduces one failure on Solaris/amd64 (vers26b3), which I'll
address in a followup.
Tested no {sparc,sparcv9}-sun-solaris2.11, {i386,amd64}-pc-solaris2.11,
and {x86_64,i686}-pc-linux-gnu.
ld:
* emultempl/solaris2.em (elf_solaris2_before_allocation): Mark
global symbols as generated by linker script.
* testsuite/ld-elfvers/vers.exp: Enable on *-*-solaris2* rather
than sparc*-*-solaris2* only.
gdb: fix forward/reverse search, when no lines are printed
The TUI test added in this commit assumed that the opening '{' of main
would be the first statement line (in DWARF terms), and so, would be
the initial focus of the TUI src window.
This is true for some targets (e.g. x86), but not
others (e.g. AArch64), and so gdb.tui/source-search.exp was seen
failing on at least some AArch64 targets.
Fix this by adding a 'list' command to the test, which forces the
initial window contents to be as needed for the rest of the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33290 Approved-By: Tom de Vries <tdevries@suse.de>
Rainer Orth [Tue, 19 Aug 2025 10:52:41 +0000 (12:52 +0200)]
bfd: Fix Solaris/x86 ELF_MAXPAGESIZE
I noticed that the alignment of the .text and .data sections on
Solaris/x86 doesn't match what /bin/ld does: gld uses the original i386
psABI default of 0x1000, while Solaris has moved to larger values as can
be seen both in the Oracle Solaris 11.4 Linkers and Libraries Guide,
ch. 15, Program Loading and Dynamic Linking, p. 15-6 and the system
headers (<sys/elf_{i386,amd64}.h>) that have
while the Solaris/SPARC values are already correct.
To fix this, on i386 it's sufficient to redefine ELF_MAXPAGESIZE. On
x86_64, unlike i386, ELF_COMMONPAGESIZE is hardcoded as 0x1000, the
default, so setting ELF_MAXPAGESIZE has no effect on ELF_P_ALIGN.
Setting ELF_COMMONPAGESIZE to ELF_MAXPAGESIZE, too, fixes that and
brings both target in sync. ELF_MACHINE_CODE is just set to the original
value again, so it's removed.
Tested on {i386,amd64}-pc-solaris2.11, {i686,x86_64}-pc-linux-gnu, and
amd64-pc-freebsd14.0.
Indu Bhagat [Tue, 19 Aug 2025 08:08:06 +0000 (01:08 -0700)]
binutils: dwarf: fix display of large cfa_offset
eh_frame textual dump was not correct when the cfa_offset is a large
value. The reason is that the dumping code generally assumes the
cfa_offset is an 'int'.
cfa_offset values can be updated by various DWARF opcodes, like:
- DW_CFA_def_cfa, DW_CFA_def_cfa_offset which bring unsigned leb128
cfa_offset
- DW_CFA_def_cfa_sf, DW_CFA_def_cfa_offset_sf which bring signed
leb128 cfa_offset
Internally, the routines in dwarf.c keep the value as 'uint64_t
cfa_offset'. That size of the datatype is expected to work for most of
the real-world cases. Care, however, needs to be taken when it comes
to the signedness of the value. Fix the buggy behavior by adding an
additional field to track whether the value of cfa_offset is signed or
unsigned and display accordingly for "frames-interp" output.
The display of cfa_offset had issues in both "frames-interp" output
(objdump -WF or do_debug_frames_interp) and the "frames" output.
Add two new tests: cfi-common-10.s uses a large positive cfa_offset
(with "frames output), and cfi-x86_64-2.s uses a negative cfa_offset
(with "frames-interp" output).
ChangeLog:
* binutils/dwarf.c (frame_display_row): Update format string
based on signedness.
(display_debug_frames): Track signedness. Also fix display of
cfa_offset using PRIu64 or PRId64 as applicable.
* gas/testsuite/gas/cfi/cfi.exp: Add two new tests.
* gas/testsuite/gas/cfi/cfi-common-10.d: New test.
* gas/testsuite/gas/cfi/cfi-common-10.s: New test.
* gas/testsuite/gas/cfi/cfi-x86_64-2.d: New test.
* gas/testsuite/gas/cfi/cfi-x86_64-2.s: New test.
H.J. Lu [Mon, 18 Aug 2025 13:07:39 +0000 (06:07 -0700)]
Limit BFD_SUPPORTS_PLUGINS check to plugin.h and targets.c
Minimize the BFD_SUPPORTS_PLUGINS check to make code more readable and
maintainable by:
1. Update bfd/plugin.h to define plugin functions as static inline if
BFD_SUPPORTS_PLUGINS is 0.
2. Remove BFD_SUPPORTS_PLUGINS check from all bfd and binutils files
except plugin.h and targets.c.
3. Replace the remaining BFD_SUPPORTS_PLUGINS checks with a function so
that plugin availability is checked at run time.
bfd/
* archive.c: Include plugin.h unconditionally.
(_bfd_compute_and_write_armap): Remove the BFD_SUPPORTS_PLUGINS
check.
* bfd-in.h (bfd_plugin_enabled): New.
* bfd-in2.h: Regenerated.
* elflink.c: Include plugin.h unconditionally.
(elf_link_is_defined_archive_symbol): Remove the
BFD_SUPPORTS_PLUGINS check.
* format.c: Include plugin.h unconditionally.
(bfd_set_lto_type): Remove the BFD_SUPPORTS_PLUGINS check.
(bfd_check_format_matches): Replace the BFD_SUPPORTS_PLUGINS
check with the bfd_plugin_enabled call. Replace plugin_vec
with bfd_plugin_vec. Remove the BFD_SUPPORTS_PLUGINS check.
* plugin.c (bfd_plugin_target_p): Removed.
* plugin.h (bfd_plugin_vec): New.
(bfd_plugin_target_p): Likewise.
(bfd_plugin_set_program_name): New. Static inline
function if BFD_SUPPORTS_PLUGINS is 0.
(bfd_plugin_open_input): Likewise.
(bfd_plugin_set_plugin): Likewise.
(bfd_link_plugin_object_p): Likewise.
(register_ld_plugin_object_p): Likewise.
(bfd_plugin_close_file_descriptor): Likewise.
(bfd_plugin_vec): Likewise.
(bfd_plugin_target_p): Likewise.
* xtensa-dynconfig.c (xtensa_load_config): Replace the
BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call.
ar/
* ar.c: Include plugin.h unconditionally.
(plugin_target): Removed.
(usage): Replace the BFD_SUPPORTS_PLUGINS check with the
bfd_plugin_enabled call.
(ranlib_usage): Likewise.
(decode_options): Likewise.
(ranlib_main): Likewise.
(main): Call bfd_plugin_set_program_name unconditionally.
* nm.c: Include plugin.h unconditionally.
(plugin_target): Removed.
(usage): Replace the BFD_SUPPORTS_PLUGINS check with the
bfd_plugin_enabled call.
(filter_symbols): Remove the BFD_SUPPORTS_PLUGINS check.
(display_rel_file): Likewise.
(main): Call bfd_plugin_set_program_name unconditionally. Replace
the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call.
* objcopy.c: Include plugin.h unconditionally.
(strip_usage): Replace the BFD_SUPPORTS_PLUGINS check with the
bfd_plugin_enabled call.
(copy_archive): Remove the BFD_SUPPORTS_PLUGINS check. Replace
BFD_SUPPORTS_PLUGINS with the bfd_plugin_enabled call.
(copy_file): Likewise.
(strip_main): Likewise.
ld/
* ldfile.c: Include plugin.h unconditionally.
(ldfile_try_open_bfd): Remove the BFD_SUPPORTS_PLUGINS check.
* ldlang.c: Include plugin.h unconditionally.
(plugin_insert): Remove the BFD_SUPPORTS_PLUGINS check.
(plugin_undefs): Likewise.
(open_input_bfds): Likewise.
(lang_check): Likewise.
(lang_gc_sections): Likewise.
(find_next_input_statement): Likewise.
(lang_process): Likewise.
* ldlang.h (lang_input_statement_flags): Likewise.
* ldlex.h (option_values): Likewise.
* ldmain.c: Include plugin.h unconditionally.
(ld_cleanup): Remove the BFD_SUPPORTS_PLUGINS check.
(main): Likewise.
(add_archive_element): Likewise.
* lexsup.c: Include plugin.h unconditionally.
(ld_options): Remove the BFD_SUPPORTS_PLUGINS check.
(parse_args): Replace the BFD_SUPPORTS_PLUGINS check with the
bfd_plugin_enabled call. Remove the BFD_SUPPORTS_PLUGINS check.
(help): Append " (ignored)" to plugin options if bfd_plugin_enabled
return false.
* libdep_plugin.c: Remove the BFD_SUPPORTS_PLUGINS check.
* plugin.c: Likewise.
* testplug.c: Likewise.
* testplug2.c: Likewise.
* testplug3.c: Likewise.
* testplug4.c: Likewise.
Co-Authored-By: Alan Modra <amodra@gmail.com> Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
some linker tests fail to disable address sanitizer options since
proc default_ld_compile has
set ccexe $cc
set ccparm [string first " " $cc]
set ccflags ""
if { $ccparm > 0 } then {
set ccflags [string range $cc $ccparm end]
set ccexe [string range $cc 0 $ccparm]
set cc $ccexe
}
...
set cmd "$cc $flags $ccflags -c $source -o $object"
Compiler flags in $CC and $CXX will be the last ones. Add
CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST to use them in
proc default_ld_compile
set cflag_test ""
set cxxflag_test ""
if {[string match "*++*" $ccexe]} {
append flags " $CXXFLAGS_FOR_TARGET"
set cflag_test "$CXXFLAGS_FOR_TARGET_TEST"
} else {
append flags " $CFLAGS_FOR_TARGET"
set cflag_test "$CFLAGS_FOR_TARGET_TEST"
}
...
set cmd "$cc $flags $ccflags $cflag_test -c $source -o $object"
so that they will be the last flags passed to compiler. Also update
run_ld_link_exec_tests and run_cc_link_tests to make
CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST the last flags
passed to compiler.
* testsuite/config/default.exp (CFLAGS_FOR_TARGET_TEST): New.
(CXXFLAGS_FOR_TARGET_TEST): Likewise.
* testsuite/ld-elf/dwarf.exp (CFLAGS_FOR_TARGET): Renamed to ...
(CFLAGS_FOR_TARGET_TEST): This.
* testsuite/ld-elf/shared.exp: Save, append and restore
CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST for
$build_tests. Save, append and restore CFLAGS_FOR_TARGET_TEST,
instead of CFLAGS_FOR_TARGET, for $dlopen_run_tests.
* testsuite/ld-plugin/plugin.exp (CFLAGS_FOR_TARGET): Renamed to
...
(CFLAGS_FOR_TARGET_TEST): This.
* testsuite/ld-shared/shared.exp (CFLAGS_FOR_TARGET): Renamed to
...
(CFLAGS_FOR_TARGET_TEST): This.
* testsuite/ld-srec/srec.exp (CFLAGS_FOR_TARGET): Renamed to ...
(CFLAGS_FOR_TARGET_TEST): This.
(CXXFLAGS_FOR_TARGET): Renamed to ...
(CXXFLAGS_FOR_TARGET_TEST): This.
* testsuite/lib/ld-lib.exp (default_ld_compile): Append
CFLAGS_FOR_TARGET_TEST/CXXFLAGS_FOR_TARGET_TEST to compiler flags.
(run_ld_link_exec_tests): Append CFLAGS_FOR_TARGET_TEST and
CXXFLAGS_FOR_TARGET_TEST to compiler.
(run_cc_link_tests): Likewise.
Tom de Vries [Mon, 18 Aug 2025 14:17:15 +0000 (16:17 +0200)]
[gdb/testsuite] Fix gdb.tui/tui-mode-switch.exp on aarch64
On aarch64-linux, occasionally I run into these warnings:
...
PASS: gdb.tui/tui-mode-switch.exp: set style enabled off
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/tui-mode-switch.exp: no boo
WARNING: timeout in accept_gdb_output
...
The first in more detail:
...
Box Dump (40 x 1) @ (0, 11):
11 b(gdb) b
WARNING: timeout in accept_gdb_output
...
Fix this by waiting for a prompt after leaving TUI before sending "b".
Also, while we're at it generate a few more passes.
i.e. there's a positive offset from the GOT instead of the expected
negative one. AFAICS that's because there are additional GOT entries on
the Solaris side (printed with elfdump -G since there seems to be no
support for that in either readelf or objdump):
Alice Carlotti [Thu, 7 Aug 2025 17:03:54 +0000 (18:03 +0100)]
gas: Record file name in macro locations
This allows the correct file name to be used when emitting messages for
lines within a macro. The line numbers were already set and displayed
correctly, which resulted in mismatched file names and line numbers.
Alan Modra [Mon, 18 Aug 2025 09:03:54 +0000 (18:33 +0930)]
Don't choose plugin target in binutils/
Instead make bfd_check_format try the plugin target first when the
user hasn't supplied a target.
bfd/
* format.c (bfd_check_format_matches): Try for a plugin target
match first.
* targets.c (bfd_find_target): Don't specially treat "plugin".
binutils/
* ar.c (plugin_target): Delete.
(open_inarch): Don't set target of archive elements.
(replace_members): Use target rather than plugin_target when
opening replacement or additional files.
* arsup.c (plugin_target): Delete. Replace all uses with NULL.
(ar_open): Don't set element target.
* bucomm.h (set_plugin_target): Delete.
* nm.c (plugin_target): Delete.
(display_archive): Don't set element target.
(display_file): Alway use target when opening file.
* objcopy.c (copy_archive): Don't use plugin target for output
elements.
* NEWS: Mention stricter target checking.
H.J. Lu [Fri, 15 Aug 2025 13:18:30 +0000 (06:18 -0700)]
ld: Issue an error if group nested too deeply
If a linker script has a group nested too deeply by mistake, issue an
error instead of hanging forever without outputting any error message.
PR ld/33265
* ldlang.c (MAX_NESTED_GROUP_DEPTH): New.
(open_input_bfds): Add a pointer argument for the nested group
count. Increment the count before the while loop and decrement
it after the loop. Issue an error if the nested group count >=
MAX_NESTED_GROUP_DEPTH when processing input statement.
(lang_process): Update open_input_bfds calls.
(cmdline_emit_object_only_section): Likewise.
* testsuite/ld-scripts/libpr33265-1.a: New file.
* testsuite/ld-scripts/libpr33265-2.a: Likewise.
* testsuite/ld-scripts/libpr33265-3a.a: Likewise.
* testsuite/ld-scripts/libpr33265-3b.a: Likewise.
* testsuite/ld-scripts/libpr33265-3c.a: Likewise.
* testsuite/ld-scripts/pr33265-1.d: Likewise.
* testsuite/ld-scripts/pr33265-2.d: Likewise.
* testsuite/ld-scripts/pr33265-3.d: Likewise.
* testsuite/ld-scripts/script.exp: Run PR ld/33265 tests.
Indu Bhagat [Sun, 17 Aug 2025 22:29:44 +0000 (15:29 -0700)]
libsframe: testsuite: use SFrame V2 specific APIs
Use sframe_encoder_add_funcdesc_v2 instead of sframe_encoder_add_funcdesc.
Similarly, use sframe_decoder_get_funcdesc_v2 instead of
sframe_decoder_get_funcdesc.
sframe_encoder_add_funcdesc, and sframe_decoder_get_funcdesc were first
added for SFrame V1. For the purpose of these testcases, the two V2
APIs are (almost) functionally equivalent. In future, we may want to
make sframe_encoder_add_funcdesc and sframe_decoder_get_funcdesc
internal to libsframe only. Using the V2 named APIs is better for
clarity as well.
Indu Bhagat [Sun, 17 Aug 2025 22:26:34 +0000 (15:26 -0700)]
libsframe: testsuite: reduce usage of magic numbers from encode-1.c
Previously, some of the libsframe tests were updated to reduce the usage
of magic numbers. This patch makes encode-1.c follow similar coding
style as other tests, reducing the number of magic constants.
Alan Modra [Sun, 17 Aug 2025 12:04:17 +0000 (21:34 +0930)]
Sanity check windows resource version len
oss-fuzz generated a total length field of 32, when the header was 40
bytes. Subtracting gave -8ul for the remaining length..
I think we should be sanity checking the total length given in the
header against the remaining buffer length and the size of the header
each time get_version_header is called.
Possibly vallen should be sanity checked inside get_version_header
too, but I'll leave that to someone else.
PR 27686
* resbin.c (bin_to_res_version): Correct error message arg.
Move len vs. buffer length sanity check..
(get_version_header): ..to here. Also sanity check len
against off.
Rainer Orth [Sun, 17 Aug 2025 10:25:43 +0000 (12:25 +0200)]
ld: testsuite: Fix several CTF tests on 32-bit SPARC
Several ld CTF tests FAIL on 32-bit SPARC, e.g.
FAIL: Arrays (conflicted)
The failure mode is always the same:
./tmpdir/array-char-conflicting-1.s: Assembler messages:
./tmpdir/array-char-conflicting-1.s:89: Error: Architecture mismatch on "return %i7+8".
./tmpdir/array-char-conflicting-1.s:89: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
The problem is that gcc emits v8plus code by default, and thus invokes
as with -xarch=v8plus (equivalent to -Av8plus), while the testcase lacks
the latter.
Fixed by setting ASFLAGS to match.
Tested on sparc-sun-solaris2.11, sparc-unknown-linux-gnu,
sparcv9-sun-solaris2.11, and sparc64-unknown-linux-gnu.
Tom de Vries [Sun, 17 Aug 2025 06:57:09 +0000 (08:57 +0200)]
[gdb/testsuite] Use regexp to match $_gdb_{major,minor}
Every time we update the gdb version number, test-case gdb.base/default.exp
needs updating because it matches the values of convenience variables
$_gdb_{major,minor} using hardcoded expected values:
...
{$_gdb_major = 17} \
{$_gdb_minor = 1} \
...
I'm assuming the values were hardcoded because gdb_test_list_exact was used.
Since the previous patch, that's not longer the case, so use regexps instead,
getting rid of this annoyance [1].
Alan Modra [Sun, 17 Aug 2025 05:43:06 +0000 (15:13 +0930)]
buffer overflow in process_sht_group_entries
An oss-fuzz testcase with a SHT_GROUP section named .debug managed to
break objcopy --compress-debug-sections. The underlying problem is
that SEC_DEBUGGING is set by section name tests, thus the SHT_GROUP
section gets compressed. The compressed section data is smaller than
the original section sh_size, and process_sht_group_entries tries to
look at sh_size worth of entries. The patch fixes this mess by simply
not setting SEC_DEBUGGING on SHT_GROUP sections.
Note that it isn't correct to restrict SEC_DEBUGGING to SHT_PROGBITS
sections, as that will break processor/os special sections for debug.
eg. SHT_MIPS_DEBUG.
* elf.c (_bfd_elf_make_section_from_shdr): Don't set
SEC_DEBUGGING on SEC_GROUP sections no matter their name.
Tom de Vries [Sun, 17 Aug 2025 06:32:13 +0000 (08:32 +0200)]
[gdb/testsuite] Handle remote host in some test-cases
I ran test-case gdb.base/default.exp with make-check-all.sh, and noticed a
FAIL with host/target board local-remote-host-native:
...
FAIL: $exp: show convenience ($_colorsupport = "monochrome" not found)
...
The problem is that part of the test-case relies on "setenv TERM dumb", and
setenv, which is a tcl command (which runs on build), only has effect in gdb
(which runs on host), if build == host, in other words, local host.
I grepped for test-cases using setenv, and ran them with the host/target
board, and fixed the FAILs I saw.
All FAILs have the same cause as I described above, except for
proc test_data_directory in gdb.python/py-parameter.exp, which handles files
assuming local host. I chose to leave it that way, and bail out but add a
comment.
Implementationwise, the change to test-case gdb.base/default.exp is the most
intrusive: it replaces a use of proc gdb_test_list_exact with a use of proc
gdb_get_lines_no_pass, because it allows specifying a regexp match.
In the process, I found out gdb_test_list_exact has a bug, filed as PR33038.
Because of this bug, I had to add matching of convenience variable $_tbl.
Tom de Vries [Sat, 16 Aug 2025 18:32:37 +0000 (20:32 +0200)]
[gdb/testsuite] Fix TUI tests on freebsd
While re-testing the TUI tests on x86_64-freebsd, I found that commit 06a53717f7c ("[gdb/testsuite] Handle unrecognized escape sequences better in
tuiterm") broke most test-cases.
Fix this by rewriting this gdb_test_multiple clause:
...
-re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" {
...
into:
...
-re "^($re_csi_cmd)" {
...
-re "^($re_csi_args*)($re_csi_cmd)" {
...
-re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" {
...
Tom de Vries [Sat, 16 Aug 2025 07:18:45 +0000 (09:18 +0200)]
[gdb/testsuite] Handle unrecognized escape sequences better in tuiterm
When encountering an unrecognized escape sequence in Term::accept_gdb_output,
a warning is issued:
...
WARNING: timeout in accept_gdb_output
...
and 0 is returned.
Subsequent calls run into the same problem, so matching doesn't progress.
Consequently, figuring out what the unrecognized escape sequence actually is
depends on analyzing gdb's output as echoed into gdb.log.
In the test added in this commit, gdb (well, a script gdb.tcl emulating gdb)
outputs escape sequence "ESC ( B", which doesn't show up in recognizable form
in gdb.log:
...
foo^M^M
...
and as mentioned the tuiterm screen only show:
...
foo
...
because matching doesn't progress beyond the unrecognized sequence.
Fix this by rewriting accept_gdb_output to match gdb output using a phased
approach that echoes unmatched escape sequences, giving us instead on the
tuiterm screen:
...
foo^[(B
...
[ Since "ESC ( B" is now supported, the test-case has been updated to use
"ESC ( % 5" instead. ]
Tom de Vries [Sat, 16 Aug 2025 07:18:45 +0000 (09:18 +0200)]
[gdb/testsuite] Move setting of Term::_last_char to Term::_insert
The variable Term::_last_char is meant to represent the last char inserted by
Term::_insert, but setting it is done alongside the only call to _insert in
lib/tuiterm.exp:
...
_insert $expect_out(0,string)
variable _last_char
set _last_char [string index $expect_out(0,string) end]
...
Fix this by moving the setting of _last_char to inside _insert.
Alan Modra [Mon, 4 Aug 2025 05:59:22 +0000 (15:29 +0930)]
Make bfd_check_format better respect given target
bfd_check_format currently does not take much notice of the target
set in its abfd arg, merely checking that target first if
target_defaulted is false. As the comment says this was due to
complications with archive handling which I think was fixed in
commit f832531609d0. It should now be possible to just check the
given target, except for linker input files. This will speed checking
the target of the first file in archives, which is done in the process
of matching archive targets.
This will no doubt expose some misuse of target options, as found in
the binutils "efi app" tests.
The stricter checking also exposed some errors. Cris targets gave
"FAIL: objcopy decompress debug sections in archive (reason: unexpected output)"
"FAIL: objcopy decompress debug sections in archive with zlib-gabi (reason: unexpected output)"
without the bfd_generic_archive_p fix. cris has a default target of
cris-aout which doesn't match objects for any of the cris-elf or
cris-linux targets. The problem here was that checking the first
object file in archives didn't match but a logic error there meant
bfd_error_wrong_object_format wasn't returned as it should be. There
was also a possibility of bfd_error_wrong_object_format persisting
from one target check to the next.
bfd/
* archive.c (bfd_generic_archive_p): Correct object in archive
target test.
* format.c (bfd_check_format_matches_lto): Try to match given
target first even when target_defaulted is set. Don't try
other targets if !target_defaulted except for linker input.
Clear bfd_error before attempted target matches.
* targets.c (bfd_find_target): Set target_defaulted for
plugin target.
binutils/
* bucomm.h (set_plugin_target): Set target_defaulted.
* testsuite/binutils-all/aarch64/pei-aarch64-little.d: Don't
wrongly specify both input and output target, just specify
output.
* testsuite/binutils-all/loongarch64/pei-loongarch64.d: Likewise.
* testsuite/binutils-all/riscv/pei-riscv64.d: Likewise.
Alan Modra [Tue, 12 Aug 2025 13:16:36 +0000 (22:46 +0930)]
archives and plugin target
Automatically choosing "plugin" for the archive target when plugins
are enabled can result in making archives as specified by the plugin
target vec, ie. COFF style archives (also used by most ELF
binutils targets). This is wrong for aix, hpux, vms, aout, macho
and possibly other targets, if compatibility with target system
archives matters.
This patch removes archive support entirely from the plugin target.
That means an archive will never get past bfd_check_format with a
target of plugin_vec, even if it is opened using "plugin". Instead,
archives will have their elements opened using the plugin target
selected is such a way that the plugin target will be tried first in
bfd_check_format and then continue to try other targets if that fails.
The patch tries to avoid opening archives using "plugin" because that
is guaranteed to fail the first target check in bfd_check_format, but
mm.c still does so, and nested archives will also be opened using
"plugin".
The patch also fixes poor arsup.c plugin support.
bfd/
* plugin.c (plugin_vec): Remove archive support.
* configure.ac: Remove plugin archive warning, and don't disable
plugins by default on anything but aout targets.
* configure: Regenerate.
binutils/
* bucomm.h (set_plugin_target): New inline function.
* ar.c: Remove unneeded forward declarations.
(open_inarch): Don't use "plugin" if defaulting target when
opening an archive, use "plugin" when opening elements.
(replace_members): Use "plugin" when opening replacement or
additional elements.
* arsup.c: Remove unneeded forward declarations.
(plugin_target): New.
(ar_open): Don't open archives using "plugin", use it when
opening elements.
(ar_addmod): Use plugin_target.
(ar_replace): Use plugin_target when opening replacement or
additional elements.
(ar_extract): Don't bfd_openr.
* nm.c (display_archive): Open archive elements using the
"plugin" target.
Indu Bhagat [Fri, 15 Aug 2025 17:28:59 +0000 (10:28 -0700)]
gas: sframe: const ptrs for args and local vars where applicable
Use const pointers for function arguments and local vars where
applicable. 'cfi_insn' contains the DWARF CFI instruction data which,
for the purpose of SFrame generation, is read-only. Similarly, some
getter APIs and output related APIs now document their argument as
read-only.
While at it, also remove the ATTRIBUTE_UNUSED from argument xlate_ctx in
sframe_xlate_do_register () because the argument is indeed conditionally
used.
Andrew Burgess [Wed, 13 Aug 2025 14:29:38 +0000 (15:29 +0100)]
gdb: fix forward/reverse search, when no lines are printed
This commit continues the theme of the previous commit, restoring the
behaviour of forward-search and reverse-search to what it was before
GDB 10, but adds tests to guard the behaviour. I believe this
restored behaviour is inline with the documentation of the two search
commands.
This time, I'm looking at what happens when no source lines end up
being printed. This can happen for two reasons, a request is made to
list a line number outside the file, or, a request is made to list a
reverse series of lines (e.g. line 100 to line 50).
Before GDB 10, a 'list' command that resulted in no lines being
printed would not change the notion of the last line listed. As a
result a future forward or reverse search would continue from the
previous last line. As an example, here's current master branch
behaviour:
(gdb) list 50
45 /* Line 45 */
46 /* Line 46 */
47 /* Line 47 */
48 /* Line 48 */
49 /* Line 49 */
50 /* Line 50 */
51 /* Line 51 */
52 /* Line 52 */
53 /* Line 53 */
54 /* Line 54 */
(gdb) list 1000
Line number 995 out of range; long-file.c has 101 lines.
(gdb) forward-search Line
Expression not found
(gdb)
But on GDB 9, the forward-search instead acts like this:
(gdb) forward-search Line
55 /* Line 55 */
(gdb)
Similarly, reverse-search reports "Expression not found" on master,
but would return line 53 on GDB 9.
The reverse-search result for master might be a little surprising,
surely, if we tried to list line 1000, then every line before that
should be searched.
The problem is that last_line_listed ends up being set to 995 (which
is 1000 minus half the listsize). Then, when the reverse-search kicks
in GDB tried to read line 994, fails, and abandons the search.
This commit wants last_line_listed updated so that the search
functions would work correctly (see notes below) when GDB is in TUI
mode. Without this commit last_line_listed would never be updated in
TUI mode, and so every search would effectively start from the
beginning of the file.
The fix I propose is to delay updating the current_source_location
until the source code has been printed successfully. That is, just
before we leave print_source_lines_base, after a successful print.
This update happens inside the 'if (noprint)' block, a the return here
isn't really considered an error condition, this is a specific choice
_not_ to print the source code.
However, in the 'if (stopline <= line)' block, the
current_source_location is not updated, that's because this 'if'
represents an error condition.
The last_line_listed is also updated at the end of the function still,
which is the path taken in CLI mode when source lines are actually
printed.
I've added some CLI tests to confirm the forward/reverse search
behaviour. And I've also added some TUI tests to check search works
within the TUI. The TUI tests cover more than just the fix for this
issue.
There is one slight issue with the TUI. At this point you should
definitively go read the previous commit. OK, so, the forward and
reverse searches are supposed to search from the last line listed.
The previous commit fixed this for CLI mode, but for the TUI the
last_line_listed is _still_ being set to the first line displayed.
The problem is that print_source_lines_base doesn't know the size of
the TUI src window, and so, doesn't know what the last line listed
will be, and so cannot set last_line_listed correctly.
This indicates to me that setting last_line_listed from the core GDB
code is likely the wrong approach, or, at least, the way it is done
now is the wrong approach.
Currently the 'list' command converts the arguments into a set of
lines to be printed based on the CLI environment, e.g. using the
'listsize' if necessary. But the 'listsize' doesn't make sense for
the TUI, where the src window height really overrides the 'listsize'.
The list command then calls the core GDB print_source_lines
function to do the printing, but for the TUI we don't actually print
anything, we just update the internal state (including
last_line_listed) and are done.
I think that the current interpreter, CLI or TUI, needs to get
involved in the 'list' command implementation much sooner. This would
allow, for example, the CLI to use 'listsize' and the TUI to use the
src window height. It might then be up to the interpreter to track
the last line listed maybe?
I mention all this only to acknowledge this issue. The problem
existed before this commit, and continues to exist after this commit.
I'm not proposing to fix this problem right now.
The TUI forward/reverse search continue to work as well as they have
since commit 8b7fcda2744.
The documentation for these commands is pretty clear:
'forward-search REGEXP'
'search REGEXP'
The command 'forward-search REGEXP' checks each line, starting with
the one following the last line listed, for a match for REGEXP. It
lists the line that is found. You can use the synonym 'search
REGEXP' or abbreviate the command name as 'fo'.
'reverse-search REGEXP'
The command 'reverse-search REGEXP' checks each line, starting with
the one before the last line listed and going backward, for a match
for REGEXP. It lists the line that is found. You can abbreviate
this command as 'rev'.
Both searches should start searching based on the last line listed.
But currently:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) forward-search Line
4 /* Line 4 */
(gdb)
This should have found line 11. And for reverse-search:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) reverse-search Line
Expression not found
(gdb)
The reverse-search should have returned line 9.
This new behaviour started with the above commits in GDB 10. On GDB 9
we see behaviour that matches the documentation.
Where the forward and reverse searches start from is controlled by a
global, last_line_listed, found in source.c.
Before commit 1dd588507782, in print_source_lines_base, the
last_line_listed variable was updated as each source line was printed,
and it was updated with the current line being printed.
After commit 1dd588507782, the current symtab and line are moved into
a current_source_location object, but the symtab and line member
variables are public. The last_line_listed is still set based on the
value held in the current_source_location object, and this object is
updated each time around the source printing loop. So despite the
restructure, the logic, and behaviour, is unchanged.
After commit a75cd9a2c129, the member variables of
current_source_location are now private. The source printing loop in
print_source_lines_base uses a local variable, new_lineno, to track
the current source line number, and updates the
current_source_location at the end of print_source_lines_base.
However, last_line_listed is still updated inside the loop, using the
original line value within current_source_location, which is no longer
being updated each time around the loop.
As a result, last_line_listed is now just the first line listed!
This didn't show up in testing because, as far as I can tell, the
last_line_listed is _only_ used for forward and reverse searching, and
the testing for these commands is minimal.
In this commit I move the setting of last_line_listed outside of the
source printing loop, this only needs to be updated once, when we have
finished printing the source lines.
I've also done a couple of other cleanups in the same area, I moved
'buf' a local variable into the most inner scope where it is required,
and I converted the 'while' loop into a 'for' loop, moving the
increment out of the loop body.
There's now a test which does some more detailed checks of the forward
and reverse search commands.
Jan Beulich [Fri, 15 Aug 2025 10:22:03 +0000 (12:22 +0200)]
bfd/TIC4x: correct COFF swapping functions for mixed-endianness binaries
Commit 3fa785190a4f ("Altered the CREATE_xxx_COFF_TARGET_VEC macro
arguments") pretty clearly screwed up the data swapping functions in the
new CREATE_BIGHDR_COFF_TARGET_VEC() macro. Since the flaw went unnoticed,
and since the correction doesn't cause any testsuite fallout, it further
seems pretty clear that all of this is entirely untested and largely
unused.
Jan Beulich [Fri, 15 Aug 2025 10:21:24 +0000 (12:21 +0200)]
bfd/ELF/PPC: make ppc_build_one_stub()'s stub_str[] static
There's no reason to have the compiler materialize objects onto the
stack.
In fact we can save some space and a level of indirection (and hence
relocation entries in the final binary) by converting to an array of
char[12] or larger. Pick char[16] for easier / faster calculations.
Jan Beulich [Fri, 15 Aug 2025 10:19:59 +0000 (12:19 +0200)]
gas/ELF: allow specifying entity size for arbitrary sections
The spec doesn't tie entity size to just SHF_MERGE and SHF_STRINGS
sections. Introduce a new "section letter" 'E' to allow recording (and
checking) of entity size even without 'M' or 'S'.
Jan Beulich [Fri, 15 Aug 2025 10:18:34 +0000 (12:18 +0200)]
gas/ELF: re-work SHF_GNU_* handling
Indicate to obj_elf_parse_section_letters() whether to recognize GNU-
specific flags by conditionally passing NULL in place of a pointer to
the GNU attributes. This way wrong use of d and R can be diagnosed just
like any other use of unrecognized letters.
Furthermore adjust the md_elf_section_letter() interface: Have targets
merely return the extra letters they support. There's no point having
them customize the entire diagnostic. Even more so that additions in
common code would then reflecting in every target's diagnostic as well,
which - as can be seen - wasn't always properly done.
There's also no reason for wrong letters to be a fatal error; switch to
as_bad() while making other adjustments there.
While making the target specific adjustments, also drop IA-64's dead
handling of 'o' (SHF_LINK_ORDER), which has been covered by common code
for a long time.
Also re-arrange the switch() in obj_elf_parse_section_letters() to be
alphabetically sorted again.
Jan Beulich [Fri, 15 Aug 2025 10:18:03 +0000 (12:18 +0200)]
gas/ELF: drop bogus check for ELFOSABI_STANDALONE
obj_elf_parse_section_letters() checking for that ABI, when the checking
at the bottom of obj_elf_section() and the logic in
_bfd_elf_final_write_processing() don't, makes no sense. Either
STANDALONE is meant to be GNU-ish, or it is not, I would think. Drop the
one inconsistent check.
If it was not GNU-ish (as the other two locations suggest), what did the
section23b testcase actually mean to check? The numeric attribute value
0x200000 has an entirely unknown (or more precisely, OS-defined, which
we may or may not know of) meaning then, so ought to be accepted. If it
was GNU-ish, the other testcase, elf/section23a, would want running for
those targets as well, and the testcase in question would still be wrong
to have. Hence that testcase is removed, and section23a is renamed to
just section23.
Jan Beulich [Fri, 15 Aug 2025 10:16:22 +0000 (12:16 +0200)]
bfd: have objcopy retain unknown ELF section flags
Silently zapping them is certainly wrong. When they're not replaced due
to user request, simply keeping them may not always be correct (we don't
know what such a flag means, after all), but is certainly at least
closer to having the output object still represent what the input object
had.
This introduces new binutils/ testsuite failures, but only for two
targets where most of the tests there fail anyway (amdgcn-elf and
nfp-elf), due to there not being an assembler available.
projects / thirdparty / binutils-gdb.git / log
