| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
The gdb.Objfile, gdb.Progspace, gdb.Type, and gdb.Inferior Python
types already have a __dict__ attribute, which allows users to create
user defined attributes within the objects. This is useful if the
user wants to cache information within an object.
This commit adds the same functionality to the gdb.InferiorThread
type.
After this commit there is a new gdb.InferiorThread.__dict__
attribute, which is a dictionary. A user can, for example, do this:
(gdb) pi
>>> t = gdb.selected_thread()
>>> t._user_attribute = 123
>>> t._user_attribute
123
>>>
There's a new test included.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The gdb.Objfile, gdb.Progspace, and gdb.Type Python types already have
a __dict__ attribute, which allows users to create user defined
attributes within the objects. This is useful if the user wants to
cache information within an object.
This commit adds the same functionality to the gdb.Inferior type.
After this commit there is a new gdb.Inferior.__dict__ attribute,
which is a dictionary. A user can, for example, do this:
(gdb) pi
>>> i = gdb.selected_inferior()
>>> i._user_attribute = 123
>>> i._user_attribute
123
>>>
There's a new test included.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that it is possible for the user to create a new
gdb.Progspace object, like this:
(gdb) pi
>>> p = gdb.Progspace()
>>> p
<gdb.Progspace object at 0x7ffad4219c10>
>>> p.is_valid()
False
As the new gdb.Progspace object is not associated with an actual C++
program_space object within GDB core, then the new gdb.Progspace is
created invalid, and there is no way in which the new object can ever
become valid.
Nor do I believe there's anywhere in the Python API where it makes
sense to consume an invalid gdb.Progspace created in this way, for
example, the gdb.Progspace could be passed as the locus to
register_type_printer, but all that would happen is that the
registered printer would never be used.
In this commit I propose to remove the ability to create new
gdb.Progspace objects. Attempting to do so now gives an error, like
this:
(gdb) pi
>>> gdb.Progspace()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot create 'gdb.Progspace' instances
Of course, there is a small risk here that some existing user code
might break ... but if that happens I don't believe the user code can
have been doing anything useful, so I see this as a small risk.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a gdb.Frame.__repr__() method. Before this patch we would see
output like this:
(gdb) pi
>>> gdb.selected_frame()
<gdb.Frame object at 0x7fa8cc2df270>
After this patch, we now see:
(gdb) pi
>>> gdb.selected_frame()
<gdb.Frame level=0 frame-id={stack=0x7ffff7da0ed0,code=0x000000000040115d,!special}>
More verbose, but, I hope, more useful.
If the gdb.Frame becomes invalid, then we will see:
(gdb) pi
>>> invalid_frame_variable
<gdb.Frame (invalid)>
which is inline with how other invalid objects are displayed.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a gdb.InferiorThread.__repr__() method. Before this patch we
would see output like this:
(gdb) pi
>>> gdb.selected_thread()
<gdb.InferiorThread object at 0x7f4dcc49b970>
After this patch, we now see:
(gdb) pi
>>> gdb.selected_thread()
<gdb.InferiorThread id=1.2 target-id="Thread 0x7ffff7da1700 (LWP 458134)">
More verbose, but, I hope, more useful.
If the gdb.InferiorThread becomes invalid, then we will see:
(gdb) pi
>>> invalid_thread_variable
<gdb.InferiorThread (invalid)>
Which is inline with how other invalid objects are displayed.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch contains work pulled from this previously proposed patch:
https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/
But has been modified by me. Credit for the original idea and
implementation goes to Lancelot, any bugs in this new iteration belong
to me.
Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is
empty other than the `foo' sub-directory, then currently within GDB,
if I type:
(gdb) file /tmp/f
and then hit TAB, GDB completes this to:
(gdb) file /tmp/foo/
notice that not only did GDB fill in the whole of `foo', but GDB also
added a trailing '/' character. This is done within readline when the
path that was just completed is a directory. However, if I instead
do:
(gdb) complete file /tmp/f
file /tmp/foo
I now see the completed directory name, but the trailing '/' is
missing. The reason is that, in this case, the completions are not
offered via readline, but are handled entirely within GDB, and so
readline never gets the chance to add the trailing '/' character.
The above patch added filename option support to GDB, which included
completion of the filename options. This initially suffered from the
same problem that I've outlined above, but the above patch proposed a
solution to this problem, but this solution only applied to filename
options (which have still not been added to GDB), and was mixed in
with the complete filename options support.
This patch pulls out just the fix for the trailing "/" problem, and
applies it to GDB's general filename completion. This patch does not
add filename options to GDB, that can always be done later, but I
think this small part is itself a useful fix.
One of the biggest changes I made in this version is that I got rid of
the set_from_readline member function, instead, I now pass the value
of m_from_readline into the completion_tracker constructor.
I then moved the addition of the trailing '/' into filename_completer
so that it is applied in the general filename completion case. I also
added a call to gdb_tilde_expand which was missing from the original
patch, I haven't tested, but I suspect that this meant that the
original patch would not add the trailing '/' if the user entered a
path starting with a tilde character.
When writing the test for this patch I ran into two problems.
The first was that the procedures in lib/completion-support.exp relied
on the command being completed for the test name. This is fine for
many commands, but not when completing a filename, if we use the
command in this case the test name will (potentially) include the name
of the directory in which the test is being run, which means we can't
compare results between two runs of GDB from different directories.
So in this commit I've gone through completion-support.exp and added a
new (optional) testname argument to many of the procedures, this
allows me to give a unique test name, that doesn't include the path
for my new tests.
The second issue was in the procedure make_tab_completion_list_re,
this builds the completion list which is displayed after a double tab
when there are multiple possible completions.
The procedure added the regexp ' +' after each completion, and then
added another ' +' at the very end of the expected output. So, if we
expected to match the name of two functions 'f1' and 'f2' the
generated regexp would be: 'f1 +f2 + +'. This would match just fine,
the actual output would be: 'f1 f2 ', notice that we get two spaces
after each function name.
However, if we complete two directory names 'd1' and 'd2' then the
output will be 'd1/ d2/ '. Notice that now we only have a single
space between each match, however, we do get the '/' added instead.
What happens is that when presenting the matches, readline always adds
the appropriate trailing character; if we performed tab completion of
'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with
a trailing space added. However, if we complete 'file d1' then we get
'file d1/'. Then readline is adding a single space after each
possible match, including the last one, which accounts for the
trailing space character.
To resolve this I've simply remove the addition o the second ' +'
within make_tab_completion_list_re, for the function completion
example I gave above the expected pattern is now 'f1 +f2 +', which for
the directory case we expect 'd1/ +d2/ +', both of which work just
fine.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265
Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
This commit adds a new InferiorThread.ptid_string attribute. This
read-only attribute contains the string returned by target_pid_to_str,
which actually converts a ptid (not pid) to a string.
This is the string that appears (at least in part) in the output of
'info threads' in the 'Target Id' column, but also in the thread
exited message that GDB prints.
Having access to this string from Python is useful for allowing
extensions identify threads in a similar way to how GDB core would
identify the thread.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In test-case gdb.dwarf2/assign-variable-value-to-register.exp a return is
missing here after the unsupported:
...
if { ![is_x86_64_m64_target] } {
unsupported "unsupported architecture"
}
...
and consequently on aarch64-linux I ran into an UNSUPPORTED followed by 3
FAILs.
Fix this by simply using require:
...
require is_x86_64_m64_target
...
Tested on x86_64-linux and aarch64-linux.
|
|
Commit 78f2fd84e83 ("gdb: remove VALUE_REGNUM, add value::regnum")
introduced an unexpected change in value_assign. It replaced
`get_prev_frame_always (next_frame)` with `next_frame`in the call to
gdbarch_value_to_register.
This is the result of a merge error, since I previously had a patch to
change gdbarch_value_to_register to take the next frame, and later
decided to drop it. Revert that change.
Add a test based on the DWARF assembler to expose the problem and test
the fix. I also tested on ppc64le to make sure the problem reported in
PR 31231 was fixed.
Change-Id: Ib8b851287ac27a4b2e386f7b680cf65865e6aee6
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31231
|
|
On ppc64le-linux, I run into:
...
(gdb) bt^M
#0 0x00000000100006dc in foobar (J=2)^M
#1 0x000000001000070c in prog ()^M
(gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo
...
The test-case attemps to emulate additional entry points of a function, with
function bar having entry points foo and foobar:
...
(gdb) p bar
$1 = {void (int, int)} 0x1000064c <bar>
(gdb) p foo
$2 = {void (int, int)} 0x10000698 <foo>
(gdb) p foobar
$3 = {void (int)} 0x100006d0 <foobar>
...
However, when setting a breakpoint on the entry point foo:
...
(gdb) b foo
Breakpoint 1 at 0x100006dc
...
it ends up in foobar instead of in foo, due to prologue skipping, and
consequently the backtrace show foobar instead foo.
The problem is that the test-case does not emulate an actual prologue at each
entry point.
Fix this by disabling the prologue skipping when setting a breakpoint, using
"break *foo".
Tested on ppc64le-linux and x86_64-linux.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
PR testsuite/31232
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232
|
|
I ran into the following FAIL:
...
(gdb) python kill_and_detach()^M
Traceback (most recent call last):^M
File "<string>", line 1, in <module>^M
File "<string>", line 7, in kill_and_detach^M
gdb.error: Selected thread is running.^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \
python kill_and_detach()
...
The FAIL happens as follows:
- gdb is debugging a process A
- a checkpoint is created, in other words, fork is called in the inferior,
after which we have:
- checkpoint 0 (the fork parent, process A), and
- checkpoint 1 (the fork child, process B).
- during checkpoint creation, lseek is called in the inferior (process A) for
all file descriptors, and it returns != -1 for at least one file descriptor.
- the process A continues in the background
- gdb detaches, from process A
- gdb switches to process B, in other words, it restarts checkpoint 1
- while restarting checkpoint 1, gdb tries to call lseek in the inferior
(process B), but this fails because gdb incorrectly thinks that inferior B
is running.
This happens because linux_nat_switch_fork patches the pid of process B into
the current inferior and current thread which where originally representing
process A. So, because process A was running in the background, the
thread_info fields executing and resumed are set accordingly, but they are not
correct for process B.
There's a line in fork_load_infrun_state that fixes up the thread_info field
stop_pc, so fix this by adding similar fixups for the executing and resumed
fields alongside.
The FAIL did not always reproduce, so extend the test-case to reliably
trigger this scenario.
Tested on x86_64-linux.
Approved-By: Kevin Buettner <kevinb@redhat.com>
PR gdb/31203
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203
|
|
When doing "checkpoint delete 0" we run into an assertion failure:
...
+delete checkpoint 0
inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
...
Fix this by handling the "pptid == null_ptid" case in
delete_checkpoint_command.
Tested on x86_64-linux.
Approved-By: Kevin Buettner <kevinb@redhat.com>
PR gdb/31209
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209
|
|
Consider test-case gdb.base/checkpoint.exp. At some point, it issues an info
checkpoints command:
...
(gdb) info checkpoints^M
* 0 process 30570 (main process) at 0x0^M
1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M
2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M
3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M
4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M
5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M
6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M
7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M
8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M
9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M
10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M
...
According to the docs, each of these (0-10) is a checkpoint.
But the pc address (as well as the file name and line number) is missing for
checkpoint 0.
Fix this by sampling the pc value for the current process in
info_checkpoints_command, such that we have instead:
...
* 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M
...
Tested on x86_64-linux.
Approved-By: Kevin Buettner <kevinb@redhat.com>
PR gdb/31211
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211
|
|
This patch rearranges the DWARF reader so that more work is done in
the background. This is PR symtab/29942.
The idea here is that there is only a small amount of work that must
be done on the main thread when scanning DWARF -- before the main
scan, the only part is mapping the section data.
Currently, the DWARF reader uses the quick_symbol_functions "lazy"
functionality to defer even starting to read. This patch instead
changes the reader to start reading immediately, but doing more in
worker tasks.
Before this patch, "file" on my machine:
(gdb) file /tmp/gdb
2023-10-23 12:29:56.885 - command started
Reading symbols from /tmp/gdb...
2023-10-23 12:29:58.047 - command finished
Command execution time: 5.867228 (cpu), 1.162444 (wall)
After the patch, more work is done in the background and so this takes
a bit less time:
(gdb) file /tmp/gdb
2023-10-23 13:25:51.391 - command started
Reading symbols from /tmp/gdb...
2023-10-23 13:25:51.712 - command finished
Command execution time: 1.894500 (cpu), 0.320306 (wall)
I think this could be further sped up by using the shared library load
map to avoid objfile loops like the one in expand_symtab_containing_pc
-- it seems like the correct objfile could be chosen more directly.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174
|
|
gdb.base/vfork-follow-parent.exp
When running test-case gdb.base/vfork-follow-parent.exp it passes fine, but
when running it with "taskset -c 0" I run into:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 26606] (vfork-follow-parent-exit)]^M
[Switching to thread 1.1 (process 26606)]^M
(gdb) Reading symbols from vfork-follow-parent-exit...^M
FAIL: $exp: exec_file=vfork-follow-parent-exit: target-non-stop=on: \
non-stop=off: resolution_method=schedule-multiple: inferior 1 (timeout)
...
Fix this by using -no-prompt-anchor.
Tested on x86_64-linux.
PR testsuite/31166
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31166
|
|
On aarch64-linux, with gcc 13.2.1, I run into:
...
(gdb) backtrace^M
#0 break_here () at solib-search.c:30^M
#1 0x0000fffff7f20194 in lib2_func4 () at solib-search-lib2.c:50^M
#2 0x0000fffff7f70194 in lib1_func3 () at solib-search-lib1.c:50^M
#3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
#5 0x00000000004101b4 in main () at solib-search.c:23^M
(gdb) PASS: gdb.base/solib-search.exp: \
backtrace (with wrong libs) (data collection)
FAIL: gdb.base/solib-search.exp: backtrace (with wrong libs)
...
The FAIL is generated by this code in the test-case:
...
if { $expect_fail } {
# If the backtrace output is correct the test isn't sufficiently
# testing what it should.
if { $count == $total_expected } {
set fail 1
}
...
The test-case:
- builds two versions of two shared libs, a "right" and "wrong" version, the
difference being an additional dummy function (called spacer function),
- uses the "right" version to generate a core file,
- uses the "wrong" version to interpret the core file, and
- generates a backtrace.
The intent is that the backtrace is incorrect due to using the "wrong"
version, but actually it's correct. This is because the spacer functions
aren't large enough.
Fix this by increasing the size of the spacer functions by adding a dummy
loop, after which we have, as expected, an incorrect backtrace:
...
(gdb) backtrace^M
#0 break_here () at solib-search.c:30^M
#1 0x0000fffff7f201c0 in ?? ()^M
#2 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#3 0x0000fffff7f20174 in lib2_func2 () at solib-search-lib2.c:30^M
#4 0x0000fffff7f70174 in lib1_func1 () at solib-search-lib1.c:30^M
#5 0x00000000004101b4 in main () at solib-search.c:23^M
(gdb) PASS: gdb.base/solib-search.exp: \
backtrace (with wrong libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with wrong libs)
...
Tested on aarch64-linux.
|
|
On aarch64-linux, I run into:
...
FAIL: gdb.base/annota1.exp: backtrace from shlibrary (timeout)
...
due to the PAC marker showing up:
...
^Z^Zframe-address^M
0x000000000041025c [PAC]^M
^Z^Zframe-address-end^M
...
In the docs the marker is documented as follows:
...
When GDB is debugging the AArch64 architecture, and the program is using the
v8.3-A feature Pointer Authentication (PAC), then whenever the link register
$lr is pointing to an PAC function its value will be masked. When GDB prints
a backtrace, any addresses that required unmasking will be postfixed with the
marker [PAC]. When using the MI, this is printed as part of the addr_flags
field.
...
Update the test-case to allow the PAC marker.
Likewise in a few other test-cases.
While we're at it, rewrite the affected pattern pat_begin in annota1.exp into
a more readable form. Likewise for the corresponding pat_end.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/31202
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31202
|
|
This commits changes how errors are reported from the expression
parser. Previously, parser errors were reported like this:
(gdb) p a1 +}= 432
A syntax error in expression, near `}= 432'.
(gdb) p a1 +
A syntax error in expression, near `'.
The first case is fine, a user can figure out what's going wrong, but
the second case is a little confusing; as the error occurred at the
end of the expression GDB just reports the empty string to the user.
After this commit the first case is unchanged, but the second case now
reports like this:
(gdb) p a1 +
A syntax error in expression, near the end of `a1 +'.
Which I think is clearer. There is a possible issue if the expression
being parsed is very long, GDB will repeat the whole expression. But
this issue already exists in the standard case; if the error occurs
early in a long expression GDB will repeat everything after the syntax
error. So I've not worried about this case in my new code either,
which keeps things simpler.
I did consider trying to have multi-line errors here, in the style
that gcc produces, with some kind of '~~~~~^' marker on the second
line to indicate where the error occurred; but I rejected this due to
the places in GDB where we catch an error and repackage the message
within some longer string, I don't think multi-line error messages
would work well in that case. At a minimum it would require some
significant work in order to make all our error handling multi-line
aware.
I've added a couple of extra tests in gdb.base/exprs.exp.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Currently GDB when executing in reverse over multiple statements in a single
line of source code, GDB stops in the middle of the line. Thus requiring
multiple commands to reach the previous line. GDB should stop at the first
instruction of the line, not in the middle of the line.
The following description of the incorrect behavior was taken from an
earlier message by Pedro Alves <pedro@palves.net>:
https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html
---------------------------------
The source line looks like:
func1 (); func2 ();
in the test case:
(gdb) list 1
1 void func1 ()
2 {
3 }
4
5 void func2 ()
6 {
7 }
8
9 int main ()
10 {
11 func1 (); func2 ();
12 }
compiled with:
$ gcc reverse.c -o reverse -g3 -O0
$ gcc -v
...
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
Now let's debug it with target record, using current gdb git master
(f3d8ae90b236),
$ gdb ~/reverse
GNU gdb (GDB) 14.0.50.20230124-git
...
Reading symbols from /home/pedro/reverse...
(gdb) start
Temporary breakpoint 1 at 0x1147: file reverse.c, line 11.
Starting program: /home/pedro/reverse
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main () at reverse.c:11
11 func1 (); func2 ();
(gdb) record
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
=> 0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
(gdb) n
12 }
So far so good, a "next" stepped over the whole of line 11 and stopped at
line 12.
Let's confirm where we are now:
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
=> 0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
Good, we're at the first instruction of line 12.
Now let's undo the "next", with "reverse-next":
(gdb) reverse-next
11 func1 (); func2 ();
Seemingly stopped at line 11. Let's see exactly where:
(gdb) disassemble /s
Dump of assembler code for function main:
reverse.c:
10 {
0x000055555555513f <+0>: endbr64
0x0000555555555143 <+4>: push %rbp
0x0000555555555144 <+5>: mov %rsp,%rbp
11 func1 (); func2 ();
0x0000555555555147 <+8>: mov $0x0,%eax
0x000055555555514c <+13>: call 0x555555555129 <func1>
=> 0x0000555555555151 <+18>: mov $0x0,%eax
0x0000555555555156 <+23>: call 0x555555555134 <func2>
0x000055555555515b <+28>: mov $0x0,%eax
12 }
0x0000555555555160 <+33>: pop %rbp
0x0000555555555161 <+34>: ret
End of assembler dump.
(gdb)
And lo, we stopped in the middle of line 11! That is a bug, we should have
stepped back all the way to the beginning of the line. The "reverse-next"
should have fully undone the prior "next" command.
--------------------
This patch fixes the incorrect GDB behavior by ensuring that GDB stops at
the first instruction in the line.
The test case gdb.reverse/func-map-to-same-line.exp is added to testsuite
to verify this fix when the line table information is and is not available.
|
|
When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on
the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp.
The failure happens around the following code:
38 b[1] = shr2(17); /* middle part two */
40 b[0] = 6; b[1] = 9; /* generic statement, end part two */
42 shr1 ("message 1\n"); /* shr1 one */
Normal execution:
- step from line 38 will land on line 40.
- step from line 40 will land on line 42.
Reverse execution:
- step from line 42 will land on line 40.
- step from line 40 will land on line 40.
- step from line 40 will land on line 38.
The problem here is that line 40 contains two contiguous but distinct
PC ranges in the line table, like so:
Line 40 - [0x7ec ~ 0x7f4]
Line 40 - [0x7f4 ~ 0x7fc]
The two distinct ranges are generated because GCC started outputting source
column information, which GDB doesn't take into account at the moment.
When stepping forward from line 40, we skip both of these ranges and land on
line 42. When stepping backward from line 42, we stop at the start PC of the
second (or first, going backwards) range of line 40.
Since we've reached ecs->event_thread->control.step_range_start, we stop
stepping backwards.
The above issues were fixed by introducing a new function that looks for
adjacent PC ranges for the same line, until we notice a line change. Then
we take that as the start PC of the range. The new start PC for the range
is used for the control.step_range_start when setting up a step range.
The test case gdb.reverse/map-to-same-line.exp is added to test the fix
for the above reverse step issues.
Patch has been tested on PowerPC, X86 and AArch64 with no regressions.
|
|
This patch adds two new options to gdb_compile to specify if the compile
should or should not generate the line table information. The
options are supported on clang and gcc version 7 and newer.
Patch has been tested on PowerPC with both gcc and clang.
|
|
This commit adds a mechanism for GDB to detect the linetable opcode
DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
that a certain instruction marks the point where the frame is destroyed.
While the standard allows for multiple points marked with epilogue_begin
in the same function, for performance reasons, the function that
searches for the epilogue address will only find the last address that
sets this flag for a given block.
This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
use the epilogue begin directly, and only if an epilogue can't be found
will it attempt heuristics based on the current instruction.
Finally, this commit also changes the dwarf assembler to be able to emit
epilogue-begin instructions, to make it easier to test this patch
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Mark pointed out that a recent patch of mine caused the buildbot to
complain about the formatting of some Python test code. This patch
re-runs 'black' to fix the problem.
|
|
On aarch64-linux with a gdb build without libexpat, I run into:
...
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
catch syscall 59
continue
Continuing.
Catchpoint 5 (call to syscall 59), 0x0000fffff7e04578 in pipe () from \
/lib64/libc.so.6
(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
...
In the test-case, this pattern handles either the syscall name or number for
the pipe syscall:
...
-re -wrap "Catchpoint $decimal \\(call to syscall (pipe|$SYS_pipe)\\).*" {
...
but the pattern for the pipe2 syscall mistakenly uses SYS_pipe instead of
SYS_pipe2:
...
-re -wrap "Catchpoint $decimal \\(call to syscall (pipe2|$SYS_pipe)\\).*" {
...
and consequently doesn't handle the pipe2 syscall number.
Fix the typo by using SYS_pipe2 instead.
Tested on aarch64-linux.
|
|
The gdb docs promise that methods with more than two or more arguments
will accept keywords. However, I found that TuiWindow.write didn't
allow them. This patch adds the missing support.
|
|
When running test-case gdb.base/gdb-index-err.exp in a container as root user,
I run into:
...
FAIL: gdb.base/gdb-index-err.exp: flag=: \
try to write index to a non-writable directory
FAIL: gdb.base/gdb-index-err.exp: flag=-dwarf-5: \
try to write index to a non-writable directory
...
The test-case creates a directory without write permissions:
...
$ ls -ald private
dr-xr-xr-x 2 root root 4096 Dec 29 06:26 private/
...
but apparently the root user is still able to write in it.
Fix this by making the test unsupported for the root user.
Tested on x86_64-linux.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
PR testsuite/31197
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31197
|
|
Fortran provides additional entry points for subroutines and functions.
These entry points may use only a subset (or a different set) of the
parameters of the original subroutine. The entry points may be described
via the DWARF tag DW_TAG_entry_point.
This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
Currently, between ifx/ifort/gfortran, only ifort is actually emitting
this tag. Both, ifx and gfortran use the DW_TAG_subprogram tag as
workaround/alternative. Thus, this patch really only adds more ifort
support. Even so, some of the attached tests still fail for ifort, due
to some wrong line info generated for the entry points in ifort.
After this patch it is possible to set a breakpoint in gdb with the
ifort compiled example at the entry points 'foo' and 'foobar', which was not
possible before.
As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
which uses some underlying c compiled code and adds some Fortran style DWARF
to it emitting the DW_TAG_entry_point. Before this patch it was not
possible to actually define breakpoint at the entry point tags.
For gfortran there actually exists a bug on bugzilla, asking for the use
of DW_TAG_entry_point over DW_TAG_subprogram:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134
This patch was originally posted here
https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html
but its review/pinging got lost after a while. I reworked it to fit the
current GDB.
Co-authored-by: Bernhard Heckel <bernhard.heckel@intel.com>
Co-authored-by: Tim Wiederhake <tim.wiederhake@intel.com>
Approved-by: Tom Tromey <tom@tromey.com>
|
|
This changes the test suite to look for rogue DAP exceptions in the
log file, and issue a "fail" if one is found.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
In many cases, it's not possible for gdb to discover the executable
when a DAP 'attach' request is used. This patch lets the IDE supply
this information.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This commit makes the following improvements to
gdb.threads/step-over-thread-exit.exp:
- Add a third axis to stepping over the breakpoint with displaced vs
inline stepping -- also test with no breakpoint at all.
- Check that when GDB reports "Command aborted, thread exited.", the
selected thread is the thread that exited. This is always true
currently on GNU/Linux by coincidence, but a similar testcase on AMD
GPU exposed a problem here. Better make the testcase catch any
potential regression.
- Fixes a race that Simon ran into with GDBserver testing.
(gdb) next
[New Thread 2143071.2143438]
Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74
74 SYSCALL (my_exit, __NR_exit)
(gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits
I was not able to reproduce it, but I believe that what happens is
the following:
Once we continue, the thread 2 exits, and the main thread thus
unblocks from its pthread_join, and spawns a new thread. That new
thread may hit the breakpoint at my_exit_syscall very quickly. GDB
could then see/process that breakpoint event before the thread exit
event for the thread we care about, which would result in the
failure seen above.
The fix here is to not loop and start a new thread at all in the
scenario where the race can happen. We only need to loop and spawn
new threads when testing with "cmd=continue" and schedlock off, in
which case GDB doesn't abort the command when the thread exits.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I90c95c32f00630a3f682b1541c23aff52451f9b6
|
|
gdbarches usually register functions to check when a frame is destroyed
which is used with software watchpoints, since the expression of the
watchpoint is no longer vlaid at this point. On amd64, this wasn't done
anymore because GCC started using CFA for variable locations instead.
However, clang doesn't use the CFA and instead relies on specifying when
an epilogue has started, meaning software watchpoints get a spurious hit
when a frame is destroyed. This patch re-adds the code to register the
function that detects when a frame is destroyed, but only uses this when
the producer is LLVM, so gcc code isn't affected. The logic that
identifies the epilogue has been factored out into the new function
amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it
directly, and its behavior isn't changed.
This can also remove the XFAIL added to gdb.python/pq-watchpoint tests
that handled this exact flaw in clang.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The gdb.threads/thread-specific-bp.exp test has been a little
problematic, see commits:
commit 89702edd933a5595557bcd9cc4a0dcc3262226d4
Date: Thu Mar 9 12:31:26 2023 +0100
[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver
and
commit 2e5843d87c4050bf1109921481fb29e1c470827f
Date: Fri Nov 19 14:33:39 2021 +0100
[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp
But I recently saw a test failure for that test, which looked like
this:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected
continue -a
Continuing.
Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
29 }
(gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
...
This only crops up (for me) when running on a loaded machine, and
still only occurs sometimes. I've had to leave the test running in a
loop for 10+ minutes sometimes in order to see the failure.
The problem is that we use gdb_test_multiple to try and match two
patterns:
(1) The 'Thread-specific breakpoint 3 deleted ....' message, and
(2) The GDB prompt.
As written in the test, we understand that these patterns can occur in
any order, and we have a flag for each pattern. Once both patterns
have been seen then we PASS the test.
The problem is that once expect has matched a pattern, everything up
to, and including the matched text is discarded from the input
buffer. Thus, if the input buffer contains:
<PATTERN 2><PATTERN 1>
Then expect will first try to match <PATTERN 1>, which succeeds, and
then expect discards the entire input buffer up to the end of the
<PATTERN 1>. As a result, we will never spot <PATTERN 2>.
Obviously we can't just reorder the patterns within the
gdb_test_multiple, as the output can legitimately (and most often
does) occur in the other order, in which case the test would mostly
fail, and only occasionally pass!
I think the easiest solution here is just to have the
gdb_test_multiple contain two patterns, each pattern consists of the
two parts, but in the alternative orders, thus, for a particular
output configuration, only one regexp will match. With this change in
place, I no longer see the intermittent failure.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR28987 notes that optimized code sometimes shows the wrong
value of variables at the entry point of a function, if some
code was optimized away and the variable has multiple values
stored in the debug info for this location.
In this example:
```
void foo()
{
int l_3 = 5, i = 0;
for (; i < 8; i++)
;
test(l_3, i);
}
```
When compiled with optimization, the entry point of foo is at
the test() function call, since everything else is optimized
away.
The debug info of i looks like this:
```
(gdb) info address i
Symbol "i" is multi-location:
Base address 0x140001600 Range 0x13fd41600-0x13fd41600: the constant 0
Range 0x13fd41600-0x13fd41600: the constant 1
Range 0x13fd41600-0x13fd41600: the constant 2
Range 0x13fd41600-0x13fd41600: the constant 3
Range 0x13fd41600-0x13fd41600: the constant 4
Range 0x13fd41600-0x13fd41600: the constant 5
Range 0x13fd41600-0x13fd41600: the constant 6
Range 0x13fd41600-0x13fd41600: the constant 7
Range 0x13fd41600-0x13fd4160f: the constant 8
(gdb) p i
$1 = 0
```
Currently, when at the entry point of a function, it will
always show the initial value (here 0), while the user would
expect the last value (here 8).
This logic was introduced for showing the entry-values of
function arguments if they are available, but for some
reason this was added for non-entry-values as well.
One of the tests of amd64-entry-value.exp shows the same
problem for function arguments, if you "break stacktest"
in the following example, you stop at this line:
```
124 static void __attribute__((noinline, noclone))
125 stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2,
126 double d1, double d2, double d3, double d4, double d5, double d6,
127 double d7, double d8, double d9, double da)
128 {
129 s1 = 3;
130 s2 = 4;
131 d9 = 3.5;
132 da = 4.5;
133 -> e (v, v);
134 asm ("breakhere_stacktest:");
135 e (v, v);
136 }
```
But `bt` still shows the entry values:
```
s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5
```
I've fixed this by only using the initial values when
explicitely looking for entry values.
Now the local variable of the first example is as expected:
```
(gdb) p i
$1 = 8
```
And the test of amd64-entry-value.exp shows the expected
current and entry values of the function arguments:
```
s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5, da@entry=12.5
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When starting gdb in CLI mode, running to main and switching into the TUI regs
layout:
...
$ gdb -q a.out -ex start -ex "layout regs"
...
we get:
...
+---------------------------------+
| |
| [ Register Values Unavailable ] |
| |
+---------------------------------+
...
Fix this by handling this case in tui_data_window::rerender.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/28600
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600
|
|
Currently, the overload handling in Ada assumes that any two array
types are compatible. However, this is obviously untrue, and a user
reported an oddity where comparing two Ada strings resulted in a call
to the "=" function for packed boolean arrays.
This patch improves the situation somewhat, by requiring that the two
arrays have the same arity and compatible base element types. This is
still over-broad, but it seems safe and is better than the status quo.
|
|
This patch adds tests to exercise the previous patches' changes.
All three tests:
- aarch64-pseudo-unwind
- amd64-pseudo-unwind
- arm-pseudo-unwind
follow the same pattern, just with different registers.
The other test, arm-pseudo-unwind-legacy, tests the special case where
the unwind information contains an entry for a register considered a
pseudo-register by GDB.
Change-Id: Ic29ac040c5eb087b4a0d79f9d02f65b7979df30f
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-by: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
Tested-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
|
|
Currently, it's not possible to call a variadic C++ function:
```
(gdb) print sum_vararg_int(1, 10)
Cannot resolve function sum_vararg_int to any overloaded instance
(gdb) print sum_vararg_int(2, 20, 30)
Cannot resolve function sum_vararg_int to any overloaded instance
```
It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS
rank by rank_function, which disqualifies the function.
To fix this, I've created the new VARARG_BADNESS rank, which is
used only for additional arguments of variadic functions, allowing
them to be called:
```
(gdb) print sum_vararg_int(1, 10)
$1 = 10
(gdb) print sum_vararg_int(2, 20, 30)
$2 = 50
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While making recent changes to 'save gdb-index' command I triggered
some errors -- of the kind a user might be expected to trigger if they
do something wrong -- and I didn't find GDB's output as helpful as it
might be.
For example:
$ gdb -q /tmp/hello.x
...
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': mkstemp: No such file or directory.
That the error message mentions '/tmp/hello', which does exist, but
doesn't mention '/non_existing_dir', which doesn't is, I think,
confusing.
Also, I find the 'mkstemp' in the error message confusing for a user
facing error. A user might not know what mkstemp means, and even if
they do, that it appears in the error message is an internal GDB
detail. The user doesn't care what function failed, but wants to know
what was wrong with their input, and what they should do to fix
things.
Similarly, for a directory that does exist, but can't be written to:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': mkstemp: Permission denied.
In this case, the 'Permission denied' might make the user thing there
is a permissions issue with '/tmp/hello', which is not the case.
After this patch, the new errors are:
(gdb) save gdb-index /non_existing_dir
Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory.
and:
(gdb) save gdb-index /no_access_dir
Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied.
we also have:
(gdb) save gdb-index /tmp/not_a_directory
Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory.
I think these do a better job of guiding the user towards fixing the
problem.
I've added a new test that exercises all of these cases, and also
checks the case where a user tries to use an executable that already
contains an index in order to generate an index. As part of the new
test I've factored out some code from ensure_gdb_index (lib/gdb.exp)
into a new proc (get_index_type), which I've then used in the new
test. I've confirmed that all the tests that use ensure_gdb_index
still pass.
During review it was pointed out that the testsuite proc
have_index (lib/gdb.exp) is similar to the new get_index_type proc, so
I've rewritten have_index to also use get_index_type, I've confirmed
that all the tests that use have_index still pass.
Nothing that worked correctly before this patch should give an error
after this patch; I've only changed the output when the user was going
to get an error anyway.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently, when creating a gdb.FinishBreakpoint in a function
called from an inline frame, it will never be hit:
```
(gdb) py fb=gdb.FinishBreakpoint()
Temporary breakpoint 1 at 0x13f1917b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
(gdb) c
Continuing.
Thread-specific breakpoint 1 deleted - thread 1 no longer in the thread list.
[Inferior 1 (process 1208) exited normally]
```
The reason is that the frame_id of a breakpoint has to be the
ID of a real frame, ignoring any inline frames.
With this fixed, it's working correctly:
```
(gdb) py fb=gdb.FinishBreakpoint()
Temporary breakpoint 1 at 0x13f5617b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47.
(gdb) c
Continuing.
Breakpoint 1, increase_inlined (a=0x40fa5c) at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c:47
(gdb) py print(fb.return_value)
-8
```
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When using $_thread in info threads to showonly the current thread,
you get this error:
```
(gdb) info thread $_thread
Convenience variable must have integer value.
Args must be numbers or '$' variables.
```
It's because $_thread is a dynamically computed convenience
variable, which isn't supported yet by get_internalvar_integer.
Now the output looks like this:
```
(gdb) info threads $_thread
Id Target Id Frame
* 1 Thread 10640.0x2680 main () at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/gdbvars.c:21
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17600
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This implements DAP cancellation. A new object is introduced that
handles the details of cancellation. While cancellation is inherently
racy, this code attempts to make it so that gdb doesn't inadvertently
cancel the wrong request.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472
Approved-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This renames a couple of DAP procs in the testsuite, to clarify that
they are now exported. The cancellation test will need these.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced:
...
set eol "\[\r\n\]+"
...
with the more strict:
...
set eol "\r\n"
...
in a few test-cases, but didn't update all uses of eol accordingly.
Fix this in three gdb.ada test-cases.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
PR29011 notes that dynamic_cast does not work correctly if
classes with virtual methods are involved, some of the results
wrongly point into the vtable of the derived class:
```
(gdb) p vlr
$1 = (VirtualLeftRight *) 0x162240
(gdb) p vl
$2 = (VirtualLeft *) 0x162240
(gdb) p vr
$3 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
$4 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
$5 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
$6 = (VirtualLeftRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeft*>(vlr)
$7 = (VirtualLeft *) 0x162240
(gdb) p dynamic_cast<VirtualLeft*>(vl)
$8 = (VirtualLeft *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
(gdb) p dynamic_cast<VirtualLeft*>(vr)
$9 = (VirtualLeft *) 0x162240
(gdb) p dynamic_cast<VirtualRight*>(vlr)
$10 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualRight*>(vl)
$11 = (VirtualRight *) 0x162250
(gdb) p dynamic_cast<VirtualRight*>(vr)
$12 = (VirtualRight *) 0x13fab89b0 <vtable for VirtualLeftRight+16>
```
For the cases where the dynamic_cast type is the same as the
original type, it used the ARG value for the result, which in
case of pointer types was already the dereferenced value.
And the TEM value at the value address was created with the
pointer/reference type, not the actual class type.
With these fixed, the dynamic_cast results make more sense:
```
(gdb) p vlr
$1 = (VirtualLeftRight *) 0x692240
(gdb) p vl
$2 = (VirtualLeft *) 0x692240
(gdb) p vr
$3 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualLeftRight*>(vlr)
$4 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeftRight*>(vl)
$5 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeftRight*>(vr)
$6 = (VirtualLeftRight *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vlr)
$7 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vl)
$8 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualLeft*>(vr)
$9 = (VirtualLeft *) 0x692240
(gdb) p dynamic_cast<VirtualRight*>(vlr)
$10 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualRight*>(vl)
$11 = (VirtualRight *) 0x692250
(gdb) p dynamic_cast<VirtualRight*>(vr)
$12 = (VirtualRight *) 0x692250
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29011
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The focused window is highlighted by using active-border-kind instead of
border-kind.
But if the focused window is the cmd window (which is an unboxed window), then
no highlighting is done, and it's not obvious from looking at the screen which
window has the focus. Instead, you have to notice the absence of highlighting
on boxed windows, and then infer that the focus is on the unboxed window.
That approach stops working if there are multiple unboxed windows.
Likewise if highlighting is switched off by setting active-border-kind to the
same value as border-kind.
Make it more explicit which window has the focus by mentioning it in the status
window, like so:
...
native process 8282 (src) In: main L7 PC: 0x400525
...
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
to print a global variable stub without a running inferior, because of
a missing nullptr-check (the block_scope function took care of that
check before it was converted to a method).
With this check it works again:
```
(gdb) print s
$1 = <incomplete type>
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Following on from the previous commit, I searched the testsuite for
places where we did:
set eol "<some pattern>"
in most cases the <some pattern> could be replaced with "\r\n" though
in the stabs test I've switched to using the multi_line proc as that
seemed like a better choice.
In gdb.ada/info_types.exp I did need to add an extra use of $eol as
the previous pattern would match multiple newlines, and in this one
place we were actually expecting to match multiple newlines. The
tighter pattern only matches a single newline, so we now need to be
explicit when multiple newlines are expected -- I think this is a good
thing.
All the tests are still passing for me after these changes.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While reviewing another patch I spotted a timeout in
gdb.ada/complete.exp when testing in READ1 mode, e.g.:
$ make check-read1 TESTS="gdb.ada/complete.exp"
...
FAIL: gdb.ada/complete.exp: complete break ada (timeout)
...
The problem is an attempt to match the entire output from GDB within a
single gdb_test_multiple pattern, for a completion command that
returns a large number of completions.
This commit changes the gdb_test_multiple to process the output line
by line. I don't use the gdb_test_multiple -lbl option, as I've
always found that option backward -- it checks for the \r\n at the
start of each line rather than the end, I think it's much clearer to
use '^' at the start of each pattern, and '\r\n' at the end, so that's
what I've done here.
.... Or I would, if this test didn't already define $eol as the end of
line regexp ... except that $eol was set to '[\r\n]*', which isn't
that helpful, so I've updated $eol to be just '\r\n' the actual end of
line regexp.
And now, the test passes without a timeout when using READ1.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Building on the last commit, which added a general --debug=COMPONENT
option to the gdbserver command line, this commit updates the monitor
command to allow for general:
(gdb) monitor set debug COMPONENT off|on
style commands. Just like with the previous commit, the COMPONENT can
be any one of all, threads, remote, event-loop, and correspond to the
same set of global debug flags.
While on the command line it is possible to do:
--debug=remote,event-loop,threads
the components have to be entered one at a time with the monitor
command. I guess there's no reason why we couldn't allow component
grouping within the monitor command, but (to me) what I have here
seemed more in the spirit of GDB's existing 'set debug ...' commands.
If people want it then we can always add component grouping later.
Notice in the above that I use 'off' and 'on' instead of '0' and '1',
which is what the 'monitor set debug' command used to use. The 0/1
can still be used, but I now advertise off/on in all the docs and help
text, again, this feels more inline with GDB's existing boolean
settings.
I have removed the two existing monitor commands:
monitor set remote-debug 0|1
monitor set event-loop-debug 0|1
These are replaced by:
monitor set debug remote off|on
monitor set debug event-loop off|on
respectively.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
