| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
New 'no-delete-breakpoints' option for the 'runto' proc. This option
disables the delete_breakpoints call early on in this proc.
There are a couple of places in the testsuite where I have used:
proc no_delete_breakpoints {} {}
with_override delete_breakpoints no_delete_breakpoints {
if {![runto_main]} {
return
}
}
In order to avoid the deleting all breakpoints when I call
runto_main. I was about to add yet another instance of this pattern
and I figured that it's time to do this properly.
This commit adds the new option to 'runto' which causes the
delete_breakpoints call to be skipped.
And, we now forward any arguments from 'runto_main' through to
'runto', this means I can now just do:
if {![runto_main no-delete-breakpoints]} {
return
}
which I think is cleaner and easier to understand.
I've updated the two tests I found that use the old with_override
approach.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix all trailing-text-in-parentheses duplicates exposed by previous patch.
Tested on x86_64-linux and aarch64-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>
|
|
Currently it's not possible to call user-defined function call
operators, at least not without specifying operator() directly:
```
(gdb) l 1
1 struct S {
2 int operator() (int x) { return x + 5; }
3 };
4
5 int main () {
6 S s;
7
8 return s(23);
9 }
(gdb) p s(10)
Invalid data type for function to be called.
(gdb) p s.operator()(10)
$1 = 15
```
This now looks if an user-defined call operator is available when
trying to 'call' a struct value, and calls it instead, making this
possible:
```
(gdb) p s(10)
$1 = 15
```
The change in operation::evaluate_funcall is to make sure the type
fields are only used for function types, only they use them as the
argument types.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213
Approved-By: Tom Tromey <tom@tromey.com>
|
|
C++14 allows the use of the apostrophe as a numeric separator; that
is, "23000" and "23'000" represent the same number. This patch
implements this for gdb's C++ parser and the C++ name canonicalizer.
I did this unconditionally for all C variants because I think it's
unambiguous.
For the name canonicalizer, there's at least one compiler that can
emit constants with this form, see bug 30845.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge"
parameter from destructors of classes with no virtual bases; Linaro's CI
informed me that the gdb testsuite needs to be adjusted to match.
Teested against GCC 13.2 and GCC 15 trunk.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
There's a pattern of using:
...
set saved_gdbflags $GDBFLAGS
set GDBFLAGS "$GDBFLAGS ..."
<do something with GDBFLAGS>
set GDBFLAGS $saved_gdbflags
...
Simplify this by using save_vars:
...
save_vars { GDBFLAGS } {
set GDBFLAGS "$GDBFLAGS ..."
<do something with GDBFLAGS>
}
...
Tested on x86_64-linux.
|
|
We now have unwind-on-timeout and unwind-on-terminating-exception, and
then the odd one out unwindonsignal.
I'm not a great fan of these squashed together command names, so in
this commit I propose renaming this to unwind-on-signal.
Obviously I've added the hidden alias unwindonsignal so any existing
GDB scripts will keep working.
There's one test that I've extended to test the alias works, but in
most of the other test scripts I've changed over to use the new name.
The docs are updated to reference the new name.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>
|
|
It's currently not possible to cast an in-memory value of a primitive
type to const reference:
```
(gdb) p Q.id
$1 = 42
(gdb) p (int&)Q.id
$2 = (int &) @0x22fd0c: 42
(gdb) p (const int&)Q.id
Attempt to take address of value not located in memory.
```
And if in a function call an argument needs the same kind of casting,
it also doesn't work:
```
(gdb) l f3
39 int f3(const int &i)
40 {
41 return i;
42 }
(gdb) p f3(Q.id)
Attempt to take address of value not located in memory.
```
It's because when the constness of the type changes in a call to
value_cast, a new not_lval value is allocated, which doesn't exist
in the target memory.
Fixed by ignoring const/volatile/restrict qualifications in
value_cast when comparing cast type to original type, so the new
value will point to the same location as the original value:
```
(gdb) p (int&)i
$2 = (int &) @0x39f72c: 1
(gdb) p (const int&)i
$3 = (const int &) @0x39f72c: 1
(gdb) p f3(Q.id)
$4 = 42
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently a reinterpret_cast may change the pointer value if
multiple inheritance is involved:
```
(gdb) p r
$1 = (Right *) 0x22f75c
(gdb) p reinterpret_cast<LeftRight*>(r)
$2 = (LeftRight *) 0x22f758
```
It's because value_cast is called in this case, which automatically
does up- and downcasting.
Fixed by simply using the target pointer type in a copy of the
original value:
```
(gdb) p r
$1 = (Right *) 0x3bf87c
(gdb) p reinterpret_cast<LeftRight*>(r)
$2 = (LeftRight *) 0x3bf87c
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently it's not possible to call functions if an argument is a
pointer to an array:
```
(gdb) l f
1 int f (int (*x)[2])
2 {
3 return x[0][1];
4 }
5
6 int main()
7 {
8 int a[2][2] = {{0, 1}, {2, 3}};
9 return f (a);
10 }
(gdb) p f(a)
Cannot resolve function f to any overloaded instance
```
This happens because types_equal doesn't handle array types, so the
function is never even considered as a possibility.
With array type handling added, by comparing element types and array
bounds, the same works:
```
(gdb) p f(a)
$1 = 1
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15398
Co-Authored-By: Keith Seitz <keiths@redhat.com>
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically")
caused a regression on a test case in the AdaCore internal test suite.
The issue here is that gdb would try to resolve the type of a dynamic
pointer that happened to be NULL. In this case, the "Location address
is not set." error would end up being thrown from the DWARF expression
evaluator.
I think it makes more sense to special-case NULL pointers and not try
to resolve their target type, as that type can't really be accessed
anyway.
This patch implements this idea, and also adds the missing Ada test
case.
|
|
The output of "info breakpoints" includes breakpoint, watchpoint,
tracepoint, and catchpoint if they are created, so it should show
all the four types are deleted in the output of "info breakpoints"
to report empty list after "delete breakpoints".
It should also change the output of "delete breakpoints" to make it
clear that watchpoints, tracepoints, and catchpoints are also being
deleted. This is suggested by Guinevere Larsen, thank you.
$ make check-gdb TESTS="gdb.base/access-mem-running.exp"
$ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running
[...]
(gdb) break main
Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32.
(gdb) watch global_counter
Hardware watchpoint 2: global_counter
(gdb) trace maybe_stop_here
Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27.
(gdb) catch fork
Catchpoint 4 (fork)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32
2 hw watchpoint keep y global_counter
3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27
not installed on target
4 catchpoint keep y fork
Without this patch:
(gdb) delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) info breakpoints 3
No breakpoint or watchpoint matching '3'.
With this patch:
(gdb) delete breakpoints
Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y
(gdb) info breakpoints
No breakpoints, watchpoints, tracepoints, or catchpoints.
(gdb) info breakpoints 3
No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This commit allows pointers to be dynamic types (on the outmost
level). Similar to references, a pointer is considered a dynamic type
if its target type is a dynamic type and it is on the outmost level.
Also this commit removes the redundant code inside function
"value_check_printable" for handling of DW_AT_associated type.
The pointer resolution follows the one of references.
This change generally makes the GDB output more verbose. We are able to
print more details about a pointer's target like the dimension of an array.
In Fortran, if we have a pointer to a dynamic type
type buffer
real, dimension(:), pointer :: ptr
end type buffer
type(buffer), pointer :: buffer_ptr
allocate (buffer_ptr)
allocate (buffer_ptr%ptr (5))
which then gets allocated, we now resolve the dynamic type before
printing the pointer's type:
Before:
(gdb) ptype buffer_ptr
type = PTR TO -> ( Type buffer
real(kind=4) :: alpha(:)
End Type buffer )
After:
(gdb) ptype buffer_ptr
type = PTR TO -> ( Type buffer
real(kind=4) :: alpha(5)
End Type buffer )
Similarly in C++ we can dynamically resolve e.g. pointers to arrays:
int len = 3;
int arr[len];
int (*ptr)[len];
int ptr = &arr;
Once the pointer is assigned one gets:
Before:
(gdb) p ptr
$1 = (int (*)[variable length]) 0x123456
(gdb) ptype ptr
type = int (*)[variable length]
After:
(gdb) p ptr
$1 = (int (*)[3]) 0x123456
(gdb) ptype ptr
type = int (*)[3]
For more examples see the modified/added test cases.
Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
nsalias.exp tries to detect a complaint that is issued when expanding
a CU. However, the test is a bit funny in that, while gdb does
currently expand the CU and issue the complaint, it also emits this
error:
No symbol "N100" in current context.
This series will change gdb such that this CU is not expanded -- which
makes sense, the symbol in question doesn't actually match the lookups
that are done.
So, to make the test more robust, a direct request to expand symtabs
is done instead.
|
|
With check-read1 we run into:
...
(gdb) break DNE>::DNE^M
Function "DNE>::DNE" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) y^M
Breakpoint 9 (DNE>::DNE) pending.^M
n^M
(gdb) FAIL: gdb.cp/namespace.exp: br malformed '>' (got interactive prompt)
n^M
...
The question is supposed to be handled by the question and response arguments
to this gdb_test call:
...
gdb_test "break DNE>::DNE" "" "br malformed \'>\'" \
"Make breakpoint pending on future shared library load?.*" "y"
...
but both this and the builtin handling in gdb_test_multiple triggers.
The cause of this is that the question argument regexp is incomplete.
Fix this by making sure that the entire question is matched in the regexp:
...
set yn_re [string_to_regexp {(y or [n])}]
...
"Make breakpoint pending on future shared library load\\? $yn_re " "Y"
...
Tested on x86_64-linux.
|
|
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.
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS
mentioned:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement
XFAIL: gdb.cp/nsusing.exp: print x, only using M
...
Add the missing PRMS, such that we have:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716)
XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716)
...
and limit the xfail to unfixed versions.
The PR is fixed starting gcc 13, but it has been backported to release
branches stretching back to gcc 10. For simplicity we just stick to testing
for the major version and ignore the backported fixes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running test-case gdb.cp/subtypes.exp with gcc 4.8.4, we run into:
...
FAIL: gdb.cp/subtypes.exp: ptype main::Foo
FAIL: gdb.cp/subtypes.exp: ptype main::Bar
FAIL: gdb.cp/subtypes.exp: ptype main::Baz
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Foo
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Bar
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Baz
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Foo
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Bar
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Baz
...
The problem is gcc PR debug/55541, which generates a superfluous
DW_TAG_lexical_block.
Add a corresponding xfail.
Tested on x86_64-linux.
|
|
Make test-case gdb.cp/subtypes.exp less repetitive by using foreach.
Tested on x86_64-linux.
|
|
When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation
failures due to the test-cases requiring c++11 and the compiler defaulting
to less than that.
Fix this by compiling with -std=c++11.
This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to
gcc PR debug/16063, so xfail those.
Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to
prevent compilation failure.
Tested on x86_64-linux.
|
|
This recent commit:
commit b1c0ab20809a502b2d2224fecb0dca3ada2e9b22
Date: Wed Jul 12 21:56:50 2023 +0100
gdb: avoid double stop after failed breakpoint condition check
Addressed a problem where two MI stopped events would be reported if a
breakpoint condition failed due to a signal, this commit was a
replacement for this commit:
commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b
Date: Fri Oct 14 14:53:15 2022 +0100
gdb: don't always print breakpoint location after failed condition check
which solved the two stop problem, but only for the CLI. Before both
of these commits, if a b/p condition failed due to a signal then the
user would see two stops reported, the first at the location where the
signal occurred, and the second at the location of the breakpoint.
By default GDB remains at the location where the signal occurred, so
the second reported stop can be confusing, this is the problem that
commit 2e411b8c68eb tried to solve (for the CLI) and b1c0ab20809a
extended also address the issue for MI too.
However, while working on another patch I realised that there was a
problem with GDB after the above commits. Neither of the above
commits considered 'set unwindonsignal on'. With this setting on,
when an inferior function call fails with a signal GDB will unwind the
stack back to the location where the inferior function call started.
In the b/p case we're looking at, the stop should be reported at the
location of the breakpoint, not at the location where the signal
occurred, and this isn't what happens.
This commit fixes this by ensuring that when unwindonsignal is 'on',
GDB reports a single stop event at the location of the breakpoint,
this fixes things for both CLI and MI.
The function call_thread_fsm::should_notify_stop is called when the
inferior function call completes and GDB is figuring out if the user
should be notified about this stop event by calling normal_stop from
fetch_inferior_event in infrun.c. If normal_stop is called, then this
notification will be for the location where the inferior call stopped,
which will be the location at which the signal occurred.
Prior to this commit, the only time that normal_stop was not called,
was if the inferior function call completed successfully, this was
controlled by ::should_notify_stop, which only turns false when the
inferior function call has completed successfully.
In this commit I have extended the logic in ::should_notify_stop. Now
there are three cases in which ::should_notify_stop will return false,
and we will not announce the first stop (by calling normal_stop).
These three reasons are:
1. If the inferior function call completes successfully, this is
unchanged behaviour,
2. If the inferior function call stopped due to a signal and 'set
unwindonsignal on' is in effect, and
3. If the inferior function call stopped due to an uncaught C++
exception, and 'set unwind-on-terminating-exception on' is in
effect.
However, if we don't call normal_stop then we need to call
async_enable_stdin in call_thread_fsm::should_stop. Prior to this
commit this was only done for the case where the inferior function
call completed successfully.
In this commit I now call ::should_notify_stop and use this to
determine if we need to call async_enable_stdin. With this done we
now call async_enable_stdin for each of the three cases listed above,
which means that GDB will exit wait_sync_command_done correctly (see
run_inferior_call in infcall.c).
With these two changes the problem is mostly resolved. However, the
solution isn't ideal, we've still lost some information.
Here is how GDB 13.1 behaves, this is before commits b1c0ab20809a and
2e411b8c68eb:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
24 return *p; /* Crash here. */
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
In this state we see two stop notifications, the first is where the
signal occurred, while the second is where the breakpoint is located.
As GDB has unwound the stack (thanks to unwindonsignal) the second
stop notification reflects where the inferior is actually located.
Then after commits b1c0ab20809a and 2e411b8c68eb the behaviour changed
to this:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
24 return *p; /* Crash here. */
Error in testing condition for breakpoint 1:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
(gdb) bt 1
#0 foo () at /tmp/mi-condbreak-fail.c:30
(More stack frames follow...)
(gdb)
This is the broken state. GDB is reports the SIGSEGV location, but
not the unwound breakpoint location. The final 'bt 1' shows that the
inferior is not located in cond_fail, which is the only location GDB
reported, so this is clearly wrong.
After implementing the fixes described above we now get this
behaviour:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Error in testing breakpoint condition for breakpoint 1:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
This is better. GDB now reports a single stop at the location of the
breakpoint, which is where the inferior is actually located. However,
by removing the first stop notification we have lost some potentially
useful information about which signal caused the inferior to stop.
To address this I've reworked the message that is printed to include
the signal information. GDB now reports this:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Error in testing condition for breakpoint 1:
The program being debugged received signal SIGSEGV, Segmentation fault
while in a function called from GDB. GDB has restored the context
to what it was before the call. To change this behavior use
"set unwindonsignal off". Evaluation of the expression containing
the function (cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
This is better, the user now sees a single stop notification at the
correct location, and the error message describes which signal caused
the inferior function call to stop.
However, we have lost the information about where the signal
occurred. I did consider trying to include this information in the
error message, but, in the end, I opted not too. I wasn't sure it was
worth the effort. If the user has selected to unwind on signal, then
surely this implies they maybe aren't interested in debugging failed
inferior calls, so, hopefully, just knowing the signal name will be
enough. I figure we can always add this information in later if
there's a demand for it.
|
|
When loading an executable using "file a.out", the language is set according
to a.out, which can involve looking up the language of symbol "main", which
will cause the symtab expansion for the containing CU.
Expansion of lto debug info can be slow, so in commit d3214198119 ("[gdb] Use
partial symbol table to find language for main") a feature was added to avoid
the symtab expansion.
This feature stopped working after commit 7f4307436fd ("Fix "start" for D,
Rust, etc").
[ The commit addresses problems related to command start, which requires finding
the main function:
- for language D, "main" was found instead of "D main", and
- for Rust, the correct function was found, but attributed the wrong name
(not fully qualified). ]
Reimplement the feature by adding
cooked_index_functions::lookup_global_symbol_language.
Tested on x86_64-linux.
PR symtab/30661
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30661
|
|
This patch removes many TODOs from the gdb.cp tests.
Going through the patch:
* bs15503.exp - these have been commented out forever and rely on
libstdc++ debuginfo. It's better to just remove these.
* classes.exp - the test is wrong, I think, according to the C++ ABI
that gdb understands; and the test can be fixed and comments removed
with a simple change to the code.
* ctti.exp - there's no need to bail out any more, as the test works.
* exception.exp - the code relying on the line numbers can't work,
because gdb never prints that message anyway.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
When debugging C++ programs, it is possible to trigger a spurious assert
failure when attempting to set a breakpoint on a malformed symbol name.
Names of the form 'A>::B' and 'A)::B' trigger this assert failure in
cp_lookup_bare_symbol:
$ gdb gdb
[...]
(gdb) br test>::assert
Function "test>::assert" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (test>::assert) pending.
(gdb) start
[...]
cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5217e2 gdb_internal_backtrace_1
/home/amerey/binutils-gdb/gdb/bt-utils.c:122
0x521885 _Z22gdb_internal_backtracev
/home/amerey/binutils-gdb/gdb/bt-utils.c:168
0xaf8303 internal_vproblem
/home/amerey/binutils-gdb/gdb/utils.c:396
0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag
/home/amerey/binutils-gdb/gdb/utils.c:476
0xccdb3f _Z18internal_error_locPKciS0_z
/home/amerey/binutils-gdb/gdbsupport/errors.cc:58
0x5dded9 cp_lookup_bare_symbol
/home/amerey/binutils-gdb/gdb/cp-namespace.c:181
0x5de39d cp_lookup_symbol_in_namespace
/home/amerey/binutils-gdb/gdb/cp-namespace.c:328
[...]
Currently this assert is skipped if the symbol name contains '<' or '('.
Fix this spurious failure by also skipping the assert when the symbol
name contains '>' or ')'.
Regression tested on F38 x86_64.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix a few typos:
- implemention -> implementation
- convertion(s) -> conversion(s)
- backlashes -> backslashes
- signoring -> ignoring
- (un)ambigious -> (un)ambiguous
- occured -> occurred
- hidding -> hiding
- temporarilly -> temporarily
- immediatelly -> immediately
- sillyness -> silliness
- similiar -> similar
- porkuser -> pokeuser
- thats -> that
- alway -> always
- supercede -> supersede
- accomodate -> accommodate
- aquire -> acquire
- priveleged -> privileged
- priviliged -> privileged
- priviledges -> privileges
- privilige -> privilege
- recieve -> receive
- (p)refered -> (p)referred
- succesfully -> successfully
- successfuly -> successfully
- responsability -> responsibility
- wether -> whether
- wich -> which
- disasbleable -> disableable
- descriminant -> discriminant
- construcstor -> constructor
- underlaying -> underlying
- underyling -> underlying
- structureal -> structural
- appearences -> appearances
- terciarily -> tertiarily
- resgisters -> registers
- reacheable -> reachable
- likelyhood -> likelihood
- intepreter -> interpreter
- disassemly -> disassembly
- covnersion -> conversion
- conviently -> conveniently
- atttribute -> attribute
- struction -> struct
- resonable -> reasonable
- popupated -> populated
- namespaxe -> namespace
- intialize -> initialize
- identifer(s) -> identifier(s)
- expection -> exception
- exectuted -> executed
- dungerous -> dangerous
- dissapear -> disappear
- completly -> completely
- (inter)changable -> (inter)changeable
- beakpoint -> breakpoint
- automativ -> automatic
- alocating -> allocating
- agressive -> aggressive
- writting -> writing
- reguires -> requires
- registed -> registered
- recuding -> reducing
- opeartor -> operator
- ommitted -> omitted
- modifing -> modifying
- intances -> instances
- imbedded -> embedded
- gdbaarch -> gdbarch
- exection -> execution
- direcive -> directive
- demanged -> demangled
- decidely -> decidedly
- argments -> arguments
- agrument -> argument
- amespace -> namespace
- targtet -> target
- supress(ed) -> suppress(ed)
- startum -> stratum
- squence -> sequence
- prompty -> prompt
- overlow -> overflow
- memember -> member
- languge -> language
- geneate -> generate
- funcion -> function
- exising -> existing
- dinking -> syncing
- destroh -> destroy
- clenaed -> cleaned
- changep -> changedp (name of variable)
- arround -> around
- aproach -> approach
- whould -> would
- symobl -> symbol
- recuse -> recurse
- outter -> outer
- freeds -> frees
- contex -> context
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit makes two changes to how we match newline characters in
the gdb_test proc.
First, for the newline pattern between the command output and the
prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.
The old pattern would spot multiple newlines, and so there are a few
places where, as part of this commit, I've needed to add an extra
trailing '\r\n' to the pattern in the main test file, where GDB's
output actually includes a blank line.
But I think this is a good thing. If a command produces a blank line
then we should be checking for it, the current gdb_test doesn't do
that. But also, with the current gdb_test, if a blank line suddenly
appears in the output, this is going to be silently ignored, and I
think this is wrong, the test should fail in that case.
Additionally, the existing pattern will happily match a partial
newline. There are a strangely large number of tests that end with a
random '.' character. Not matching a literal period, but matching any
single character, this is then matching half of the trailing newline
sequence, while the \[\r\n\]+ in gdb_test is matching the other half
of the sequence. I can think of no reason why this would be
intentional, I suspect that the expected output at one time included a
period, which has since been remove, but I haven't bothered to check
on this. In this commit I've removed all these unneeded trailing '.'
characters.
The basic rule of gdb_test after this is that the expected pattern
needs to match everything up to, but not including the newline
sequence immediately before the GDB prompt. This is generally how the
proc is used anyway, so in almost all cases, this commit represents no
significant change.
Second, while I was cleaning up newline matching in gdb_test, I've
also removed the '[\r\n]*' that was added to the start of the pattern
passed to gdb_test_multiple.
The addition of this pattern adds no value. If the user pattern
matches at the start of a line then this would match against the
newline sequence. But, due to the '*', if the user pattern doesn't
match at the start of a line then this group doesn't care, it'll
happily match nothing.
As such, there's no value to it, it just adds more complexity for no
gain, so I'm removing it. No tests will need updating as a
consequence of this part of the patch.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), there
was a silent regression on openSUSE Leap 15.4 for test-case
gdb.cp/m-static.exp, from:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /home/vries/tmp.local-remote-host-native/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
(gdb)
...
to:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
8: const int gnu_obj_4::everywhere;^M
(gdb)
...
Another regression was found due to that commit, and it was fixed in commit
99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") by
limiting the scope of the fix in the original commit.
Fix this regression by yet further limiting the scope of that fix, making sure
that this bit in dwarf_decode_lines is executed again for m-static1.cc:
...
/* Make sure a symtab is created for every file, even files
which contain only variables (i.e. no code with associated
line numbers). */
...
Tested on x86_64-linux.
PR symtab/30265
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30265
|
|
In commit 722c4596034 ("[gdb/testsuite] Fix gdb.cp/*.exp for remote host"), I
needed to change ".*/" into "(.*/)?" in:
...
gdb_test "info variable everywhere" \
"File .*/m-static\[.\]h.*const int gnu_obj_4::everywhere;"
...
However, due to the fact that I got this output:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
8: const int gnu_obj_4::everywhere;^M
...
I decided to make the matching somewhat stricter, to make sure that the two
matched lines were subsequent.
The commit turned out to be more strict than intended, and caused a regression
on Ubuntu 20.04, where the output was instead:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
...
At that point I realized I'm looking at a bug (filed as PR symtab/30265),
which manifests on openSUSE Leap 15.4 for native and readnow, and on Ubuntu
20.04 for readnow, but not for native.
Before my commit, the test-case passed whether the bug manifested or not.
After my commit, the test-case only passed when the bug manifested.
Fix the test-case regression by reverting to the situation before the commit:
pass whether the bug manifests or not. We could add an xfail for the PR, but
I'm expecting a fix soon, so that doesn't look worth the effort.
Tested on x86_64-linux, both on openSUSE Leap 15.4 and Ubuntu 20.04, both with
native and readnow.
Reported-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Fix test-case gdb.cp/cp-relocate.exp for remote host using
gdb_remote_download.
Tested on x86_64-linux.
|
|
When running test-cases gdb.cp/annota{2,3}.exp with target board
native-extended-gdbserver, we run into a few FAILs, due to the test-cases
trying to match inferior output together with gdb output.
Fix this by ignoring the inferior output in this case.
Tested on x86_64-linux.
|
|
Fix a few test-cases in gdb.cp/*.exp for remote host using new proc
include_file.
Tested on x86_64-linux.
|
|
In some cases GDB will fail when attempting to complete a command that
involves a rust symbol, the failure can manifest as a crash.
The problem is caused by the completion_match_for_lcd object being
left containing invalid data during calls to cp_symbol_name_matches_1.
The first question to address is why we are calling a C++ support
function when handling a rust symbol. That's due to GDB's auto
language detection for msymbols, in some cases GDB can't tell if a
symbol is a rust symbol, or a C++ symbol.
The test application contains symbols for functions which are
statically linked in from various rust support libraries. There's no
DWARF for these symbols, so all GDB has is the msymbols built from the
ELF symbol table.
Here's the problematic symbol that leads to our crash:
mangled: _ZN4core3str21_$LT$impl$u20$str$GT$5parse17h5111d2d6a50d22bdE
demangled: core::str::<impl str>::parse
As an msymbol this is initially created with language auto, then GDB
eventually calls symbol_find_demangled_name, which loops over all
languages calling language_defn::sniff_from_mangled_name, the first
language that can demangle the symbol gets assigned as the language
for that symbol.
Unfortunately, there's overlap in the mangled symbol names,
some (legacy) rust symbols can be demangled as both rust and C++, see
cplus_demangle in libiberty/cplus-dem.c where this is mentioned.
And so, because we check the C++ language before we check for rust,
then the msymbol is (incorrectly) given the C++ language.
Now it's true that is some cases we might be able to figure out that a
demangled symbol is not actually a valid C++ symbol, for example, in
our case, the construct '::<impl str>::' is not, I believe, valid in a
C++ symbol, we could look for ':<' and '>:' and refuse to accept this
as a C++ symbol.
However, I'm not sure it is always possible to tell that a demangled
symbol is rust or C++, so, I think, we have to accept that some times
we will get this language detection wrong.
If we accept that we can't fix the symbol language detection 100% of
the time, then we should make sure that GDB doesn't crash when it gets
the language wrong, that is what this commit addresses.
In our test case the user tries to complete a symbol name like this:
(gdb) complete break pars
This results in GDB trying to find all symbols that match 'pars',
eventually we consider our problematic symbol, and we end up with a
call stack that looks like this:
#0 0x0000000000f3c6bd in strncmp_iw_with_mode
#1 0x0000000000706d8d in cp_symbol_name_matches_1
#2 0x0000000000706fa4 in cp_symbol_name_matches
#3 0x0000000000df3c45 in compare_symbol_name
#4 0x0000000000df3c91 in completion_list_add_name
#5 0x0000000000df3f1d in completion_list_add_msymbol
#6 0x0000000000df4c94 in default_collect_symbol_completion_matches_break_on
#7 0x0000000000658c08 in language_defn::collect_symbol_completion_matches
#8 0x0000000000df54c9 in collect_symbol_completion_matches
#9 0x00000000009d98fb in linespec_complete_function
#10 0x00000000009d99f0 in complete_linespec_component
#11 0x00000000009da200 in linespec_complete
#12 0x00000000006e4132 in complete_address_and_linespec_locations
#13 0x00000000006e4ac3 in location_completer
In cp_symbol_name_matches_1 we enter a loop, this loop repeatedly
tries to match the demangled problematic symbol name against the user
supplied text ('pars'). Each time around the loop another component
of the symbol name is stripped off, thus, we check 'pars' against
these options:
core::str::<impl str>::parse
str::<impl str>::parse
<impl str>::parse
parse
As soon as we get a match the cp_symbol_name_matches_1 exits its loop
and returns. In our case, when we're looking for 'pars', the match
occurs on the last iteration of the loop, when we are comparing to
'parse'.
Now the problem here is that cp_symbol_name_matches_1 uses the
strncmp_iw_with_mode, and inside strncmp_iw_with_mode we allow for
skipping over template parameters. This allows GDB to match the
symbol name 'foo<int>(int,int)' if the user supplies 'foo(int,'.
Inside strncmp_iw_with_mode GDB will record any template arguments
that it has skipped over inside the completion_match_for_lcd object
that is passed in as an argument.
And so, when GDB tries to match against '<impl str>::parse', the first
thing it sees is '<impl str>', GDB assumes this is a template argument
and records this as a skipped region within the
completion_match_for_lcd object. After '<impl str>' GDB sees a ':'
character, which doesn't match with the 'pars' the user supplied, so
strncmp_iw_with_mode returns a value indicating a non-match. GDB then
removes the '<impl str>' component from the symbol name and tries
again, this time comparing to 'parse', which does match.
Having found a match, then in cp_symbol_name_matches_1 we record the
match string, and the full symbol name within the
completion_match_result object, and return.
The problem here is that the skipped region, the '<impl str>' that we
recorded in the penultimate loop iteration was never discarded, its
still there in our returned result.
If we look at what the pointers held in the completion_match_result
that cp_symbol_name_matches_1 returns, this is what we see:
core::str::<impl str>::parse
| \________/ |
| | '--- completion match string
| '---skip range
'--- full symbol name
When GDB calls completion_match_for_lcd::finish, GDB tries to create a
string using the completion match string (parse), but excluding the
skip range, as the stored skip range is before the start of the
completion match string, then GDB tries to do some weird string
creation, which will cause GDB to crash.
The reason we don't often see this problem in C++ is that for C++
symbols there is always some non-template text before the template
argument. This non-template text means GDB is likely to either match
the symbol, or reject the symbol without storing a skip range.
However, notice, I did say, we don't often see this problem. Once I
understood the issue, I was able to reproduce the crash using a pure
C++ example:
template<typename S>
struct foo
{
template<typename T>
foo (int p1, T a)
{
s = 0;
}
S s;
};
int
main ()
{
foo<int> obj (2.3, 0);
return 0;
}
Then in GDB:
(gdb) complete break foo(int
The problem here is that the C++ symbol for the constructor looks like
this:
foo<int>::foo<double>(int, double)
When GDB enters cp_symbol_name_matches_1 the symbols it examines are:
foo<int>::foo<double>(int, double)
foo<double>(int, double)
The first iteration of the loop will match the 'foo', then add the
'<int>' template argument will be added as a skip range. When GDB
find the ':' after the '<int>' the first iteration of the loop fails
to match, GDB removes the 'foo<int>::' component, and starts the
second iteration of the loop.
Again, GDB matches the 'foo', and now adds '<double>' as a skip
region. After that the '(int' successfully matches, and so the second
iteration of the loop succeeds, but, once again we left the '<int>' in
place as a skip region, even though this occurs before the start of
our match string, and this will cause GDB to crash.
This problem was reported to the mailing list, and a solution
discussed in this thread:
https://sourceware.org/pipermail/gdb-patches/2023-January/195166.html
The solution proposed here is similar to one proposed by the original
bug reported, but implemented in a different location within GDB.
Instead of placing the fix in strncmp_iw_with_mode, I place the fix in
cp_symbol_name_matches_1. I believe this is a better location as it
is this function that implements the loop, and it is this loop, which
repeatedly calls strncmp_iw_with_mode, that should be resetting the
result object state (I believe).
What I have done is add an assert to strncmp_iw_with_mode that the
incoming result object is empty.
I've also added some other asserts in related code, in
completion_match_for_lcd::mark_ignored_range, I make some basic
assertions about the incoming range pointers, and in
completion_match_for_lcd::finish I also make some assertions about how
the skip ranges relate to the match pointer.
There's two new tests. The original rust example that was used in the
initial bug report, and a C++ test. The rust example depends on which
symbols are pulled in from the rust libraries, so it is possible that,
at some future date, the problematic symbol will disappear from this
test program. The C++ test should be more reliable, as this only
depends on symbols from within the C++ source code.
Since I originally posted this patch to the mailing list, the
following patch has been merged:
commit 6e7eef72164c00d6a5a7b0bce9fa01f5481f33cb
Date: Sun Mar 19 09:13:10 2023 -0600
Use rust_demangle to fix a crash
This solves the problem of a rust symbol ending up in the C++ specific
code by changing the order languages are sorted. However, this new
commit doesn't address the issue in the C++ code which was fixed with
this commit.
Given that the C++ issue is real, and has a reproducer, I'm still
going to merge this fix. I've left the discussion of rust in this
commit message as I originally wrote it, but it should be read within
the context of GDB prior to commit 6e7eef72164c00d6a5a7.
Co-Authored-By: Zheng Zhan <zzlossdev@163.com>
|
|
Handle $srcdir/lib/attributes.h using lappend_include_dir.
Tested on x86_64-linux.
|
|
This changes many tests to use 'require' when checking target_info.
In a few spots, the require is hoisted to the top of the file, to
avoid doing any extra work when the test is going to be skipped
anyway.
|
|
remote-gdbserver-on-localhost
Test-case gdb.cp/breakpoint-shlib-func.exp fails with target board
remote-gdbserver-on-localhost.
Fix this by adding the missing gdb_load_shlib.
Tested on x86_64-linux.
|
|
In C++ it is possible to use an empty enum as a strong typedef. For
example, a user could write:
enum class my_type : unsigned char {};
Now my_type can be used like 'unsigned char' except the compiler will
not allow implicit conversion too and from the native 'unsigned char'
type.
This is used in the standard library for things like std::byte.
Currently, when GDB prints a value of type my_type, it looks like
this:
(gdb) print my_var
$1 = (unknown: 0x4)
Which isn't great. This gets worse when we consider something like:
std::vector<my_type> vec;
When using a pretty-printer, this could look like this:
std::vector of length 2, capacity 2 = {(unknown: 0x2), (unknown: 0x4)}
Clearly not great. This is described in PR gdb/30148.
The problem here is in dwarf2/read.c, we assume all enums are flag
enums unless we find an enumerator with a non-flag like value.
Clearly an empty enum contains no non-flag values, so we assume the
enum is a flag enum.
I propose adding an extra check here; that is, an empty enum should
never be a flag enum.
With this the above cases look more like:
(gdb) print my_var
$1 = 4
and:
std::vector of length 2, capacity 2 = {2, 4}
Which look much better.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30148
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit should fix PR gdb/20091, PR gdb/17201, and PR gdb/17071.
Additionally, PR gdb/17199 relates to this area of code, but is more
of a request to refactor some parts of GDB, this commit does not
address that request, but it is probably worth reading that PR when
looking at this commit.
When the current language is C++, and the user places a breakpoint on
a function in a shared library, GDB will currently find two locations
for the breakpoint, one location will be within the function itself as
we would expect, but the other location will be within the PLT table
for the call to the named function. Consider this session:
$ gdb -q /tmp/breakpoint-shlib-func
Reading symbols from /tmp/breakpoint-shlib-func...
(gdb) start
Temporary breakpoint 1 at 0x40112e: file /tmp/breakpoint-shlib-func.cc, line 20.
Starting program: /tmp/breakpoint-shlib-func
Temporary breakpoint 1, main () at /tmp/breakpoint-shlib-func.cc:20
20 int answer = foo ();
(gdb) break foo
Breakpoint 2 at 0x401030 (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
2.1 y 0x0000000000401030 <foo()@plt>
2.2 y 0x00007ffff7fc50fd in foo() at /tmp/breakpoint-shlib-func-lib.cc:20
This is not the expected behaviour. If we compile the same test using
a C compiler then we see this:
(gdb) break foo
Breakpoint 2 at 0x7ffff7fc50fd: file /tmp/breakpoint-shlib-func-c-lib.c, line 20.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x00007ffff7fc50fd in foo at /tmp/breakpoint-shlib-func-c-lib.c:20
Here's what's happening. When GDB parses the symbols in the main
executable and the shared library we see a number of different symbols
for foo, and use these to create entries in GDB's msymbol table:
- In the main executable we see a symbol 'foo@plt' that points at
the plt entry for foo, from this we add two entries into GDB's
msymbol table, one called 'foo@plt' which points at the plt entry
and has type mst_text, then we create a second symbol, this time
called 'foo' with type mst_solib_trampoline which also points at
the plt entry,
- Then, when the shared library is loaded we see another symbol
called 'foo', this one points at the actual implementation in the
shared library. This time GDB creates a msymbol called 'foo' with
type mst_text that points at the implementation.
This means that GDB creates 3 msymbols to represent the 2 symbols
found in the executable and shared library.
When the user creates a breakpoint on 'foo' GDB eventually ends up in
search_minsyms_for_name (linespec.c), this function then calls
iterate_over_minimal_symbols passing in the name we are looking for
wrapped in a lookup_name_info object.
In iterate_over_minimal_symbols we iterate over two hash tables (using
the name we're looking for as the hash key), first we walk the hash
table of symbol linkage names, then we walk the hash table of
demangled symbol names.
When the language is C++ the symbols for 'foo' will all have been
mangled, as a result, in this case, the iteration of the linkage name
hash table will find no matching results.
However, when we walk the demangled hash table we do find some
results. In order to match symbol names, GDB obtains a symbol name
matching function by calling the get_symbol_name_matcher method on the
language_defn class. For C++, in this case, the matching function we
use is cp_fq_symbol_name_matches, which delegates the work to
strncmp_iw_with_mode with mode strncmp_iw_mode::MATCH_PARAMS and
language set to language_cplus.
The strncmp_iw_mode::MATCH_PARAMS mode means that strncmp_iw_mode will
skip any parameters in the demangled symbol name when checking for a
match, e.g. 'foo' will match the demangled name 'foo()'. The way this
is done is that the strings are matched character by character, but,
once the string we are looking for ('foo' here) is exhausted, if we
are looking at '(' then we consider the match a success.
Lets consider the 3 symbols GDB created. If the function declaration
is 'void foo ()' then from the main executable we added symbols
'_Z3foov@plt' and '_Z3foov', while from the shared library we added
another symbol call '_Z3foov'. When these are demangled they become
'foo()@plt', 'foo()', and 'foo()' respectively.
Now, the '_Z3foov' symbol from the main executable has the type
mst_solib_trampoline, and in search_minsyms_for_name, we search for
any symbols of type mst_solib_trampoline and filter these out of the
results.
However, the '_Z3foov@plt' symbol (from the main executable), and the
'_Z3foov' symbol (from the shared library) both have type mst_text.
During the demangled name matching, due to the use of MATCH_PARAMS
mode, we stop the comparison as soon as we hit a '(' in the demangled
name. And so, '_Z3foov@plt', which demangles to 'foo()@plt' matches
'foo', and '_Z3foov', which demangles to 'foo()' also matches 'foo'.
By contrast, for C, there are no demangled hash table entries to be
iterated over (in iterate_over_minimal_symbols), we only consider the
linkage name symbols which are 'foo@plt' and 'foo'. The plain 'foo'
symbol obviously matches when we are looking for 'foo', but in this
case the 'foo@plt' will not match due to the '@plt' suffix.
And so, when the user asks for a breakpoint in 'foo', and the language
is C, search_minsyms_for_name, returns a single msymbol, the mst_text
symbol for foo in the shared library, while, when the language is C++,
we get two results, '_Z3foov' for the shared library function, and
'_Z3foov@plt' for the plt entry in the main executable.
I propose to fix this in strncmp_iw_with_mode. When the mode is
MATCH_PARAMS, instead of stopping at a '(' and assuming the match is a
success, GDB will instead search forward for the matching, closing,
')', effectively skipping the parameter list, and then resume
matching. Thus, when comparing 'foo' to 'foo()@plt' GDB will
effectively compare against 'foo@plt' (skipping the parameter list),
and the match will fail, just as it does when the language is C.
There is one slight complication, which is revealed by the test
gdb.linespec/cpcompletion.exp, when searching for the symbol of a
const member function, the demangled symbol will have 'const' at the
end of its name, e.g.:
struct_with_const_overload::const_overload_fn() const
Previously, the matching would stop at the '(' character, but after my
change the whole '()' is skipped, and the match resumes. As a result,
the 'const' modifier results in a failure to match, when previously
GDB would have found a match.
To work around this issue, in strncmp_iw_with_mode, when mode is
MATCH_PARAMS, after skipping the parameter list, if the next character
is '@' then we assume we are looking at something like '@plt' and
return a value indicating the match failed, otherwise, we return a
value indicating the match succeeded, this allows things like 'const'
to be skipped.
With these changes in place I now see GDB correctly setting a
breakpoint only at the implementation of 'foo' in the shared library.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20091
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17201
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17071
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17199
Tested-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Change gdb.cp to use clean_restart more consistently.
|
|
A number of tests end with "return". However, this is unnecessary.
This patch removes all of these.
|
|
Due to a GDB bug (visible when building with -D_GLIBCXX_DEBUG), GDB
crashes somewhere in the middle of gdb.cp/cpexprs.exp, and thus fails to
read the string, at gdb.cp/cpexprs.exp.tcl:725. The "correct" variable
doesn't get set, and I then see this TCL error:
ERROR: can't read "correct": no such variable
Avoid the TCL error by initializing the "correct" variable to a dummy
value.
Change-Id: I828968d9b2d105ef47f8da2ef598aa16a518c059
|
|
Add new proc is_x86_64_m64_target and use it where appropriate.
Tested on x86_64-linux.
|
|
The previous commit touched the source file for the test script
gdb.cp/cpcompletion.exp. This source file is called pr9594.cc. The
source file is only used by the one test script.
This commit renames the source file to cpcompletion.cc to match the
test script, this is more inline with how we name source files these
days.
|
|
Spotted in gdb.cp/cpcompletion.exp that we could replace some uses of
gdb_test with test_gdb_complete_unique, this will extend the
completion testing to check tab-completion as well as completion using
the 'complete' command in some additional cases.
|
|
While looking at some test output, I saw that no-libstdcxx-probe.exp
was not being run. However, it occurred to me that Tom de Vries' new
"maint ignore-probes" command could be used to enable this test
unconditionally.
Reviewed-by: Tom de Vries <tdevries@suse.de>
|
