| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In a record session, when we move backward, GDB switches from normal
execution to simulation. Moving forward again, the emulation continues
until the end of the reverse history. When the end is reached, the
execution stops, and a warning message is shown. This message has been
modified to indicate that the forward emulation has reached the end, but
the execution can continue as normal, and the recording will also continue.
Before this patch, the warning message shown in that case was the same as
in the reverse case. This meant that when the end of history was reached in
either backward or forward emulation, the same message was displayed:
"No more reverse-execution history."
This message has changed for these two cases. Backward emulation:
"Reached end of recorded history; stopping.
Backward execution from here not possible."
Forward emulation:
"Reached end of recorded history; stopping.
Following forward execution will be added to history."
The reason for this change is that the initial message was deceiving, for
the forward case, making the user believe that forward debugging could not
continue.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224
Reviewed-By: Markus T. Metzger <markus.t.metzger@intel.com> (btrace)
Approved-By: Guinevere Larsen <blarsen@redhat.com>
|
|
A corrupt debuginfo file can result in a null abbrev_info pointer
being passed to cooked_indexer::scan_attributes. This pointer
is set to nullptr by peek_die_abbrev when an abbrev of 0 is found.
There is no check for whether the abbrev pointer is null and
SIGSEGV occurs when attempting to dereference the pointer.
An abbrev of 0 normally indicates that the corresponding DIE is a
null entry, but scan_attributes expects a non-null DIE.
Fix this by throwing an error in cooked_indexer::scan_attributes
when peek_die_abbrev returns a nullptr in order to avoid
scan_attributes calling itself with a null abbrev.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478
Co-authored-by: Tom de Vries <tdevries@suse.de>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
cooked_indexer::ensure_cu_exists
With the test-case included in this patch, we run into:
...
$ gdb -q -batch $exec
Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \
[in module $exec]
...
The debug info consists of two CUs:
...
Compilation Unit @ offset 0xb2:
Length: 0x25 (32-bit)
Version: 4
Abbrev Offset: 0x6c
Pointer Size: 8
<0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
<be> DW_AT_language : 2 (non-ANSI C)
<1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
<c0> DW_AT_low_pc : 0x4004a7
<c8> DW_AT_high_pc : 0x4004b2
<d0> DW_AT_specification: <0xe8>
<1><d4>: Abbrev Number: 3 (DW_TAG_subprogram)
<d5> DW_AT_name : main
<1><da>: Abbrev Number: 0
Compilation Unit @ offset 0xdb:
Length: 0xf (32-bit)
Version: 4
Abbrev Offset: 0x86
Pointer Size: 8
<0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit)
<e7> DW_AT_language : 2 (non-ANSI C)
<1><e8>: Abbrev Number: 2 (DW_TAG_subprogram)
<e9> DW_AT_specification: <0xd4>
<1><ed>: Abbrev Number: 0
...
where:
- DIE 0xbf in CU@0xb2 contains an inter-CU reference to
- DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to
- DIE 0xd4 back in CU@0xb2.
The dwarf error is caused by this bit of code in
cooked_indexer::ensure_cu_exists:
...
if (per_cu == m_per_cu)
return reader;
...
The dwarf error happens as follows:
- a cutu_reader A is created for CU@0xb2
- using cutu_reader A, the cooked index reader starts indexing dies, with
m_per_cu set to CU@0xb2
- while indexing it scans the attributes of DIE 0xbf and encounters the
inter-CU reference to DIE 0xe8
- it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for
CU@0xdb and returns it
- using cutu_reader B, it continues scanning attributes of DIE 0xe8 and
encounters the inter-CU reference to DIE 0xd4
- it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered
and cutu_reader B is returned
- using cutu_reader B, it continues scanning attributes of DIE 0xd4
- this goes wrong because:
- the attributes of the DIE are encoded using the abbreviation table at
offset 0x6c, while
- the decoding is done using cutu_reader B which uses the abbreviation table
at offset 0x86.
Fix this by removing the problematic if clause.
Since cutu_reader A is not preserved in m_index_storage,
cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate
cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving
the cutu_reader A as well in m_index_storage.
Tested on x86_64-linux and aarch64-linux.
PR symtab/32081
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081
Approved-By: Tom Tromey <tom@tromey.com>
Reported-By: Andreas Schwab <schwab@linux-m68k.org>
|
|
It was pointed out in this email:
https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com
that this commit:
commit 0726729d344fecf98f8d138e688e77201cc3cece
Date: Mon Jun 3 13:56:54 2024 +0100
gdb/testsuite: track if a caching proc calls gdb_exit or not
had broken some AArch64 tests.
What is going on is that there are two caching procs:
allow_aarch64_sme_tests
aarch64_initialize_sme_information
the allow_aarch64_sme_tests proc makes a call to
aarch64_initialize_sme_information, but
aarch64_initialize_sme_information is also called from other
non-caching procs, like aarch64_supports_sme_svl.
Both of the caching procs mentioned above compile and run a helper
program, and both of them call gdb_exit.
After the above commit, the first call to any caching proc, the body
of which calls gdb_exit, will result in a gdb_exit call even if the
body is not executed and the result is fetched from the cache.
What was observed is that in the first test script
allow_aarch64_sme_tests is called, the body of this caching proc is
run which calls gdb_exit. Then allow_aarch64_sme_tests calls
aarch64_initialize_sme_information, the body of which is run and
gdb_exit is called again. The results from both procs are added to
the cache.
In the next test script allow_aarch64_sme_tests is called. This
results in a cache hit, but gdb_exit is also called as this is the
first call in this second test script.
Later in the test script aarch64_supports_sme_svl is called which
calls aarch64_initialize_sme_information. As this is the first call
to aarch64_initialize_sme_information in this second test
script (remember the body of allow_aarch64_sme_tests was never run)
then gdb_exit is called. This call to gdb_exit is new after the above
commit and is unexpected.
I think the idea behind the above commit is still sound. If the call
to allow_aarch64_sme_tests was removed from the second test script
then we would want the extra gdb_exit call as this would expose a real
bug in the test. The problem is that after the above commit the
nested nature of the caching proc calls becomes important: a call to
allow_aarch64_sme_tests should mean that we've also called
aarch64_initialize_sme_information, and that relationship isn't
currently captured.
So in this commit I'm adding another field to the global
gdb_data_cache (in lib/cache.exp). This new field is 'also_called'.
For every caching proc we populate this field with a list of names,
these are the names of any nested caching procs that are called when
the body of a caching proc is executed.
Now when we get a cache hit in gdb_data_cache we mark every proc in
the 'also_called' list as having been called. This means that further
calls to these procs will no longer trigger a gdb_exit call.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into:
...
Expecting: ^(-pycmd exp[^M
]+)?(.*&"Traceback \(most recent call last\):.."^M
&"[^^M
]+py-mi-cmd.py[^^M
]+"^M
&"[^^M
]+raise gdb.GdbError\(\).."^M
&"gdb.GdbError.."^M
\^error,msg="Error occurred in Python\."[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd exp^M
&"Traceback (most recent call last):\n"^M
&" File \"py-mi-cmd.py\", line 76, in invoke\n raise gdb.GdbError()\n"^M
&"gdb.GdbError\n"^M
^error,msg="Error occurred in Python."^M
(gdb) ^M
FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output)
...
In contrast, with python 3.12 I have:
...
Expecting: ^(-pycmd exp[^M
]+)?(.*&"Traceback \(most recent call last\):.."^M
&"[^^M
]+py-mi-cmd.py[^^M
]+"^M
&"[^^M
]+raise gdb.GdbError\(\).."^M
&"gdb.GdbError.."^M
\^error,msg="Error occurred in Python\."[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd exp^M
&"Traceback (most recent call last):\n"^M
&" File \"py-mi-cmd.py\", line 76, in invoke\n"^M
&" raise gdb.GdbError()\n"^M
&"gdb.GdbError\n"^M
^error,msg="Error occurred in Python."^M
(gdb) ^M
PASS: gdb.python/py-mi-cmd.exp: -pycmd exp
...
To make it easier to understand what we're looking at, let's take this out of
the mi interpreter context and use the cli interpreter:
...
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+set python print-stack full
+source py-mi-cmd.py
+python pycmd1('-pycmd')
+python pycmd1.invoke (pycmd1, ["exp"])
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "py-mi-cmd.py", line 76, in invoke
raise gdb.GdbError()
gdb.GdbError
gdb.in:4: Error in sourced command file:
Error occurred in Python.
...
Interestingly, this is what we're seeing with both python 3.12 and 3.13.
The difference between the python versions is that:
- with python 3.12 each line is printed by itself, and
- with python 3.13 two particular lines are printed toghether.
With the cli interpreter, that makes no difference, because the '\n' is
interpreted.
But with the mi interpreter, that causes a difference in output because the
'\n' is not interpreted, but rather printed literally.
Fix this by accepting the new output in addition to the old one.
Tested on aarch64-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
PR testsuite/31913
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913
|
|
gdb.ada/multiarray.exp has a loop that looks like it should run the
test in both 'all' and 'minimal' encodings mode. However, the body of
the loop doesn't actually use the 'flags' variable. This was an
oversight in the original commit.
|
|
Following on from the previous commit, this commit fixes the two KFAIL
in gdb.base/sysroot-debug-lookup.exp when not using the
native-extended-gdbserver board.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What I think we need to do is this: if the sysroot has a target:
prefix, and the target filesystem is local to GDB, then we should
strip the target: prefix from the sysroot, just as we do when opening
a file (see gdb_bfd_open in gdb_bfd.c).
Now, when we make the child_path() call neither the sysroot nor
CANON_DIR will have a target: prefix, the child_path() call will
succeed, and GDB will correctly find the debug information.
There is just one remaining issue, the last path we look in when
searching for debug information is built by starting with the sysroot,
then adding the debug directory, see this line:
debugfile = path_join (target_prefix_str, root.c_str (),
debugdir.get (), base_path, debuglink);
The target_prefix_str is set to target: if DIR has a target: prefix,
and DIR should have a target: prefix if the file we're looking for was
opened with a target: prefix. However, in our case the file was in a
local filesystem so GDB stripped the prefix off.
The sysroot however, does have the target: prefix, and the test is
expecting to see GDB look within a file with the target: prefix.
Given that the above line is about looking within a sub-directory of
the sysroot, I think we should not be stripping the target: prefix off
the sysroot path (as we do when building ROOT), instead, we should, in
this case, not use TARGET_PREFIX_STR, and instead just use GDB's
sysroot as it is (in this case with the target: prefix).
With these fixes in place I now see no failures when using the 'unix',
'native-gdbserver', or 'native-extended-gdbserver' boards with this
test, and the KFAILs can be removed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
|
|
I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added
recently actually had a KPASS when run with the
native-extended-gdbserver board. This was an oversight when adding
the test.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What happens in the native-extended-gdbserver case is that GDB doesn't
see the target filesystem as local. Now the filename retains the
target: prefix, which means that in the child_path() call both the
sysroot and the CANON_DIR have a target: prefix, and so the
child_path() call succeeds. This allows GDB to progress, try some
additional paths, and then find the debug information.
So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect
the test to succeed when using the native-extended-gdbserver protocol.
This leaves one KFAIL when using the native-extended-gdbserver board,
we find the debug information but (apparently) find it in the wrong
file. What's happening is that when GDB builds the filename for the
debug information we end up with a '//' string as a directory
separator, the test regexp only expects a single separator.
Instead of just fixing the test regexp, I've updated the path_join
function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to
appear in the argument list after the first argument. This means it's
now possible to do this:
auto result = path_join ("/a/b/c", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
Additionally I've changed path_join so that it avoids adding
unnecessary directory separators. In the above case when the two
paths were joined GDB only added a single separator between 'c' and
'd'. But additionally, if we did this:
auto result = path_join ("/a/b/c/", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
We'd still only get a single separator.
With these changes to path_join I can now make use of this function in
find_separate_debug_file. With this done I now have no KFAIL when
using the native-extended-gdbserver board.
After this commit we still have 2 KFAIL when not using the
native-gdbserver and unix boards, these will be addressed in the next
commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Usually with test-case gdb.python/py-progspace-events.exp I get:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 4116] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M
28 { /* Nothing. */ }^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
step^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabf4f850>^M
do_parent_stuff () at py-progspace-events.c:41^M
41 ++global_var;^M
(gdb) PASS: gdb.python/py-progspace-events.exp: step
...
But occasionally I run into the following FAIL:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
(gdb) FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout)
...
This is caused by a race between the handling of an event, and the
"inferior 1" command.
In the passing case, the event is handled first. During which prune_inferiors
is called, but it can't remove inferior 2, because it's still the current one.
In the failing case, the "inferior 1" command is handled first. Then during
handling of the event, prune_inferiors is called, and it can remove inferior 2
because it's no longer the current one.
This looks like a test-case issue to me, but ISTM that we can do better: by
calling prune_inferiors asap, at the end of the "inferior 1" command, we
stabilize the moment when the inferior is removed:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
...
This also allows us to simplify the test-case by removing the step command,
which is no longer required to trigger the pruning of the inferior.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR gdb/31440
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440
|
|
The relatively new "globals" scope code in DAP has a fairly obvious
bug -- the fetch_one_child method should return a tuple with two
elements, but instead just returns the variable's value.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada
print pck.fp1_var^M
$1 = 0.3125^M
(gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var
...
The problem is that the thumb prologue analyzer overshoot, setting the
breakpoint for main after line 49:
...
46 int
47 main (void)
48 {
49 pck__fp1_var++;
...
and consequently we see the value of pck.fp1_var after line 49 instead of
before line 49. This is PR tdep/31981.
Work around this by removing line 49 and all similar subsequent lines, which
turn out to be dead code.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on arm-linux.
|
|
On arm-linux I run into:
...
(gdb) p *kernel_user_helper_version^M
Cannot access memory at address 0xffff0ffc^M
(gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version
...
What the test-case is trying to do, is to access a special address in the arm
linux kernel [1] using ptrace, which doesn't seem to work.
This is with kernel version 6.1.55. Perhaps this used to work, but the kernel
was modified to be more strict with respect to access to this special address.
Fix this by making the inferior access that special address instead.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/32070
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070
[1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
|
|
My previous patch
commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD)
Author: Felix Willgerodt <felix.willgerodt@intel.com>
Date: Mon Feb 25 15:30:29 2019 +0100
python: Add clear() to gdb.Record.
exposed a clear function for btrace data in python and added some tests
for it. That caused a regression (PR 32086) when recording with bts.
This is reproducible even without my patch, when adding
"maintenance btrace clear" to the test.
When comparing the instructions that get recorded in both cases, the traces
are almost identical, just that the first 3 instructions are missing.
Before clear:
(gdb) record instruction-history 1,100
1 0x0000555555555163 <main+12>: movl $0x0,-0x4(%rbp)
2 0x000055555555516a <main+19>: movl $0x0,-0x8(%rbp)
3 0x0000555555555171 <main+26>: jmp 0x555555555184 <main+45>
4 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
5 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
6 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
7 0x0000555555555176 <main+31>: mov %eax,%edi
...
After clear:
(gdb) record instruction-history 1,100
1 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
2 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
3 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
4 0x0000555555555176 <main+31>: mov %eax,%edi
...
The GDB manual describes this behaviour already:
maint btrace clear
Discard the branch trace data. The data will be fetched anew and
the branch trace will be recomputed when needed.
This implicitly truncates the branch trace to a single branch trace
buffer. When updating branch trace incrementally, the branch trace
available to GDB may be bigger than a single branch trace buffer.
The test with BTS is updating the recorded trace incrementally. After the
clear, the buffer of raw trace data available is not enough to recompute the
whole trace as it was before the clear(), and the first 3 instructions are
missing.
As increasing the buffer size for BTS didn't help, I propose to fix the test
by moving the testing of clear to the end of the test.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086
|
|
A DAP user noticed that breakpoints set by address were never updated
to show their location after the DAP launch request. It turns out
that gdb does not emit the breakpoint-modified event when this sort of
breakpoint is updated.
This patch changes gdb to notify the breakpoint-modified observer when
a breakpoint location's symbol changes. This in turn causes the DAP
event to be emitted.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
While working on earlier patches, I noticed that the DAP C++ exception
test had some strange results in the log. Digging into this, I found
that while the Ada catchpoints emit a "bkptno" field in the MI result,
the C++ ones do not -- but the DAP code was relying on this.
This patch fixes the problem by changing which field is examined, and
then updates the tests to verify this.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Currently, when a DAP client uses setInstructionBreakpoints, the
resulting breakpoints are created as "verified", even though there is
no symbol file and thus the breakpoint can't possibly have a source
location.
This patch changes the DAP code to assume that all breakpoints are
unverified before launch.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Call the ptwrite filter function whenever a ptwrite event is decoded.
The returned string is written to the aux_data string table and a
corresponding auxiliary instruction is appended to the function segment.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This function allows to clear the trace data from python, forcing to
re-decode the trace for successive commands.
This will be used in future ptwrite patches, to trigger re-decoding when
the ptwrite filter changes.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
There are a couple of ways that readline wrapping can be disabled:
- using "set horizontal-scroll-mode on" in INPUTRC,
- using a TERM setting like TERM=dumb, and
- building gdb with stub-termcap.
Using a trigger patch in default_gdb_init that adds
"set horizontal-scroll-mode on" to INPUTRC:
...
- setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"]
+ setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"]
...
we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in
PR testsuite/31201 (which was reported for the stub-termcap case):
...
WARNING: timeout in accept_gdb_output
Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1):
0 Quit
1 <89012345678901234567890123456789W
2
...
23
FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap
...
Fix this by accepting the horizontal-scroll-mode style output. We do
this only when in CLI mode though, when in TUI wrapping works as before
because it doesn't rely on readline.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
|
|
Remove the support for the QNX Neutrino OS (tdep and native bits). This
has been unmaintained for years, and we don't have a way to see if it
works (or even builds, for the native parts). Without somebody actively
maintaining it, this is just a burden for developers, especially that
this port does a few weird unique things that require reasoning about
when doing big change.
Support for GDBserver was removed in 2020, commit 613f149a90d6
("gdbserver: remove support for Neutrino").
Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
This adds a missing allow_tui_tests guard.
When tui is not enabled this test case does
typically fail:
FAIL: gdb.base/new-ui.exp: do_test_invalid_args: new-ui with tui
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
The 'list' command prints around the 'main' function if the current
source location is not set. The prologue of 'main' is skipped and the
first real line of 'main' is offset by 'lines_to_print - 1'. This is
incorrect, the location should be defaulted to main's prologue without
applying offsets (similar to 'list main'). Printing around the selected
line is then done in 'list_around_line'.
The patch also fixes an issue if the list command is used before the
program is started. For example, with the following code:
26 static void attribute ((used)) ambiguous_fun (void) {}
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
37
38 int
39 main (void)
40 {
41 return 0;
42 }
GDB offsets the relevant line by 'lines_to_print - 1' and then by another
'lines_to_print / 2' and prints:
(gdb) list
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
With this patch, GDB correctly prints:
37
38 int
39 main (void)
40 {
41 return 0;
42 }
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Using 'output' to print arrays larger than max-value-size, with only
repeating elements, can cause gdb to crash:
```
$ cat a.c:
char a[1000000];
int main()
{
return a[0];
}
$ gdb -q a
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
Using 'print' works, because value::record_latest sets the unavailable
bytes of the value when it's added to the value history.
But 'outout' doesn't do that, so the printing tries to access more bytes
than are available.
The original problem in PR32015 was about using 'print' of a dynamic
array in a D program.
Here the crash happens because for 'print' the value was a struct with
length/ptr fields, which is converted in d-valprint.c into an array.
So value::record_latest didn't have a chance to mark the unavailable
bytes in this case.
To make sure the unavailable bytes always match the contents, this fixes
it by marking the unavailable bytes immediately after the contents are
allocated.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Consider the following test-case:
...
$ cat -n test.c
1 int var;
2
3 int
4 foo (void)
5 {
6 var = 1;
7 #include "test.h"
8 }
9
10 int
11 main ()
12 {
13 return foo ();
14 }
$ cat -n test.h
1 return 1;
$ gcc test.c -g
...
When stepping through the test-case, gdb doesn't make it explicit that line 1
is not in test.c:
...
Temporary breakpoint 1, main () at test.c:13
13 return foo ();
(gdb) step
foo () at test.c:6
6 var = 1;
(gdb) n
1 return 1;
(gdb)
8 }
(gdb)
...
which makes it easy to misinterpret the output.
This is with the default "print frame-info" == auto, with documented
behaviour [1]:
...
stepi will switch between source-line and source-and-location depending on the
program counter.
...
What is actually implemented is that source-line is used unless stepping into
or out of a function.
The problem can be worked around by using
"set print frame-info source-and-location", but that's a bit verbose.
Instead, change the behaviour of "print frame-info" == auto to also use
source-and-location when stepping into another file, which gets us:
...
(gdb) n
foo () at test.h:1
1 return 1;
...
Tested on x86_64-linux.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
PR gdb/32011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo
|
|
Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not
actually compiling the test with some debuginfo in the relevant part,
and while fixing I noticed that the base assumption of the "some" case
was wrong, GDB would select some symtab as a default location and the
test would always fail. This fix makes printing the default location
only be tested when there is no debuginfo.
When testing with no debuginfo, if a system had static libc debuginfo,
the test would also fail. To add an extra layer of robustness to the
test, this rewrite also strips any stray debuginfo from the executable.
The test would only fail now if it runs in a system that can't handle
stripped debuginfo and has static debuginfo pre-installed.
Reported-By: Tom de Vries <tdevries@suse.de>
Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The final test of gdb.python/py-framefilter-invalidarg.exp expected that
the the backtrace only printed the source file name. However, when using
clang, gdb will always print the full path to the file, which would
cause the test to fail. This commit introduces a regexp that optionally
matches paths, preprended to the file name, which fixes the clang
failure without introducing gcc failures.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The test gdb.fortran/entry-point.exp already has an XFAIL when trying to
set a breakpoint in mod::mod_foo because gcc puts that subprogram in the
wrong scope in the debug information. Clang's debug information looks
the same as gcc's, so the test to setup the xfail has been extended to
also include clang.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Clang doesn't add build-id information by default, unlike gcc. This
means that tests that rely on build-id being available and don't
explicitly add it to the compilation options will fail with clang.
This commit fixes the fails in gdb.python/py-missing-debug.exp,
gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp
and gdb.server/solib-list.exp
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
On fedora rawhide, with python 3.13, I run into:
...
(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
Python Exception <class 'TypeError'>: \
this function got an unexpected keyword argument 'invalid'^M
Error occurred in Python: \
this function got an unexpected keyword argument 'invalid'^M
(gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
a_point_t with option invalid=True
...
A passing version with an older python version looks like:
...
(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
Python Exception <class 'TypeError'>: \
'invalid' is an invalid keyword argument for this function^M
Error occurred in Python: \
'invalid' is an invalid keyword argument for this function^M
(gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
a_point_t with option invalid=True
...
Fix this by accepting the updated error message.
Tested on aarch64-linux.
PR testsuite/31912
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912
|
|
Fix all trailing-text-in-parentheses duplicates exposed by previous patch.
Tested on x86_64-linux and aarch64-linux.
|
|
When using a duplicate test name:
...
fail foo
fail foo
...
we get:
...
FAIL: $exp: foo
FAIL: $exp: foo
DUPLICATE: $exp: foo
...
But when we do:
...
fail foo
fail "foo (timeout)"
...
we get only:
...
FAIL: $exp: foo
FAIL: $exp: foo (timeout)
...
Trailing text between parentheses prefixed with a space is interpreted as
extra information, and not as part of the test name [1].
Consequently, "foo" and "foo (timeout)" do count as duplicate test names,
which should have been detected. This is PR testsuite/29772.
Fix this in CheckTestNames::_check_duplicates, such that we get:
...
FAIL: $exp: foo
FAIL: $exp: foo (timeout)
DUPLICATE: $exp: foo (timeout)
...
[ One note on the implementation: I used the regexp { \([^()]*\)$}. I don't
know whether that covers all required cases, due to the fact that those are
not unambiguousely specified. It might be possible to reverse-engineer that
information by reading or running the "regression analysis tools" mentioned on
the wiki page [1], but I haven't been able to. Regardless, the current regexp
covers a large amount of cases, which IMO should be sufficient to be
acceptable. ]
Doing so shows many new duplicates in the testsuite.
A significant number of those is due to using a message which is a copy of the
command:
...
gdb_test "print (1)"
...
Fix this by handling those cases using test names "gdb-command<print (1)>" and
"gdb-command<print (2)>.
Fix the remaining duplicates manually (split off as follow-up patch for
readability of this patch).
Tested on x86_64-linux and aarch64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29772
[1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages
|
|
I tried to reproduce a problem in test-case gdb.python/py-disasm.exp on a
s390x machine, but when running with target board unix/-m31 I saw that the
required libraries were missing, so I couldn't generate an executable.
However, I realized that I did have an object file, and the test-case should
mostly also work with an object file.
I've renamed gdb.python/py-disasm.exp to gdb.python/py-disasm.exp.tcl and
included it from two new minimal test-case wrappers:
- gdb.python/py-disasm-exec.exp, and
- gdb.python/py-disasm-obj.exp
where the former uses an executable as before, and the latter uses an object
file.
Using an object file required changing the info.read_memory calls in
gdb.python/py-disasm.py:
...
- info.read_memory(1, -info.address + 2)
+ info.read_memory(1, -info.address - 1)
...
because reading from address 2 succeeds. Using address -1 instead does
generate the expected gdb.MemoryError.
Tested on x86_64-linux.
|
|
When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get:
...
(gdb) p cmplx (4,4,16)^M
/home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \
Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error)
...
The problem is that 16-byte floats are unsupported:
...
$ gfortran test.f90
test.f90:2:17:
2 | REAL(kind=16) :: foo = 1
| 1
Error: Kind 16 not supported for type REAL at (1)
...
and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with
code TYPE_CODE_ERROR.
Fix this by bailing out asap when encountering such a type.
Without this patch we're able to do the rather useless:
...
(gdb) ptype real*16
type = real*16
(gdb) ptype real_16
type = real*16
...
but with this patch we get:
...
(gdb) ptype real*16
unsupported kind 16 for type real*4
(gdb) ptype real_16
unsupported type real*16
...
Tested on arm-linux.
PR fortran/30537
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537
|
|
When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie),
I run into:
...
Expecting: ^(-var-create A_String_Access \* A_String_Access[
]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[
]+[(]gdb[)]
[ ]*)
-var-create A_String_Access * A_String_Access
^error,msg="Cannot access memory at address 0x4"
(gdb)
FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
...
This is similar to the problem fixed by commit c5a72a8d1c3 ("[gdb/testsuite]
Fix regexp in gdb.ada/mi_var_access.exp").
The problem in both cases is that we're printing an uninitialized variable,
and consequently we can run into various error messages during printing.
Fix this as in the other commit, by accepting the error message.
Tested on arm-linux.
|
|
Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the
.debug_macro section.
For one malformed macro definition, I get two identical complaints:
...
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
...
Fix this by bailing out after the first one.
Tested on aarch64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
It also tests the gcore script being run without its accessible
terminal.
This test was written by Jan Kratochvil a long time ago. I modernized
the test making it use various procs from lib/gdb.exp, reorganizing it
and added some comments.
Modify the gcore script to make it possible to pass the --data-directory to
it. This prevents a lot of these warnings:
Python Exception <class 'AttributeError'>: module 'gdb' has no attribute
'_handle_missing_debuginfo'
Tested by using make check-all-boards.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we
run into:
...
(gdb) save gdb-index index_1^M
Error while writing index for `xgdb': No debugging symbols^M
(gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file
...
Fix this by instead emitting an unsupported, and bailing out.
Tested on aarch64-linux.
|
|
When running test-case gdb.threads/leader-exit-attach.exp with target board
native-extended-gdbserver I run into:
...
(gdb) KFAIL: $exp: attach (PRMS: gdb/31555)
print $_inferior_thread_count^M
$1 = 0^M
(gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554)
...
The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dcc
("Fix "attach" failure handling with GDBserver"), and consequently the PR is
closed.
Fix this by removing the corresponding kfail.
Tested on x86_64-linux.
|
|
With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into:
...
(gdb) attach 18591^M
Attaching to program: leader-exit-attach, process 18591^M
warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555)
^M
ptrace: Operation not permitted.^M
(gdb) FAIL: $exp: get valueof "$_inferior_thread_count"
...
The problem is that the gdb_test_multiple in the test-case doesn't consume the
prompt in all clauses:
...
gdb_test_multiple "attach $testpid" "attach" {
-re "Attaching to process $testpid failed.*" {
# GNU/Linux gdbserver. Linux ptrace does not let you attach
# to zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "warning: process $testpid is a zombie - the process has already terminated.*" {
# Native GNU/Linux. Linux ptrace does not let you attach to
# zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" {
pass $gdb_test_name
set attached 1
}
}
...
Fix this by using -wrap in the first two clauses.
While we're at it, also use -wrap in the third clause.
Tested on x86_64-linux.
|
|
After a recent patch review I asked myself why can_spawn_for_attach
exists. This proc currently does some checks, and then calls
can_spawn_for_attach_1 which is an actual caching proc.
The answer is that can_spawn_for_attach exists in order to call
gdb_exit the first time can_spawn_for_attach is called within any test
script.
The reason this is useful is that can_spawn_for_attach_1 calls
gdb_exit. If the user calls can_spawn_for_attach_1 directly then a
problem might exist. Imagine a test written like this:
gdb_start
if { [can_spawn_for_attach_1] } {
... do stuff that assumes GDB is running ...
}
If this test is NOT the first test run, and if an earlier test calls
can_spawn_for_attach_1, then when the above test is run the
can_spawn_for_attach_1 call will return the cached value and gdb_exit
will not be called.
But, if the above test IS the first test run then
can_spawn_for_attach_1 will not return the cached value, but will
instead compute the cached value, a process that ends up calling
gdb_exit. When can_spawn_for_attach_1 returns GDB will have exited
and the test might fail if it is written assuming that GDB is
running.
So can_spawn_for_attach was added which ensures that we _always_ call
gdb_exit the first time can_spawn_for_attach is called within a single
test script, this ensures that in the above case, even if the above is
not the first test script run, gdb_exit will still be called. This
ensures consistent behaviour and avoids some hidden bugs in the
testsuite.
The split between can_spawn_for_attach and can_spawn_for_attach_1 was
introduced in this commit:
commit 147fe7f9fb9a89b217d11d73053f53e8edacf90f
Date: Mon May 6 14:27:09 2024 +0200
[gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach
However, I observe that can_spawn_for_attach is not the only caching
proc that calls gdb_exit. Why does can_spawn_for_attach get special
treatment when surely the same issue exists for any other caching proc
that calls gdb_exit?
I think a better solution is to move the logic from
can_spawn_for_attach into cache.exp and generalise it so that it
applies to all caching procs.
This commit does this by:
1. When the underlying caching proc is executed we track calls to
gdb_exit. If a caching proc calls gdb_exit then this information
is stored in gdb_data_cache (using a ',exit' suffix), and also
written to the cache file if appropriate.
2. When a cached value is returned from gdb_do_cache, if the
underlying proc would have called gdb_exit, and if this is the
first use of the caching proc in this test script, then we call
gdb_exit.
When storing the ',exit' value into the on-disk cache file, the flag
value is stored on a second line. Currently every cached value only
occupies a single line, and a check is added to ensure this remains
true in the future.
To track calls to gdb_exit I eventually settled on using TCL's trace
mechanism. We already make use of this in lib/gdb.exp so I figure
this is OK to use. This should be fine, so long as non of the caching
procs use 'with_override' to replace gdb_exit, or do any other proc
replacement to change gdb_exit, however, I think that is pretty
unlikely.
One issue did come up in testing, a FAIL in gdb.base/break-interp.exp,
prior to this commit can_spawn_for_attach would call gdb_exit before
calling the underlying caching proc. After this call we call gdb_exit
after calling the caching proc.
The underlying caching proc relies on gdb_exit having been called. To
resolve this issue I just added a call to gdb_exit into
can_spawn_for_attach.
With this done can_spawn_for_attach_1 can be renamed to
can_spawn_for_attach, and the existing can_spawn_for_attach can be
deleted.
|
|
In the next commit I want to add more information to
gdb_data_cache (see lib/cache.exp). Specifically I want to track if
the underlying function of a caching proc calls gdb_exit or not.
Currently gdb_data_cache is an associative array, the keys of which
are the name of the caching proc.
In this commit I add a ',value' suffix to the gdb_data_cache keys. In
the next commit I'll add additional entries with a different suffix.
There should be no noticable changes after this commit, this is just a
restructuring.
|
|
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
This may or may not be a kernel bug.
Work around this by first using an inoffensive address bpts[i].address & ~0x7.
Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on
target board native-gdbserver/mthumb.
While we're at it:
- use arm_hwbp_control_is_initialized in
arm_linux_nat_target::low_prepare_to_resume,
- handle the !arm_hwbp_control_is_initialized case explicitly,
- add missing '_()' in arm_target::low_prepare_to_resume,
- make error messages identical between arm_target::low_prepare_to_resume and
arm_linux_nat_target::low_prepare_to_resume,
- factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to
make the implementation more readable.
Remove the tentative xfail added in d0af16d5a10 ("[gdb/testsuite] Add xfail in
gdb.base/hbreak.exp") by simply reverting the commit.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
It was pointed out in this message:
https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com
That the test gdb.base/build-id-seqno.exp I added recently was FAILing
when using Clang as the compiler.
The problem was that I had failed to add 'build-id' as a compile
option in the call to build_executable within the test script. For
GCC this is fine as build-ids are included by default. For Clang
though this meant the build-id was not included and the test would
fail.
So I added build-id to the compiler options.... and the test still
didn't pass! Now the test fails to compile and I see this error from
the compiler:
gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \
input unused [-Wunused-command-line-argument]
It turns out that the build-id compile option causes our gdb.exp to
add the '-Wl,--build-id' option into the compiler flags, which means
its used when building the object file AND during the final link.
However this option is unnecessary when creating the object file and
Clang warns about this, which causes the build to fail.
The solution is to change gdb.exp, instead of adding the build-id
flags like this:
lappend new_options "additional_flags=-Wl,--build-id"
we should instead add them like:
lappend new_options "ldflags=-Wl,--build-id"
Now the flag is only appended during the link phase and Clang is
happy. The gdb.base/build-id-seqno.exp test now passes with Clang.
The same problem (adding to additional_flags instead of ldflags)
exists for the no-build-id compile option, so I've fixed that too.
While investigating this I also spotted two test scripts,
gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were
setting ldflag directly rather than using the build-id compile option
so I've updated these two tests to use the compile option which I
think is neater.
I've checked that all these tests still pass with both GCC and Clang.
There should be no changes in what is actually tested after this
commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Consider test.c, compiled with -g:
...
__complex__ float cf = 1 + 2i;
int main (void) { return 0; }
...
The values of cf and its components are:
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) p cf
$1 = 1 + 2i
(gdb) p $_creal(cf)
$2 = 1
(gdb) p $_cimag(cf)
$3 = 2
...
and their respective types are:
...
(gdb) ptype $1
type = complex float
(gdb) ptype $2
type = float
(gdb) ptype $3
type = float
...
Now let's try that again, using ptype directly:
...
(gdb) ptype cf
type = complex float
(gdb) ptype $_creal(cf)
type = int
(gdb) ptype $_cimag(cf)
type = int
...
The last two types should have been float, not int.
Fix this by extending the internal function handlers creal_internal_fn and
cimag_internal_fn with the noside parameter, such that we get instead:
...
(gdb) ptype $_creal(cf)
type = float
(gdb) ptype $_cimag(cf)
type = float
...
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR exp/31816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816
|
|
Sometimes, if I'm testing on a loaded machine, the
gdb.gdb/index-file.exp test will timeout during some early steps,
which then cases a TCL error to be thrown later in the test script.
Dejagnu then reports this error once the test run has completed, which
can be pretty noisy, and isn't really very helpful.
The underlying problem is that if GDB takes too long to load the
executable (which is GDB itself in this test) then GDB will still be
busy loading the executable when dejagnu moves on and call
gdb_get_worker_threads. The gdb_get_worker_threads call itself times
out as GDB is _still_ busy loading the executable, and so
gdb_get_worker_threads returns the string "UNKNOWN".
Later we try to perform arithmetic on the worker thread count, which
results in errors when we try to do 'UNKNOWN / 2'.
I propose that after calling gdb_get_worker_threads, we check if the
result was UNKNOWN. If it was then we should report an UNRESOLVED and
abandon the test, this avoids the later TCL errors.
|
|
On s390x-linux, I ran into:
...
(gdb) ptype crash^M
type = class crash {^M
^M
public:^M
crash(int (class {...}::*)(class {...} * const @mode32));^M
}^M
(gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash
...
The problem is that the test-case doesn't expect the address class annotation
@mode32.
The test-case uses a .S file, with the address size hard-coded to 4 bytes, and
that's something that is annotated with @mode32 on s390x (which uses 8 byte
addresses).
Fix this by allowing the annotation in the regexp.
Likewise in two other test-cases.
Tested on s390-linux and x86_64-linux.
|
|
With test-case gdb.cp/m-static.exp on arm-linux, I get:
...
(gdb) ptype test5.single_constructor^M
type = class single_constructor {^M
^M
public:^M
single_constructor(void);^M
~single_constructor(void);^M
} *(single_constructor * const)^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype constructor
...
The test-case expects:
- no empty line before "public:", and
- no "~single_constructor(void)", but "~single_constructor()"
The latter is due to commit 137c886e9a6 ("[gdb/c++] Print destructor the same
for gcc and clang").
The failing test is in a part only enabled for is_aarch32_target == 1, so it
looks like it was left behind.
I'm assuming the same happened for the other difference.
Fix this by updating the regexps to match the observed output.
Tested on arm-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The DAP spec recently changed to add a new scope for the return value
from a "stepOut" request. This new scope uses the "returnValue"
presentation hint. See:
https://github.com/microsoft/debug-adapter-protocol/issues/458
This patch implements this for gdb.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31945
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
I'm not sure if this is simply unsupported or if there's a kernel bug of some
sort, but I don't see what gdb can do about this.
Tentatively mark this as xfail.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
On arm-linux, I run into:
...
PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me
Expecting: ^(-stack-list-arguments 1[^M
]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|<optimized out>)"})?\]},.*[^M
]+[(]gdb[)] ^M
[ ]*)
-stack-list-arguments 1^M
^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that the test-case expects a level 3 frame, but there is none.
This can be reproduced using cli bt:
...
$ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \
-ex "b task_switch.break_me" \
-ex run \
-ex bt
Breakpoint 1 at 0x34b4: file task_switch.adb, line 57.
Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \
at task_switch.adb:57
57 null;
#0 task_switch.break_me () at task_switch.adb:57
#1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51
#2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
...
The purpose of the test-case is printing the frame at level 1, so I don't
think we should bother about the presence of the frame at level 3.
Fix this by allowing the backtrace to stop at level 2.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
