| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When running test-case gdb.ada/big_packed_array.exp on s390x-linux, I run
into:
...
(gdb) print bad^M
$2 = (0 => 0 <repeats 24 times>, 1)^M
(gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
...
This is with gcc 7.5.0, and this xfail should trigger:
...
if { $have_xfail && [string is integer $last] \
&& [expr ($last & 0xf) == 0] } {
# gcc/101643
setup_xfail *-*-*
}
...
but it doesn't because $last is '1'.
Fix this by using 0xf0 as mask for big endian.
Tested on s390x-linux.
|
|
When running test-case gdb.ada/convvar_comp.exp on s390x-linux, I get:
...
(gdb) run ^M
Starting program: pb16_063 ^M
^M
Breakpoint 1, pck.break_me (item=...) at pck.adb:17^M
17 function Break_Me (Item : T) return Boolean is^M
(gdb) print item.started^M
Cannot access memory at address 0x0^M
(gdb) FAIL: gdb.ada/convvar_comp.exp: print item.started
...
This happens as follows.
The parameter item is available in (DW_OP_fbreg: -168):
...
<2><912>: Abbrev Number: 18 (DW_TAG_formal_parameter)
<913> DW_AT_name : (indirect string, offset: 0x14ca): item
<919> DW_AT_type : <0x929>
<91d> DW_AT_location : 3 byte block: 91 d8 7e (DW_OP_fbreg: -168)
...
and according to the rules of -O0, it's considered to be available after the
prologue, which looks like this:
...
0000000001002998 <pck__break_me>:
1002998: b3 c1 00 2b ldgr %f2,%r11
100299c: b3 c1 00 0f ldgr %f0,%r15
10029a0: e3 f0 ff 58 ff 71 lay %r15,-168(%r15)
10029a6: b9 04 00 bf lgr %r11,%r15
10029aa: e3 20 b0 a0 00 24 stg %r2,160(%r11)
...
To detect the prologue, gdb checks the line info, which looks like this:
...
pck.adb:
File name Line number Starting address View Stmt
pck.adb 17 0x1002998 x
pck.adb 17 0x1002998 1 x
pck.adb 19 0x10029b0 x
pck.adb 20 0x10029b8 x
pck.adb - 0x10029c6
...
and gdb concludes that it's an empty prologue, so we stop at 0x1002998 and
try to print parameter item, which is not available yet.
For more details, see this comment in skip_prologue_using_sal:
...
/* For languages other than assembly, treat two consecutive line
entries at the same address as a zero-instruction prologue.
...
The same thing happens on x86_64-linux, but it causes no problem there,
because amd64_skip_prologue decides not to trust the result:
...
struct compunit_symtab *cust = find_pc_compunit_symtab (func_addr);
/* LLVM backend (Clang/Flang) always emits a line note before the
prologue and another one after. We trust clang and newer Intel
compilers to emit usable line notes. */
if (post_prologue_pc
&& (cust != NULL
&& cust->producer () != nullptr
&& (producer_is_llvm (cust->producer ())
|| producer_is_icc_ge_19 (cust->producer ()))))
return std::max (start_pc, post_prologue_pc);
...
because the producer is GCC.
Work around this by setting a breakpoint on the first statement of
pck.break_me instead.
Tested on s390x-linux.
|
|
In some cases, test-cases use c++, but don't add "c++" to the compilation
flags. This can cause problems with some compilers.
Fix this in some test-cases.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/30380
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30380
|
|
On openSUSE Leap 15.6 with test-case gdb.base/list-dot-nodebug.exp I run into:
...
(gdb) list .^M
warning: 1 ../sysdeps/x86_64/crtn.S: No such file or directory^M
(gdb) FAIL: $exp: debug=none: print before start
...
The intent of the debug=none case is to generate an executable with no debug
info. However, we have quite a few CUs with debug info:
...
$ readelf -wi outputs/gdb.base/list-dot-nodebug/list-dot-nodebug-none \
| egrep -c " @ "
431
...
This is because this code:
...
gdb_gnu_strip_debug $executable no-debuglink
...
uses $executable, and the variable is set here:
...
set executable ${testfile}-none
...
which sets it to "list-dot-nodebug-none" and consequently
gdb_gnu_strip_debug cannot find it.
Fix this by using "[standard_output_file $executable]" instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31721
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721
|
|
When running test-case gdb.tui/main.exp, the last command discards the
executable file and symbol table:
...
(gdb) file
No executable file now.
Discard symbol table from `main'? (y or n) [answered Y; input not from terminal]
No symbol file now.
(gdb)
...
and we end up with this source window:
...
+-tui-layout.c----------------------------------------------------------------+
| |
| |
| |
| |
| |
| |
| [ No Source Available ] |
| |
| |
| |
| |
| |
| |
+-----------------------------------------------------------------------------+
...
The source window title shouldn't be showing tui-layout.c. It's the source
file containing function main for the executable that was just discarded.
Fix this by clearing the title in tui_source_window::erase_source_content.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Run `pre-commit autoupdate`.
This picks up a fresh Black version from 2025, and with it comes a small
but welcome formatting change.
There is a new version of isort as well, but no formatting change there.
Change-Id: Ie654a9c14c3a4096893011082668efb57c166fa4
|
|
After syncing with strace v6.13 using:
...
$ update-linux-defaults.sh ~/upstream/strace.git
...
we have a few new entries in linux-defaults.xml.in:
...
<syscall name="getxattrat" groups="descriptor,file"/>
<syscall name="listxattrat" groups="descriptor,file"/>
<syscall name="removexattrat" groups="descriptor,file"/>
<syscall name="setxattrat" groups="descriptor,file"/>
...
Regenerate most *-linux.xml.in files using:
...
$ ./update-linux-from-src.sh ~/upstream/linux-stable.git
...
updating the copyright years, and do so manually for the remaining two.
Then regenerate *-linux.xml using make, propagating the groups changes and
copyright years.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When I run:
runtest dw2-using-debug-str.exp
... if I examine the gdb.log, I see:
objcopy: unable to copy file '[...]/dw2-using-debug-str'; reason: Text file busy
This happens because the inferior is still running, and objcopy --
despite the invocation seemingly not needing this -- tries to open it
for writing.
This patch works around the objcopy oddity by having gdb exit (killing
the inferior) before the invocation.
Fixing this points out that the test does not work in the
--target_board=cc-with-gdb-index case. This patch also arranges to
issue an "untested" here.
|
|
There is a test in gdb.cp/var-tag.exp that is kfail'd. I happened
across this while working on another series and found that the PR it
referenced was closed as invalid. On that basis I think the test
should be deleted.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
I neglected to update "maint print psymbols" when adding TYPE_DOMAIN
and FUNCTION_DOMAIN. This would have been mildly helpful when
debugging a series I am working on. This patch corrects the
oversight.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I noticed a spot that uses 0 where "false" is more appropriate.
|
|
The Rust compiler emits tuple type names with a space after the comma,
like "(i32, f64)". This changes rust-parse.c to follow. This isn't
ideal -- probably the DWARF reader should canonicalize these names --
but it is a bit more robust if symbol lookup should change; and anyway
this feature of gdb is probably rarely used.
|
|
A couple of ".tcl" files in gdb.dwarf2 escaped notice during the
"require" refactoring. This patch fixes these to use "require" rather
than if/return.
|
|
When the changes on the remote protocol are made,
we want to test all the corner cases to prevent
regressions. Currently it can be tricky to simulate
some corner case conditions that would expose possible
regressions. When I want to add or change the remote
protocol packet, I need to hack gdbserver to send a
corrupted packet or an error to make sure GDB is able
to handle such a case.
This test makes it easy to send a corruped packet or
an error message to GDB using the gdbreplay tool and
check GDB deals with it as we expect it to.
This test starts a communication with gdbsever setting
the remotelog file. Then, it modifies the remotelog with
update_log proc, injects an error message instead of
the expected replay to the vMustReplyEmpty packet in order
to test GDB reacts to the error response properly. After
the remotelog modification, this test restarts GDB and starts
communication with gdbreply instead of the gdbserver using
the remotelog.
Add a lib/gdbreplay-support.exp. update_log proc matches lines
from GDB to gdbserver in a remotelogfile. Once a match is found then
the custom line is used to build a replacement line to send from
gdbserver to GDB.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
All the reported races have been fixed, so this patch re-enabled
background DWARF reading.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751
Tested-By: Tom de Vries <tdevries@suse.de>
|
|
These includes are reported as unused by clangd.
Change-Id: Ibf3cdc881abad5f5969edca623412ceac7212149
|
|
They are unused, according to clangd.
Add some includes to other files, which were relying on transitive
includes.
Change-Id: I3bcb4be93b3a18bf44a4068f4067e567f83e1d4f
|
|
It is unused, according to clangd.
Change-Id: Ieadb84a2b1953b70d82a28775472fd347a809a62
|
|
dwarf2_per_bfd is used but never declared in this file, forward-declare
it.
dwarf2/types.h is unused, according to clangd.
Change-Id: I324b68894008af20307030c9e36c5abe06e36a78
|
|
This include is unused, according to clangd.
Change-Id: Ifbc2fe75b02c9ae9b3e2f1184bbcc4dc7095a554
|
|
quick-symbol.h uses domain_search_flags, defined in symtab.h.
Change-Id: I5c4ae272da929eb6a8dd593bcd96a2aacf0ca99f
|
|
With test-case gdb.python/py-mi-notify.exp and python 3.4, I occasionally run
into:
...
python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
=-test-notification,data2="2",data1="1"
^done
(gdb)
FAIL: $exp: python notification, with additional data (unexpected output)
...
In contrast, a passing version looks like:
...
python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
=-test-notification,data1="1",data2="2"
^done
(gdb)
PASS: gdb.python/py-mi-notify.exp: python notification, with additional data
...
The python method "gdb.notify_mi(name, data)" has parameter data which is a
dictionary, and it iterates over that dictionary.
The problem is that dictionaries are only guaranteed to be iterating in
insertion order starting python 3.7 (though cpython does this starting python
3.6).
Fix this in the same way as in commit 362a867f2ac ("[gdb/testsuite] Handle
unordered dict in gdb.python/py-mi-cmd.exp"): by allowing the alternative
order.
Tested on x86_64-linux.
|
|
cmd_show_list is a bit funny because it shows partial command names --
for a command like "show abc xyz", it will only show "abc xyz".
Nevertheless, I think it makes some sense to highlight these with the
command style. That is what this patch does.
|
|
show_index_cache_command prints whether the index-cache is enabled.
This text was added back in 2018 in commit 87d6a7aa (Add DWARF index
cache). Then in 2021, the enabling option was changed via commit
7bc5c369 (gdb: introduce "set index-cache enabled", deprecate "set
index-cache on/off").
This latter change made this output, IMO, redundant. That is,
currently gdb will show:
(gdb) show index-cache
...
index-cache enabled: The index cache is off.
...
The index cache is currently disabled.
This patch removes the redundant output.
|
|
This changes the help command to use the new command style when
displaying text like:
List of "catch" subcommands:
As a side effect, this mildly -- but not hugely -- cleans up some i18n
issues in help_list. The header comment for that function is also
changed to the gdb style.
Finally, this function used to print something like:
Type "help catch" followed by catch subcommand name for full documentation.
The second "catch" here seems redundant to me, so this patch removes
it.
|
|
I think there is no need to have a prefix command that simply calls
help_list. Instead, add_basic_prefix_cmd can be used. This patch
changes the relevant instances. In one spot, add_setshow_prefix_cmd
is used instead.
|
|
PR 32610 says:
File gdb/darwin-nat.c is missing an #include statement of
"cli/cli-style.h". It is needed because there is a reference to class
object command_style in the .c file.
I'm not able to build-test this change (I only have access to arm64
macos machines, which GDB doesn't support yet), but I don't think I'm
doing things worse by adding this.
Change-Id: I2a169664ff91b92caf27cb084334f2eb4df46aa5
|
|
Add comments to the assembler generated by the DWARF assembler that
builds the line table. I found these comments useful when debugging
issues with the line table parsing.
This patch should make no difference to what is being tested. The
test binaries should be unchanged after this commit.
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
The debug output that says a line has been recorded is currently
outside the `if` block which decides if the line should be recorded or
not. This means the debug output will claim the line was recorded,
when actually it wasn't!
Fixed by moving the debug output inside the `if` block.
Should be no user visible changes after this commit (except if debug
output is turned on).
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This is a preparatory patch to support native linux port
of gdbserver for MicroBlaze
* gdb/features/Makefile : Add microblaze-expedite
* gdb/features/microblaze-linux.xml : New
* gdb/features/microblaze-linux.c : New (generated)
* gdb/regformats/microblaze-linux.dat : New (generated)
Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com>
Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com>
Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com>
Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
|
|
Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this:
...
$ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \
-ex "b f2"\
-ex run
...
(from a directory not containing a file called main.c to make sure that the
missing source stays missing) and then issue finish:
...
(gdb) finish
Run till exit from #0 f2 (x=4)
at f2.c:5
0x0000000000400570 in main ()
at main.c:7
Value returned is $1 = 13
(gdb)
...
and use control-<minus> to decrease the font size (IOW increase the $LINES and
$COLUMNS) on the terminal, we get:
...
gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \
Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
The tui_source_window_base class has variable m_pad which keeps track of a
curses pad that is used to display the source code or disassembly efficiently.
The assert in tui_source_window_base::refresh_window triggers while preparing
to display part of the pad.
The problem is that the window is in a state in which the pad is not used,
because m_content.empty () == true. Instead, it simply shows
"[ No Source Available ]".
Fix this by bailing out of tui_source_window_base::refresh_window before
accessing the m_pad variable, if m_content.empty () == true.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/32592
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32592
|
|
I build gdb with libguile v2.0.9, and ran into:
...
In file included from /usr/include/guile/2.0/libguile.h:56,
from ../../gdb/guile/guile-internal.h:30,
from ../../gdb/guile/scm-arch.c:26:
/usr/include/guile/2.0/libguile/inline.h: In function 'int scm_is_pair(SCM)':
/usr/include/guile/2.0/libguile/tags.h:97:53: error: \
operation on '*0' may be undefined [-Werror=sequence-point]
# define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))
~~~~~~~~~^~~~~
...
Fix this by using SCM_DEBUG_TYPING_STRICTNESS 0.
We were already using this for c++20 due to a Werror=volatile in SCM_UNPACK
when using libguile v2.0.10.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
We found that the gdb.ada/import.exp test fails when 'mold' is used as
the linker. This happens because mold decides to mark most of the
symbols in the executable as being file-local. I tend to think this
choice, while non-traditional, is probably fine. So, this patch fixes
the problem by changing the relevant Ada code to look for file-local
symbols as well.
Furthermore, there are two overloads of lookup_minimal_symbol_linkage
that both have a final 'bool' parameter -- but with radically
different meanings. This patch somewhat clears up this confusion as
well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31378
|
|
This mailing list discussion:
https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com
highlighted the following issue with GDB's 'x' packet implementation.
Unfortunately, LLDB also has an 'x' packet, but their implementation
is different to GDB's and so targets that have implemented LLDB's 'x'
packet are incompatible with GDB.
The above thread is specifically about the 'rr' tool, but there could
be other remote targets out there that have this problem.
The difference between LLDB and GDB is that GDB expects a 'b' prefix
on the reply data, while LLDB does not. The 'b' is important as it
allows GDB to distinguish between an empty reply (which will be a 'b'
prefix with no trailing data) and an unsupported packet (which will be
a completely empty packet). It is not clear to me how LLDB
distinguishes these two cases.
See for discussion of the 'x' packet:
https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r
with the part specific to the 'b' marker in:
https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/
I propose that we add a new feature 'binary-upload' which can be
reported by a stub in its qSupported reply. By default this feature
is "off", meaning GDB will not use the 'x' packet unless a stub
advertises this feature.
I have updated gdbserver to send 'binary-upload+', and when I examine
the gdbserver log I can see this feature being sent back, and then GDB
will use the 'x' packet.
When connecting to an older gdbserver, the feature is not sent, and
GDB does not try to use the 'x' packet at all.
I also built the latest version of `rr` and tested using current HEAD
of master, where I see problems like this:
(rr) x/10i main
0x401106 <main>: Cannot access memory at address 0x401106
Then tested using this patched version of GDB, and now I see:
(rr) x/10i main
0x401106 <main>: push %rbp
0x401107 <main+1>: mov %rsp,%rbp
0x40110a <main+4>: mov 0x2f17(%rip),%rax # 0x404028 <global_ptr>
... etc ...
and looking in the remote log I see GDB is now using the 'm' packet
instead of the 'x' packet.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32593
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
|
|
As PR sim/28684 explains, it isn't possible to compile GDB with all
targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd
is forced, so the build works, but in 32 bit hosts, that has to be
explicitly enabled.
I ran into this when I tried compiling GDB on a mips64 machine running a
32 bit OS. Along with the errors in the PR, several other architectures
are also required, notably aarch64 and other explicitly 64bit targets.
Additionally, some 32 bit files required for the gdb mips target aren't
added to the makefile.
Considering the last comment in the bug says this isn't going to be
fixed on the binutils side, I didn't think it was worth trying to fix
the GDB side. Instead, this commit causes the configure script to fail
if all targets were requested and 64 bit bfd isn't enabled. If that is
ever fixed, we can revert this commit.
I considered adding this to the top level configure script, but couldn't
figure out how to detect the situation in there, so this was my next
best idea.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/gdb.texinfo:42613: warning: `.' or `,' must follow @xref, not `f'.
...
This is related to this line:
...
@xref{Standard Replies} for standard error responses, and how to
respond indicating a command is not supported.
...
Fix this by adding a comma.
Tested by rebuilding the docs.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
|
|
When building gdb with gcc 7.5.0, I run into:
...
gdb/dwarf2/cooked-index.c: In lambda function:
gdb/dwarf2/cooked-index.c:104:5: error: \
the value of ‘_sch_tolower’ is not usable in a constant expression
};
^
In file included from gdbsupport/gdb-safe-ctype.h:47:0,
from gdb/dwarf2/cooked-index.c:34:
include/safe-ctype.h:111:29: note: ‘_sch_tolower’ was not declared ‘constexpr’
extern const unsigned char _sch_tolower[256];
^~~~~~~~~~~~
...
This does not happen with gcc 8.2.1.
Fix this by dropping the constexpr on lambda function munge in
cooked_index_entry::compare for gcc 7.
Tested by completing the build on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/gdb.texinfo:49064: warning: @sc argument all uppercase, thus no effect.
...
Using a grep, I found one more instance:
...
$ grep @sc gdb/doc/*.tex* | egrep -v '@sc{[^A-Z]*}'
gdb/doc/gdb.texinfo:\
Bit 1 (@sc{ZA}) shows whether the @code{ZA} register state is active (in use) or
gdb/doc/python.texi:\
corresponding @sc{GDB/MI} command's output. Refer to the
...
Fix this by using lowercase letters in the @sc argument, similar to how that
was done in commit c96452ad168 ("Use lower-case in @sc in the documentation").
Tested by rebuilding the documentation.
|
|
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/gdb.texinfo:44159: @anchor expected braces.
gdb/doc/gdb.texinfo:44159: ` {qIsAddressTagged}
...
This is related to this line:
...
@anchor {qIsAddressTagged}
...
Fix this by removing the space before the left brace.
Tested by rebuilding the documentation.
|
|
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/python.texi:3015: warning: `(' follows defined name \
`gdb.unwinder.Unwinder.__init__' instead of whitespace.
gdb/doc/python.texi:3041: warning: `(' follows defined name \
`gdb.unwinder.FrameId.__init__' instead of whitespace.
...
The warnings are related to these two lines:
...
@defun gdb.unwinder.Unwinder.__init__(name)
...
@defun gdb.unwinder.FrameId.__init__(sp, pc, special = @code{None})
...
Indeed, when checking the command and variable index, we can see that it
contains an incorrect entry:
...
gdb.unwinder.FrameId.__init__(sp,: Unwinding Frames in Python
...
Fix this by adding a space before the left parenthesis.
Tested by rebuilding the documentation and checking the command and variable
index.
|
|
Reviewed-By Richard Earnshaw <richard.earnshaw@arm.com>
|
|
In commit 64a97606 ("Support template lookups in
strncmp_iw_with_mode"), gdb was changed so that a command like "break
func<templ>" would match instantiations like "func<templ<int>>".
The new indexer does not support this and so this is a regression.
This went unnoticed because gdb.linespec.cpcompletion.exp puts all
these functions into the main file, and this CU is expanded early.
This patch fixes the bug by changing the cooked index entry comparison
function. It also updates the test to fail without this fix.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32482
|
|
In RISC-V, the general registers can be shown in their abi
form (e.g. sp, a0) or their numeric form (e.g. x2, x10).
Depending on context/preference, someone may prefer to
see one form over the other. The disassembler already
supports this configuration, which can be changed using
the 'set disassembler-options numeric' command.
This commit adds a new set/show command to change gdb's
preference: 'set riscv numeric-registers-names on/off'.
If on, 'info registers' and other situations will print
the numeric register names, rather than the abi versions.
The alias generation has been modified so that the abi
versions are still available for access if specifically
requested such as 'print $ra'. This was done by changing
the behaviour of the code which adds the aliases: all
register names will be added as aliases, even if the name
is the primary one.
There is also no functional downside to adding aliases
which are surplus-to-requirement, since they will be
ignored if there is a 'true' register with the same
name.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
With test-case gdb.ada/O2_float_param.exp on s390x-linux, I get:
...
(gdb) frame^M
#0 callee.increment (val=99.0, val@entry=<error reading variable: \
register has not been saved in frame>, msg=...) at callee.adb:19^M
19 procedure Increment (Val : in out Float; Msg: String) is^M
(gdb) FAIL: $exp: scenario=all: frame
...
The frame command calls read_frame_arg to get:
- the current value of val, and
- the value of val at function entry.
The first scenario succeeds, and the second scenario fails.
For context and contrast, let's also investigate the first scenario: getting
the current value of val.
Function parameter val:
...
<2><b51>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<b52> DW_AT_name : val
<b58> DW_AT_type : <0xb86>
<b5c> DW_AT_location : 0xab (location list)
...
has location list:
...
000000ab 0000000001002928 0000000001002967
(DW_OP_reg16 (f0))
000000be 0000000001002967 0000000001002968
(DW_OP_reg24 (f8))
000000d1 0000000001002968 0000000001002974
(DW_OP_GNU_regval_type: 24 (f8) <0xb29>;
DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus;
DW_OP_stack_value)
000000ef 0000000001002974 0000000001002982
(DW_OP_GNU_entry_value: (DW_OP_GNU_regval_type: 16 (f0) <0xb29>);
DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus;
DW_OP_stack_value)
0000010f <End of list>
...
and since we're stopped at address 0x1002928:
...
(gdb) print $pc
$1 = (access procedure) 0x1002928 <callee.increment>
...
we get the value from dwarf register 16.
The s390x ABI [1] specifies that dwarf register 16 maps onto 8-byte register
f0 or 16-byte register v0 (where f0 is part of v0), and in this case (because
the v0 register is available) s390_dwarf_reg_to_regnum maps it to v0.
Val is only 4 bytes:
...
(gdb) ptype val
type = <4-byte float>
...
and s390_value_from_register takes care to get the value from the correct part
of v0.
The value of v0 is found in the prologue cache, and the value of parameter val
is printed.
Now the second scenario: getting the value of val at function entry.
FWIW, since we're stopped at function entry, we could simply return the same
value, reading the same register, but that's currently not implemented [2].
Instead we start from the fact that val is in dwarf reg 16 at function entry,
and then use call site information:
...
<4><cf7>: Abbrev Number: 13 (DW_TAG_GNU_call_site)
<cf8> DW_AT_low_pc : 0x1002a46
<d00> DW_AT_abstract_origin: <0xdda>
<5><d04>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter)
<d05> DW_AT_location : 1 byte block: 60 (DW_OP_reg16 (f0))
<d07> DW_AT_GNU_call_site_value: 3 byte block: f5 18 2d \
(DW_OP_GNU_regval_type: 24 (f8) <0xc42>)
<5><d0b>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter)
...
to conclude that the value we're looking for is in dwarf reg 24, which
s390_dwarf_reg_to_regnum maps to v8.
As before, s390_value_from_register takes care to get the value from the
correct part of v8.
However, v8 is not available in the prologue cache, and we take a different
path and end up in s390_unwind_pseudo_register, where v8 and similar
(regnum_is_vxr_full) is unhandled, and we get:
...
return value::allocate_optimized_out (type);
...
which eventually causes the "error reading variable: register has not been
saved in frame".
Fix this by handling the regnum_is_vxr_full case in
s390_unwind_pseudo_register, similar to how that is done in
s390_pseudo_register_read.
Tested on s390x-linux.
This also fixes test-case gdb.base/savedregs.exp.
[1] https://github.com/IBM/s390x-abi
[2] https://sourceware.org/pipermail/gdb-patches/2024-September/211589.html
|
|
While stepping through gdb.reverse/time-reverse.exp I realized that we're
recording the instructions for resolving the PLT entries for functions time
and syscall, while that's not really the focus of the test-case.
Limit the scope of the test, by calling the functions once before starting
to record.
Also call "info record" after recording to make it clear how many
instructions were recorded.
On x86_64-linux, before this patch (but with info record added), we have:
...
$ grep "Log contains" gdb.log
Log contains 750 instructions.
Log contains 1218 instructions.
...
and with this patch we have:
...
$ grep "Log contains" gdb.log
Log contains 24 instructions.
Log contains 19 instructions.
...
Tested on x86_64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Consider test-case gdb.base/return-3.exp:
...
$ gdb -q outputs/gdb.base/return-3/return-3
Reading symbols from outputs/gdb.base/return-3/return-3...
(gdb)
...
Function bar is an inlined function, and consequently we cannot return from
it:
...
(gdb) b bar
Breakpoint 1 at 0x4006ac: file return-3.c, line 25.
(gdb) r
Starting program: return-3
...
Breakpoint 1, bar () at return-3.c:25
25 c++;
(gdb) return
Can not force return from an inlined function.
(gdb)
...
However, function foo is not an inline function, and we should be able to
return from it, but we get the same error message:
...
(gdb) up
31 bar ();
(gdb) return
Can not force return from an inlined function.
(gdb)
...
Fix this by using the selected frame rather than the current frame in
return_command, such that we get instead:
...
(gdb) up
31 bar ();
(gdb) return
40 printf ("%d\n", c);
(gdb)
...
Tested on aarch64-linux.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
PR cli/32479
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32479
|
|
This removes gnatmake_version_at_least in favor of using the more
flexible gnat_version_compare. I think these two version numbers
should be the same, as gnatmake is shipped with the compiler.
|
|
While testing gnat-llvm, I found a gdb crash when applying 'length to
a non-array type. This patch fixes the crash.
|
|
I found another Ada test case where gnat-llvm optimizes away the local
variables. This patch applies the same fix to it as previous patches.
|
|
On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and
test-case gdb.base/branch-to-self.exp I run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
0x0040058c 38 for (;;); /* loop-line */^M
(gdb) FAIL: $exp: single-step: si
...
In contrast, on the same machine but with debian testing and gcc 14.2.0 we have:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: stepi
...
The difference is in the instruction(s) generated for the loop.
In the passing case, we have:
...
588: eafffffe b 588 <main+0x24>
...
and in the failing case:
...
588: e320f000 nop {0}
58c: eafffffd b 588 <main+0x24>
...
The purpose of this part of the test-case is to:
- generate a branch instruction that jumps to itself, and
- set a breakpoint on it, and check that stepi-ing from that breakpoint
triggers the breakpoint again.
As we can see, in the failing case we failed to generate a branch instruction
that jumps to itself, and consequently we cannot expect to hit the breakpoint
again after issuing a single si.
Fix this by issuing stepi until we hit the breakpoint.
Tested on arm-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
