| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix clean_restart <absolute filename> in the test-case in gdb.replay.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.reverse.
Tested on:
- x86_64-linux, target boards unix and unix/-m32
- aarch64-linux
- ppc64le-linux
- s390x-linux
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.rocm.
Since these test-cases are unsupported for me, do the simple substitution:
...
clean_restart $binfile
->
clean_restart
gdb_load $binfile
...
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.server.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.testsuite.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.threads.
Tested on x86_64-linux.
|
|
Tom de Vries ran the testsuite on msys2-ucrt64 with mount point map:
...
/bin C:/msys64/usr/bin
/c C:
/ C:/msys64
...
and ran into the problem that host_file_normalize didn't translate:
...
/home/user/gdb/build/gdb/testsuite/temp/n/x
...
into:
...
C:/msys64/home/user/gdb/build/gdb/testsuite/temp/n/x
...
The problem is that host_file_normalize_mingw mishandles a
file/directory under the root mount point. A simpler reproducer is
"/foo". If we add that as a test to
gdb.testsuite/mount-point-map.exp, we see:
input: /foo
expected: C:/msys64/foo/
got: /foo
FAIL: gdb.testsuite/mount-point-map.exp: /foo
For a mount point that ends in /, this line in
host_file_normalize_mingw:
} elseif {[string index $filename $mount_len] eq "/"} {
... is always false, because the character at $mount_len is the one
_after_ the slash.
Notice that the "/" mount point is the only one that ends in "/".
This is even if you try to create one explicitly with a trailing /.
On MSYS2:
$ mount c:/foo /foo/
mount: warning - /foo/ does not exist.
$ mount
C:/foo on /foo type ntfs (binary,user)
...
So fix this by special casing the "/" mount point.
And then... while playing with fixing this, I noticed I had done
something strange with this case:
if {[string length $filename] == $mount_len} {
return "$win_filename/"
The intent was to append the slash when the mount is a drive letter,
like 'cygpath -ma' does:
$ cygpath -ma /c
C:/
Other cases do not get a trailing slash:
$ cygpath -ma /c/foo
C:/foo
I think this is because on Windows, every drive letter has a current
directory, and really "C:" means "current directory of drive letter
C:", not "root of C:". Resolving it to "C:/" makes it unambiguous.
However, I mishandled that in a63213cd374d ('MSYS2+MinGW testing: Unix
<-> Windows path conversion'). The original version of that patch
when I posted it to the mailing list only supported drive mounts,
which turned out incorrect, and then I generalized it to work with all
mount points before it was merged. In the process, I inadvertently
made the code append the slash whenever the input filename matches a
mount exactly, any mount.
I also now noticed that TCL's "file normalize" on Linux always removes
the trailing slash, and since host_file_normalize is an abstraction
for it, I think host_file_normalize_mingw should do the same.
Likewise for duplicate slashes, "file normalize" gets rid of them.
Fix all this in host_file_normalize_mingw, and add corresponding tests
to gdb.testsuite/mount-point-map.exp.
I smoke tested this here with a few of the testcases that required
tweaking in the patch that added host_file_normalize, like
gdb.base/source-dir.exp and gdb.base/fullname.exp and they still pass.
Tom ran gdb.testsuite/mount-point-map.exp on both x86_64-linux and
msys2-ucrt64, and it passed in both cases.
Change-Id: I852a8662f0cb8b0ee4e683e9b157618cf6955477
|
|
Proc host_file_normalize is structured like this:
...
proc host_file_normalize {filename} {
if {[ishost *-*-mingw*]} {
...
}
return [file normalize $filename]
...
so a testcase exercising the mingw specific part can only be run on a
mingw host.
Factor out a new proc host_file_normalize_mingw, which can be used on
any host platform.
Add testcase gdb.testsuite/mount-point-map.exp, exercising
host_file_normalize_mingw.
Tested on aarch64-linux, x86-64-linux, msys2-ucrt64, and msys2-mingw.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ia130de5c12c940852b6367c422d04896863bfc02
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.trace.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.tui.
Tested on x86_64-linux.
|
|
PR gdb/33069 reports the following behavior:
...
$ gdb -q ls -ex starti -ex "b *1"
Reading symbols from ls...
(No debugging symbols found in ls)
Starting program: /usr/bin/ls
Program stopped.
0x00007ffff7fe4f00 in _start () from /lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x1
(gdb) p (int)strlen("abc")
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1
Command aborted.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(malloc@plt) will be abandoned.
When the function is done executing, GDB will silently stop.
[1]+ Stopped gdb -q ls -ex starti -ex "b *1"
$ fg
gdb -q ls -ex starti -ex "b *1"
(gdb)
...
with gdb being unresponsive to further input.
PR gdb/33068 reports a similar problem, but using gdbserver, and in that case
gdb doesn't go into the background, but is likewise unresponsive.
This is a regression since commit b1c0ab20809 ("gdb: avoid double stop after
failed breakpoint condition check"), and consequently since release gdb 14.1.
The commit changed this in run_inferior_call:
...
if (current_ui->prompt_state == PROMPT_BLOCKED)
- current_ui->unregister_file_handler ();
- else
- current_ui->register_file_handler ();
+ {
+ if (call_thread->thread_fsm ()->finished_p ())
+ async_disable_stdin ();
+ else
+ async_enable_stdin ();
+ }
...
which means current_ui->register_file_handler is no longer called in the
current_ui->prompt_state == PROMPT_NEEDED case.
Fix this by:
- restoring this behavior, fixing the unresponsiveness, and
- adding target_terminal::ours alongside it, fixing the problem that gdb goes
into the background.
Add a new test-case gdb.base/infcall-failure-2.exp, a regression test for the
unresponsiveness issue. The problem of gdb going into the background did not
reproduce in the test-case.
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33068
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33069
|
|
Change-Id: Ib15ecd6c03fce9d50a0121bbcb910e2fa05cc5f9
|
|
Change-Id: Ifb1dab85891200cadb4b4f59661450a03b0c6abd
|
|
The GCSPR is almost always updated implicitly by the hardware, so the
compiler doesn't generate DWARF unwind information for it. Therefore add
an unwinding function that calculates the value of the GCSPR in the
previous frame based on its value in this frame. Some sanity checking is
done by confirming that the calculated value is within a Guarded Control
Stack memory area.
This function is the same as amd64_linux_dwarf2_prev_ssp, written by
Christina Schimpe to unwind Intel's SSP register.
The gdb.arch/aarch64-gcs-return.exp testcase is lightly adapted from
gdb.arch/amd64-shadow-stack-cmds.exp.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
When doing displaced step on a branch and link instruction with the Guarded
Control Stack enabled, it's necessary to manually push and pop the GCS
entry for the function call since GDB writes a simple branch instruction
rather than a branch and link instruction in the displaced step buffer.
The testcase exercises GCS with displaced stepping by putting the
breakpoint on the bl instruction to force GDB to copy it to the
displaced stepping buffer. In this situation GDB needs to manually
manage the Guarded Control Stack.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
The signal frame can have a GCS context, so teach GDB how to use it.
Also, there's a new SEGV sigcode when the inferior does an illegal
memory access in the Guarded Control Stack, so display a message when
that is the case.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
Add the org.gnu.gdb.aarch64.gcs feature with the GCSPR register, and the
org.gnu.gdb.aarch64.gcs.linux feature with "registers" to represent the
Linux kernel ptrace and prctl knobs that enable and lock specific GCS
functionality.
This code supports GCS only in Linux userspace applications, so the
GCSPR that is exposed is the one at EL0.
Also, support for calling inferior functions is enabled by adding an
implementation for the shadow_stack_push gdbarch method.
If for some reason a target description contains the
org.gnu.gdb.aarch64.gcs feature but not the
org.gnu.gdb.aarch64.gcs.linux feature then GCS support is disabled and
GDB continues the debugging session. Features that need GCS
support (for example, calling inferior functions) will not work and the
inferior will get a segmentation fault signal instead. There's a
testcase for this scenario but it only checks the native debugging case,
even though in practice this problem would only occur in remote
debugging with a broken stub or gdbserver. I tested manually with a
gdbserver hacked to send a broken target description and it worked as
described.
Testcases gdb.arch/aarch64-gcs.exp, gdb.arch/aarch64-gcs-core.exp and
gdb.arch/aarch64-gcs-wrong-tdesc.exp are included to cover the added
functionality.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
Currently, if displaced stepping is active and the single stepped instruction
is a call instruction, the return address atop the stack is the address
following the copied instruction. However, to allow normal program execution
it has to be the address following the original instruction. Due to that
reason, the return address is corrected in amd64_displaced_step_fixup and
i386_displaced_step_fixup.
For programs that are shadow-stack enabled we see a control-protection
exception, as the address on the shadow stack does not match the address
atop the stack.
Fix this by correcting the shadow stack top address as well.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This patch enables inferior calls to support Intel's Control-Flow
Enforcement Technology (CET), which provides the shadow stack feature
for the x86 architecture.
Following the restriction of the linux kernel, enable inferior calls
for amd64 only.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Unwind the $pl3_ssp register.
We now have an updated value for the shadow stack pointer when
moving up or down the frame level. Note that $pl3_ssp can
become unavailable when moving to a frame before the shadow
stack enablement. In the example below, shadow stack is enabled
in the function 'call1'. Thus, when moving to a frame level above
the function, $pl3_ssp will become unavaiable.
Following the restriction of the linux kernel, implement the unwinding
for amd64 linux only.
Before this patch:
~~~
Breakpoint 1, call2 (j=3) at sample.c:44
44 return 42;
(gdb) p $pl3_ssp
$1 = (void *) 0x7ffff79ffff8
(gdb) up
55 call2 (3);
(gdb) p $pl3_ssp
$2 = (void *) 0x7ffff79ffff8
(gdb) up
68 call1 (43);
(gdb) p $pl3_ssp
$3 = (void *) 0x7ffff79ffff8
~~~
After this patch:
~~~
Breakpoint 1, call2 (j=3) at sample.c:44
44 return 42;
(gdb) p $pl3_ssp
$1 = (void *) 0x7ffff79ffff8
(gdb) up
55 call2 (3);
(gdb) p $pl3_ssp
$2 = (void *) 0x7ffff7a00000
(gdb) up
68 call1 (43i);
(gdb) p $pl3_ssp
$3 = <unavailable>
~~~
As we now have an updated value for each selected frame, the
return command is now enabled for shadow stack enabled programs, too.
We therefore add a test for the return command and shadow stack support,
and for an updated shadow stack pointer after a frame level change.
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Intel's Control-Flow Enforcement Technology (CET) provides the shadow
stack feature for the x86 architecture.
This commit adds support to write and read the shadow-stack node in
corefiles. This helps debugging return address violations post-mortem.
The format is synced with the linux kernel commit "x86: Add PTRACE
interface for shadow stack". As the linux kernel restricts shadow
stack support to 64-bit, apply the fix for amd64 only.
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
---
The code and testcase are lightly adapted from:
[PATCH v3 5/9] GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support
https://sourceware.org/pipermail/gdb-patches/2025-June/218892.html
|
|
This patch adds the user mode register PL3_SSP which is part of the
Intel(R) Control-Flow Enforcement Technology (CET) feature for support
of shadow stack.
For now, only native and remote debugging support for shadow stack
userspace on amd64 linux are covered by this patch including 64 bit and
x32 support. 32 bit support is not covered due to missing Linux kernel
support.
This patch requires fixing the test gdb.base/inline-frame-cycle-unwind
which is failing in case the shadow stack pointer is unavailable.
Such a state is possible if shadow stack is disabled for the current thread
but supported by HW.
This test uses the Python unwinder inline-frame-cycle-unwind.py which fakes
the cyclic stack cycle by reading the pending frame's registers and adding
them to the unwinder:
~~~
for reg in pending_frame.architecture().registers("general"):
val = pending_frame.read_register(reg)
unwinder.add_saved_register(reg, val)
return unwinder
~~~
However, in case the python unwinder is used we add a register (pl3_ssp) that is
unavailable. This leads to a NOT_AVAILABLE_ERROR caught in
gdb/frame-unwind.c:frame_unwind_try_unwinder and it is continued with standard
unwinders. This destroys the faked cyclic behavior and the stack is
further unwinded after frame 5.
In the working scenario an error should be triggered:
~~~
bt
0 inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:49^M
1 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M
2 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M
3 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M
4 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M
5 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5
~~~
To fix the Python unwinder, we simply skip the unavailable registers.
Also it makes the test gdb.dap/scopes.exp fail. The shadow stack feature is
disabled by default, so the pl3_ssp register which is added with my CET
shadow stack series will be shown as unavailable and we see a TCL error:
~~
>>> {"seq": 12, "type": "request", "command": "variables", "arguments": {"variablesReference": 2, "count": 85}}
Content-Length: 129^M
^M
{"request_seq": 12, "type": "response", "command": "variables", "success": false, "message": "value is not available", "seq": 25}FAIL: gdb.dap/scopes.exp: fetch all registers success
ERROR: tcl error sourcing /tmp/gdb/testsuite/gdb.dap/scopes.exp.
ERROR: tcl error code TCL LOOKUP DICT body
ERROR: key "body" not known in dictionary
while executing
"dict get $val body variables"
(file "/tmp/gdb/testsuite/gdb.dap/scopes.exp" line 152)
invoked from within
"source /tmp/gdb/testsuite/gdb.dap/scopes.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /tmp/gdb/testsuite/gdb.dap/scopes.exp"
invoked from within
"catch "uplevel #0 source $test_file_name" msg"
UNRESOLVED: gdb.dap/scopes.exp: testcase '/tmp/gdb/testsuite/gdb.dap/scopes.exp' aborted due to Tcl error
~~
I am fixing this by enabling the test for CET shadow stack, in case we
detect that the HW supports it:
~~~
# If x86 shadow stack is supported we need to configure GLIBC_TUNABLES
# such that the feature is enabled and the register pl3_ssp is
# available. Otherwise the reqeust to fetch all registers will fail
# with "message": "value is not available".
if { [allow_ssp_tests] } {
append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK"
}
~~~
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
The change comes from ARM's GCS series:
[PATCH v3 5/9] GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support.
We need it for testing coredump files, too. So include it in this patch series.
Abridged-by: Christina Schimpe <christina.schimpe@intel.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
---
This is the patch mentioned above:
https://sourceware.org/pipermail/gdb-patches/2025-June/218892.html
Minus everything except for the change in gdb.exp's corefind procedure.
|
|
When running test-case gdb.dwarf2/dw2-linkage-name-trust.exp with target board
cc-with-gdb-index, I get:
...
(gdb) file dw2-linkage-name-trust^M
Reading symbols from dw2-linkage-name-trust...^M
warning: .gdb_index address table has a range (0x4006ac - 0x4006cc) that \
overlaps with an earlier range, ignoring .gdb_index^M
(gdb) delete breakpoints^M
...
Fix this by compiling with nodebug.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/33315
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33315
|
|
When running test-case gdb.dwarf2/dw2-entry-points.exp with target board
cc-with-gdb-index, I get:
...
(gdb) file dw2-entry-points^M
Reading symbols from dw2-entry-points...^M
warning: .gdb_index address table has a range (0x40066c - 0x4006e4) that \
overlaps with an earlier range, ignoring .gdb_index^M
(gdb) delete breakpoints^M
...
Fix this by copying function bar_helper to barso_helper, and using it where
appropriate.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/33315
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33315
|
|
I don't know if this is true on all platforms, but from what I can see
on Linux, the dump commands don't output anything. Use
gdb_test_no_output, which should be a bit more robust than checking for
some specific error patterns.
Change-Id: Idc82298c4752ba7808659dfea2f8324c8a97052d
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Even though the core_find proc will log a warning, it's better to log
"untested" and then terminate the test. This will help to avoid
silently skipped tests, when running the testsuite. Most of the tests
already do that. This patch adds the missing ones.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
|
|
While looking at test-case gdb.tui/tui-missing-src.exp I noticed that
gdb_compile is used to compile multiple sources:
...
if { [gdb_compile "${srcfiles}" "${binfile}" \
executable {debug additional_flags=-O0}] != "" } {
...
meaning there are no separate compile and link steps, as is required for
fission [1].
Fix this by using build_executable instead.
Tested on aarch64-linux.
[1] https://gcc.gnu.org/wiki/DebugFission
|
|
The Linaro CI reported a regression in test-case
gdb.dwarf2/macro-source-path-clang14-dw4.exp due to recent commit 81e5a23c7b8
("[gdb/testsuite] Fix require dwarf2_support check in some test-cases").
The problem is that the "require dwarf2_support" in its new location doesn't
work because proc dwarf2_support is not defined.
I didn't notice this because I tested all gdb.dwarf2 test-cases together, and
a different test-case had already imported the proc.
Fix this by moving load_lib dwarf.exp earlier.
Tested on x86_64-linux.
|
|
Similar to a previous patch, if the gdb executable is in fact a libtool
wrapper, we need to get the path to the real executable to load it in
the top-level gdb.
With this change, the test runs on Cygwin, although I do see two
failures:
FAIL: gdb.gdb/index-file.exp: debug_names files are identical
FAIL: gdb.gdb/index-file.exp: debug_str files are identical
Change-Id: Ie06d1ece67e61530e5b664e65b5ef0edccaf6afa
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
When running gdb.gdb/selftest.exp on Cygwin, the test eventually times
out on this command:
(gdb) PASS: gdb.gdb/selftest.exp: printed version as pointer
continue
Continuing.
[New Thread 4804.0x1728]
[New Thread 4804.0x2f24]
[New Thread 4804.0x934]
[New Thread 4804.0x23a8]
[New Thread 4804.0x2cf4]
[New Thread 4804.0x1408]
[New Thread 4804.0x2c90]
[New Thread 4804.0xc58]
[New Thread 4804.0x1d40]
[New Thread 4804.0x1824]
GNU gdb (GDB) 17.0.50.20250530-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) [New Thread 4804.0x2c64]
[New Thread 4804.0x23c4]
[New Thread 4804.0x2814]
[Thread 4804.0x1200 exited with code 0]
[Thread 4804.0x293c exited with code 0]
[Thread 4804.0x2c9c exited with code 0]
FAIL: gdb.gdb/selftest.exp: xgdb is at prompt (timeout)
The problem is the new thread notification, and the fact that the test
expects the prompt to be the last thing in the buffer. To avoid the
thread events interfering with the test, disable them, they are not
useful here.
With this patch, gdb.gdb/selftest.exp mostly runs fine on Cygwin, the
only remaining problem appears to be:
(gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process
signal SIGINT
Continuing with signal SIGINT.
PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process, top GDB message
FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process, bottom GDB message (timeout)
Change-Id: I0b1df0503c1961c042c8de559b4d223c5d3cb95c
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
When building GDB on Cygwin, gdb/gdb.exe is a libtool wrapper (which
happens to be a PE executable). The real executable is at
gdb/.libs/gdb.exe. The "does gdb have debug info test" that
_selftest_setup does is bogus, because it loads the libtool wrapper
(which doesn't have debug info), doesn't see any debug info, and thus
the test is skipped.
The "correct" way to deal with libtool wrappers is to run the shell
command you want to run under `libtool --mode=execute`. That will
replace any path resembling to a libtool wrapper with the real
executable path. But it will also add to the environment the library
paths necessary for this executable to find the libraries it needs.
Therefore, modify the `do_self_tests` proc to:
- run the top-level GDB commands under `libtool --mode=execute`
- pass the path to the inferior GDB on the command-line of the
top-level, so that it gets replaced with the real executable's path
However, the "file" command was previously used to detect the presence
of debug info in the GDB executable. It's not easy to implement this
check when loading the executable directly on the command line. So, add
a separate proc, _selftest_check_executable_debug_info, that spawns a
temporary GDB and does the debug info check through the file command.
This proc uses libtool to obtain the path to the real executable.
When building, we use the bundled libtool.m4 at the top of the tree.
This means that the libtool system package, and therefore the libtool
binary, might not be available. Check for the presence of the libtool
binary first, and only do the conversion if it is found. If it is not
found, the test should still work on platforms that don't require the
conversion.
With this commit, the test runs on Cygwin, even though there are
failures later.
Change-Id: Ie7b712cdc84671a5a017655a7e41687ff23f906c
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
In the ROCm-GDB testing process, we hit a problem that is a combination
of these 3 factors:
1. In the downstream ROCm-GDB packages, the gdb executable is built with
a relative RUNPATH:
0x000000000000001d (RUNPATH) Library runpath: [${ORIGIN}/../lib]
This is done so that the installation is relocatable (the whole ROCm
directory can be copied around) and things still work. For instance,
the rocgdb executable needs to be able to find the libraries it
needs, such as `librocm-dbgapi.so.0`. The relative runpath allows
that.
2. For testing, we run the testsuite against the gdb executable
installed from one of those packages. It is possible to ./configure
the testsuite directory on its own, and then do:
$ make check RUNTESTFLAGS="GDB=/opt/rocm/bin/rocgdb"
3. The selftests (such as gdb.gdb/selftest.exp) copy the GDB under test
to the standard output directory, before trying to debug it.
The problem is that the gdb executable under test that has been copied
can't find the libraries it needs.
With this patch, I propose that we don't copy the gdb executable, but
debug it in place instead. The comment removed in this patch says "in
case this OS doesn't like to edit its own text space", and has been
there since forever in some form. But it's not clear if there is a host
OS (where we intend to run this test) that needs this nowadays. I would
bet that there isn't. If there is in fact a GDB host OS (where we
intend to run this test) that needs it, we can reinstate the copying,
but as an opt-in operation.
Another situation where this change helps is on Windows, where
gdb/gdb.exe is a libtool wrapper (the real executable is at
gdb/.libs/gdb.exe). Copying gdb/gdb.exe doesn't accomplish anything
useful. The next patch does further changes to account for the libtool
wrapper case.
I tested on Linux and Cygwin, more testing would be welcome.
Change-Id: Id4148517d4fc4ecdd49f099c12003e3d16c6a93d
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
The function to stop at is always main. Remove the parameter and
hard-code main in _selftest_setup.
Change-Id: Ibbbf598203b1658305eb6bc631d029652c10edac
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Rename some procs in lib/selftest-support.exp that are only used
internally, to make it a bit clearer that they are just internal
helpers.
Change-Id: Icd399ac42698209fbc8e798bf43a7d8464aa848c
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
There is a bug in expect, see:
https://sourceforge.net/p/expect/patches/26/
which causes empty substring matches from a regexp to instead return
the complete input buffer. To reproduce this bug, try this command:
expect -c 'spawn sh -c "echo -n -e \"abc\""; \
expect -re "(a?)(a)(bc)"; \
puts "\n"; \
for { set i 1 } { $i < 4 } { incr i } { \
puts -nonewline "($i): \""; \
puts -nonewline $expect_out($i,string); \
puts "\"" \
}'
For a working expect the output looks like:
spawn sh -c echo -n -e "abc"
abc
(1): ""
(2): "a"
(3): "bc"
But for a broken expect the output looks like:
spawn sh -c echo -n -e "abc"
abc
(1): "abc"
(2): "a"
(3): "bc"
Notice that (1) is now returning the complete input buffer rather than
the empty string, this is wrong.
This is not the first time this bug has impacted GDB's testsuite,
this commit seems to be working around the same problem:
commit e579b537353cd91cb8fac1eaeb69901d4936766f
Date: Sat Aug 16 20:32:37 2025 +0200
[gdb/testsuite] Fix TUI tests on freebsd
I recently pushed this commit:
commit 3825c972a636852600b47c242826313f4b9963b8
Date: Wed Jun 18 15:02:29 2025 +0100
gdb: allow gdb.Color to work correctly with pagination
Which added gdb.python/py-color-pagination.exp. Bug PR gdb/33321 was
then created as the test was failing on some hosts. Turns out, this
is same expect bug.
The fix presented here is the same as for e579b537353cd91cb8, avoid
using optional regexp substrings at the start of a regexp, and instead
use two separate regexp patterns. With this change in place, the test
now passes on all hosts.
There's no change in what is being tested after this commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33321
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
On msys2-ucrt64, with test-case gdb.server/non-existing-program.exp I get:
...
(gdb) quit^M
gdb_caching_proc allow_xml_test caused gdb_exit to be called
gdb_caching_proc allow_xml_test marked as called
gdb_caching_proc get_mount_point_map marked as called
builtin_spawn gdbserver stdio non-existing-program^M
Error creating process "non-existing-program " (error 2): \
The system cannot find the file specified.^M^M
Exiting^M^M
FAIL: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
This happens because this regexp fails to match:
...
# This is what we get on Windows.
-re "Error creating process\r\n\r\nExiting\r\n" {
...
Fix this by updating the regexp.
Tested on x86_64-w64-mingw32 (msys2-ucrt64).
|
|
Say we disable startup-with-shell, we get:
...
(gdb) run `echo 8`^M
Starting program: a2-run `echo 8`^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
usage: factorial <number>^M
[Inferior 1 (process 10787) exited with code 01]^M
(gdb) FAIL: gdb.base/a2-run.exp: run "a2-run" with shell (timeout)
...
Fix this by only doing this test if startup-with-shell is supported.
This fixes the test-case on msys2-ucrt64, where startup-with-shell is not
supported.
Likewise in other test-cases.
Tested on x86_64-linux.
|
|
I ran test-case gdb.python/py-color-pagination.exp with make-check-all.sh and
noticed failures when using remote host.
So I grepped to find all test-cases using with_ansi_styling_terminal and ran
them with host/target board local-remote-host-native.
Fix the failing test-cases using require {!is_remote host}.
Tested on x86_64-linux.
|
|
On x86_64-freebsd, I ran into trouble with test-case
gdb.dwarf2/macro-source-path-clang14-dw4.exp (and similar), and I managed to
reproduce the problem on x86_64-linux by making dwarf2_support return 0.
The failure looks like:
...
UNSUPPORTED: $exp: require failed: dwarf2_support
UNRESOLVED: $exp: testcase aborted due to invalid command name: do_test
ERROR: tcl error sourcing $exp.
...
I fixed a similar problem in commit 3e488d8ccd0 ("[gdb/testsuite] Fix
gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh").
Fix this by moving "require dwarf2_support" from
gdb.dwarf2/macro-source-path.exp.tcl to the files including it.
Tested on x86_64-linux.
|
|
On s390x, a big-endian machine, I'm seeing these test failures:
FAIL: gdb.base/dump.exp: array as memory, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: array as value, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: array copy, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array copy, tekhex; value restored ok
FAIL: gdb.base/dump.exp: array partial, tekhex; file restored ok
FAIL: gdb.base/dump.exp: array partial, tekhex; value restored ok
FAIL: gdb.base/dump.exp: dump array as memory, tekhex
FAIL: gdb.base/dump.exp: dump array as value, tekhex
FAIL: gdb.base/dump.exp: dump struct as memory, tekhex
FAIL: gdb.base/dump.exp: dump struct as value, tekhex
FAIL: gdb.base/dump.exp: reload array as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: reload array as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: reload struct as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: reload struct as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: struct as memory, tekhex; file restored ok
FAIL: gdb.base/dump.exp: struct as memory, tekhex; value restored ok
FAIL: gdb.base/dump.exp: struct as value, tekhex; file restored ok
FAIL: gdb.base/dump.exp: struct as value, tekhex; value restored ok
FAIL: gdb.base/dump.exp: struct copy, tekhex; file restored ok
FAIL: gdb.base/dump.exp: struct copy, tekhex; value restored ok
It turns out that there's a subtle bug in move_section_contents in
bfd/tekhex.c. The bug is that when attempting to write a buffer that
starts with a zero byte, the function will return false, an error
condition, without writing anything. But it also doesn't set
bfd_error, so GDB ends up displaying whatever the last unrelated error
was, e.g.:
warning: writing dump file '.../intstr1.tekhex' (No such file or directory)
When I investigated this, the bfd error was set during failure to
open a separate debug file for the test case, which is totally
unrelated to this problem.
The reason this fails on big endian machines is that the test case
writes out structs and arrays of int initialized to small values. On
little endian machines, the small integer is the first byte, so the
error doesn't occur. On big endian machines, a zero byte occurs
first, triggering the error.
On the GDB side of things, I've made a one line change to the test
case to cause the error to also happen on little endian machines. I
simply shift value of the first field in the struct left by 16 bits.
That leaves at least one zero byte on both sides of the non-zero part
of the int. I shifted it by 16 because, for a moment, there was a
question in my mind about what would happen with a second zero byte,
but it turns out that it's not a problem.
On the bfd side of things, take a look at move_section_contents() and
find_chunk() in tekhex.c. The scenario is this: we enter
move_section_contents with locationp pointing at a character buffer
whose first byte is zero. The 'get' parameter is false, i.e. we're
writing, not reading. The other critical fact is that the
abfd->tdata.tekhex_data->data is NULL (0).
I'm going to go through the execution path pretty much line by line
with commentary below the line(s) just executed.
char *location = (char *) locationp;
bfd_vma prev_number = 1; /* Nothing can have this as a high bit. */
I can't say that the comment provides the best explanation about
what's happening, but the gist is this: later on, chunk_number will
have it's low bits masked away, therefore no matter what it is, it
can't possibly be equal to prev_number when it's set to 1.
struct data_struct *d = NULL;
BFD_ASSERT (offset == 0);
for (addr = section->vma; count != 0; count--, addr++)
{
Set d to NULL and enter the loop.
/* Get high bits of address. */
bfd_vma chunk_number = addr & ~(bfd_vma) CHUNK_MASK;
bfd_vma low_bits = addr & CHUNK_MASK;
Use CHUNK_MASK, which is 0x1fff, to obtain the chunk number, i.e.
whatever's left after masking off the low 13 bits of addr, and
low_bits, which are the low 13 bits of addr. chunk_number matters for
understanding this bug, low_bits does not. Remember that no matter
what addr is, once you mask off the low 13 bits, it can't be equal to 1.
bool must_write = !get && *location != 0;
!get is true, *location != 0 is false, therefore the conjunction is
false, and furthermore must_write is false. I.e. even though we are
writing, we don't transfer zero bytes to the chunk - this is why
must_write is false. (The reason this works is that a chunk, once
allocated, is zero'd as part of the allocation using bfd_zalloc.
Therefore we can skip transferring zero bytes and, if enough of them
are skipped one after another, chunk allocation simply doesn't happen.
That's a good thing.)
if (chunk_number != prev_number || (!d && must_write))
For the reason provided above, chunk_number != prev_number is true.
The other part of the disjunction doesn't matter since the first part
is true. This means that the if-block is entered.
/* Different chunk, so move pointer. */
d = find_chunk (abfd, chunk_number, must_write);
find_chunk is entered with must_write set to false. Now, remember
where we left off here, because we're going to switch to find_chunk.
static struct data_struct *
find_chunk (bfd *abfd, bfd_vma vma, bool create)
{
(Above 3 lines indented to distinguish code from commentary.)
When we enter find_chunk, create is false because must_write was false.
struct data_struct *d = abfd->tdata.tekhex_data->data;
d is set to NULL since abfd->tdata.texhex_data->data is NULL (one of
the conditions for the scenario).
vma &= ~CHUNK_MASK;
while (d && (d->vma) != vma)
d = d->next;
d is NULL, so the while loop doesn't execute.
if (!d && create)
...
d is NULL so !d is true, but create is false, so the condition
evaluates to false, meaning that the if-block is skipped.
return d;
find_chunk returns NULL, since d is NULL.
Back in move_section_contents:
if (!d)
return false;
d is NULL (because that's what find_chunk returned), so
move_section_contents returns false at this point.
Note that find_section_contents has allocated no memory, nor even
tried to transfer any bytes beyond the first (zero) byte. This
is a bug.
The key to understanding this bug is to observe that find_chunk can
return NULL to indicate that no chunk was found. This is especially
important for the read (get=true) case. But it can also be NULL
to indicate a memory allocation error. I toyed around with the
idea of using a different value to distinguish these cases, i.e.
something like (struct data_struct *) -1, but although bfd contains
plenty of code where -1 is used to indicate various interesting
conditions for scalars, there's no prior art where this is done
for a pointer. Therefore the idea was discarded in favor of
modifying this statement:
if (!d)
return false;
to:
if (!d && must_write)
return false;
This works because, in find_chunk, the only way to return a NULL
memory allocation error is for must_write / create to be true. When
it is true, if bfd_zalloc successfully allocates a chunk, then that
(non-NULL) chunk will be returned at the end of the function. When it
fails, it'll return NULL early. The point is that when bfd_zalloc()
fails and returns NULL, must_write (in move_section_contents) / create
(in find_chunk) HAD to be true. That provides us with an easy test
back in move_section_contents to distinguish a memory-allocation-NULL
from a block-not-found-NULL.
The other NULL return case happens when the end of the function is
reached when either searching for a chunk to read or attempting to
find a chunk to write when abfd->tdata.tekhex_data->data is NULL. But
for the latter case, must_write was false, which does not (now, with
the above fix) trigger the early return of false.
(Alan Modra approved the bfd/tekhex.c change.)
Approved-By: Simon Marchi <simon.marchi@efficios.com> (GDB)
|
|
This commit allows gdb.Color objects to be used to style output from
GDB commands written in Python, and the styled output should work
correctly with pagination.
There are two parts to fixing this:
First, GDB needs to be able to track the currently applied style
within the page_file class. This means that style changes need to be
achieved with calls to pager_file::emit_style_escape.
Now usually, GDB does this by calling something like fprintf_styled,
which takes care to apply the style for us. However, that's not
really an option here as a gdb.Color isn't a full style, and as the
gdb.Color object is designed to be converted directly into escape
sequences that can then be printed, we really need a solution that
works with this approach.
However pager_file::puts already has code in place to handle escape
sequences. Right now all this code does is spot the escape sequence
and append it to the m_wrap_buffer. But in this commit I propose that
we go one step further, parse the escape sequence back into a
ui_file_style object in pager_file::puts, and then we can call
pager_file::emit_style_escape.
If the parsing doesn't work then we can just add the escape sequence
to m_wrap_buffer as we did before.
But wait, how can this work if a gdb.Color isn't a full style? Turns
out that's not a problem. We only ever emit the escape sequence for
those parts of a style that need changing, so a full style that sets
the foreground color will emit the same escape sequence as a gdb.Color
for the foreground. When we convert the escape sequence back into a
ui_file_style, then we get a style with everything set to default,
except the foreground color.
I had hoped that this would be all that was needed. But unfortunately
this doesn't work because of the second problem...
... the implementation of the Python function gdb.write() calls
gdb_printf(), which calls gdb_vprintf(), which calls ui_file::vprintf,
which calls ui_out::vmessage, which calls ui_out::call_do_message, and
finally we reach cli_ui_out::do_message. This final do_message
function does this:
ui_file *stream = m_streams.back ();
stream->emit_style_escape (style);
stream->puts (str.c_str ());
stream->emit_style_escape (ui_file_style ());
If we imagine the case where we are emitting a style, triggered from
Python like this:
gdb.write(gdb.Color('red').escape_sequence(True))
the STYLE in this case will be the default ui_file_style(), and STR
will hold the escape sequence we are writing.
After the first change, where pager_file::puts now calls
pager_file::emit_style_escape, the current style of STREAM will have
been updated. But this means that the final emit_style_escape will
now restore the default style.
The fix for this is to avoid using the high level gdb_printf from
gdb.write(), and instead use gdb_puts instead. The gdb_puts function
doesn't restore the default style, which means our style modification
survives.
There's a new test included. This test includes what appears like a
pointless extra loop (looping over a single value), but this makes
sense given the origin of this patch. I've pulled this commit from a
longer series:
https://inbox.sourceware.org/gdb-patches/cover.1755080429.git.aburgess@redhat.com
I want to get this bug fix merged before GDB 17 branches, but the
longer series is not getting reviews, so for now I'm just merging this
one fix. Once the rest of the series gets merged, I'll be extending
the test, and the loop (mentioned above) will now loop over more
values.
|
|
After running the testsuite with target board cc-with-gdb-index I ran found
failures in test-cases:
- gdb.dwarf2/backward-spec-inter-cu.exp
- gdb.dwarf2/forward-spec-inter-cu.exp
Fix this by requiring a cooked index.
Tested on x86_64-linux.
|
|
I forgot one spot when updating the "info shared" header from NS to
"Linker NS", fix that. This fixes the following failure:
FAIL: gdb.base/dlmopen-ns-ids.exp: check no duplicates: info sharedlibrary
At the same time, fix a couple of things I found when looking at this
code again. One is bad indentation, the other is an unnecessary
parameter.
Change-Id: Ibbc2062699264dde08fd3ff7c503524265c73b0c
|
|
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:
1) - Keep standard_output_file's host-side semantics
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:
proc build_file_normalize {filename} {
if { [ishost *-*-mingw*] } {
return [exec cygpath -ua $filename]
} else {
return [file normalize $filename]
}
}
proc host_file_normalize {filename} {
if { [ishost *-*-mingw*] } {
return [exec cygpath -ma $filename]
} else {
return [file normalize $filename]
}
}
"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.
Change-Id: I664dbb86d0efa4fa8db405577bea2b4b4a96a613
|
|
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
|
|
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.
Tested on x86-64 GNU/Linux with both:
$ make check RUNTESTFLAGS=" \
--host_board=local-remote-host-native \
--target_board=local-remote-host-native \
HOST_DIR=/tmp/foo/" \
TESTS="gdb.base/backtrace.exp"
and:
$ make check TESTS="gdb.base/backtrace.exp"
and confirming that the testcase still compiles and passes cleanly.
Also ran full testsuite on x86-64 GNU/Linux in normal mode.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I5ca77426ea4a753a995c3ad125618c02cd952576
|
|
When running a program that uses multiple linker namespaces, I get
something like:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-ns-ids -ex "tb 50" -ex r -ex "info shared" -batch
...
From To NS Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 0 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7e93000 0x00007ffff7f8b000 0 Yes /usr/lib/libm.so.6
0x00007ffff7ca3000 0x00007ffff7e93000 0 Yes /usr/lib/libc.so.6
0x00007ffff7fb7000 0x00007ffff7fbc000 1 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-lib.so
0x00007ffff7b77000 0x00007ffff7c6f000 1 Yes /usr/lib/libm.so.6
0x00007ffff7987000 0x00007ffff7b77000 1 Yes /usr/lib/libc.so.6
0x00007ffff7fc6000 0x00007ffff7fff000 1 Yes /usr/lib/ld-linux-x86-64.so.2
0x00007ffff7fb2000 0x00007ffff7fb7000 2 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-lib.so
0x00007ffff788f000 0x00007ffff7987000 2 Yes /usr/lib/libm.so.6
0x00007ffff769f000 0x00007ffff788f000 2 Yes /usr/lib/libc.so.6
0x00007ffff7fc6000 0x00007ffff7fff000 1! Yes /usr/lib/ld-linux-x86-64.so.2
0x00007ffff7fad000 0x00007ffff7fb2000 3 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-lib.so
0x00007ffff75a7000 0x00007ffff769f000 3 Yes /usr/lib/libm.so.6
0x00007ffff73b7000 0x00007ffff75a7000 3 Yes /usr/lib/libc.so.6
0x00007ffff7fc6000 0x00007ffff7fff000 1! Yes /usr/lib/ld-linux-x86-64.so.2
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.
Change-Id: I84467c6abf4e0109b1c53a86ef688b934e8eff99
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
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.
5 libraries loaded in 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
6 libraries loaded in 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
5 libraries loaded in 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 shared
From To Linker 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
Change-Id: Iefad340f7f43a15cff24fc8e1301f91d3d7f0278
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
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.
Change-Id: I03867f40e5313816bd8a8401b65713ddef5d620e
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
