| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
$_hit_locno PR breakpoints/12464
This implements the request given in PR breakpoints/12464.
Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.
Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.
$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
disable $_hit_bpnum.$_hit_locno
In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.
This also fixes a strange behaviour: when a breakpoint X has only
one location,
enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.
The changes in RFA v4 handle the comments of Tom Tromey:
- Changed convenience var names from $bkptno/$locno to
$_hit_bpnum/$_hit_locno.
- updated the tests and user manual accordingly.
User manual also explictly describes that $_hit_locno is set to 1
for a breakpoint with a single location.
- The variable values are now set in bpstat_do_actions_1 so that
they are set for silent breakpoints, and when several breakpoints
are hit at the same time, that the variables are set to the printed
breakpoint.
The changes in RFA v3 handle the additional comments of Eli:
GDB/NEW:
- Use max 80-column
- Use 'code location' instead of 'location'.
- Fix typo $bkpno
- Ensure that disable $bkptno and disable $bkptno.$locno have
each their explanation inthe example
- Reworded the 'breakpoint-hit' paragraph.
gdb.texinfo:
- Use 'code location' instead of 'location'.
- Add a note to clarify the distinction between $bkptno and $bpnum.
- Use @kbd instead of examples with only one command.
Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
- Use %s for the result of paddress
- Use bkptno_numopt_re instead of 2 different -re cases
- use C@t{++}
- Add index entries for $bkptno and $locno
- Added an example for "locno" in the mi interface
- Added examples in the Break command manual.
|
|
Convert the gdb.cp/call-method-register.exp test to make use of the
DWARF assembler.
The existing gdb.cp/call-method-register.exp test relies on a GCC
extension - forcing a local variable into a particular named register.
This means that the test will only work with Clang, and, as we have to
name the register into which the variable will be placed, will only
work for those targets where we've selected a suitable register,
currently this is x86-64, i386, and ppc64.
By switching to the DWARF assembler, the test will work with gcc and
clang, and should work on most, if not all, architectures.
The test creates a small structure, something that can fit within a
register, and then tries to call a method on the structure from within
GDB. This should fail because GDB can't take the address of the in
register structure (for the `this` pointer).
As the test is for a failure case, then we don't really care _which_
register the structure is in, and I take advantage of this for the
DWARF assembler test, I just declare that the variable is in
DW_OP_reg0, whatever that might be. I've tested the new test on
x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all
these architectures, which is already more than we used to cover.
Additionally, on x86-64, I've tested with Clang and gcc, and the test
runs and passed with both compilers.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
|
|
Two tests make the claim that the DWARF assembler requires gcc,
however, this isn't true. I think at one point, when the DWARF
assembler was first added, we did use some techniques that were not
portable (see the comments in lib/dwarf.exp on function_range for
details), however, I think most DWARF assembler tests will now work
fine with Clang.
The two tests that I modify in this commit both work fine with Clang,
at least, I've tested with Clang 9.0.1 and 15.0.2, and don't see any
problems, so I'm removing the early return logic that stops these
tests from running with Clang.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
|
|
values.
Currently, a non-trivial return value from a function cannot currently be
reliably determined on PowerPC. This is due to the fact that the PowerPC
ABI uses register r3 to store the address of the buffer containing the
non-trivial return value when the function is called. The PowerPC ABI
does not guarantee the value in register r3 is not modified in the
function. Thus the value in r3 cannot be reliably used to obtain the
return addreses on exit from the function.
This patch adds a new gdbarch method to allow PowerPC to access the value
of r3 on entry to a function. On PowerPC, the new gdbarch method attempts
to use the DW_OP_entry_value for the DWARF entries, when exiting the
function, to determine the value of r3 on entry to the function. This
requires the use of the -fvar-tracking compiler option to compile the
user application thus generating the DW_OP_entry_value in the binary. The
DW_OP_entry_value entries in the binary file allows GDB to resolve the
DW_TAG_call_site entries. This new gdbarch method is used to get the
return buffer address, in the case of a function returning a nontrivial
data type, on exit from the function. The GDB function should_stop checks
to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to
zero by the new gdbarch method call for all architectures except PowerPC.
The get_return_value function will be used to obtain the return value on
all other architectures as is currently being done if RETURN_BUF is zero.
On PowerPC, the new gdbarch method will return a nonzero address in
RETURN_BUF if the value can be determined. The value_at function uses the
return buffer address to get the return value.
This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp.
The correct function return values are now reported.
Note this patch is dependent on patch: "PowerPC, function
ppc64_sysv_abi_return_value add missing return value convention".
This patch has been tested on Power 10 and x86-64 with no regressions.
|
|
The test gdb.cp/call-method-register.exp assumes that the class will be
placed on a register. However, this keyword has been deprecated since
C++11, and Clang, for instance, does not feel the need to follow it.
Since this test is not usable without this working, this commit marks
this test as untested.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
gdb.cp/temargs.exp last 2 tests always setup an XFAILs, despite checking
for old gcc versions. However, Clang does not fail in this test,
turning into XPASSes and slighty annoying when comparing between
compilers. To change this, make the xfails only happen if we using gcc.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
Since Clang chooses to not add any debug information for base types,
expecting it to be included with libraries' informations, gdb.cp/typeid.exp
will always fail if the program hasn't started. This commit fixes that by
making it so when using Clang, the base type variables aren't tested.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
When Clang compiles anonymous structures, it does not add linkage names in
their dwarf representations. This is compounded by Clang not adding linkage
names to subprograms of those anonymous structs (for instance, the
constructor). With these 2 things together, GDB is unable to refer to
any of them, so there is no way to pass any of the tests of
gdb.cp/anon-struct.exp
Since this isn't a bug on Clang or GDB according to the DWARF
specifications as DW_AT_name is optional for all DIEs, the test was marked
as untested.
Since I was already touching the file, I also added a comment at the top
of the file explaining what it is testing for.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
when running gdb.cp/m-static.exp using Clang, we get the following
failures:
print test1.~gnu_obj_1^M
$6 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print destructor
ptype test1.~gnu_obj_1^M
type = void (gnu_obj_1 * const)^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype destructor
print test1.'~gnu_obj_1'^M
$7 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print quoted destructor
This is because the test is expecting an extra integer parameter on the
destructor. Looking at the debuginfo, it seems that there is nothing
actually wrong with this output, so these tests were changed to test
multiple possible regexps.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
When running gdb.cp/derivation.exp using Clang, we get an unexpected
failure when printing the type of a class with an internal typedef. This
happens because Clang doesn't add accessibility information for typedefs
inside classes (see https://github.com/llvm/llvm-project/issues/57608
for more info). To help with Clang testing, an XFAIL was added to this
test.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
When compiling virtual classes's destructors, two versions are compiled,
one with a single parameter (this) and the other with 2 parameters (this
and vtt).
GCC's compilation makes it so either the version with 1
parameter or the one with 2 parameters is called, depending on whether
the destructor is being called by the class itself or by an inherited
class. On the test gdb.cp/mb-ctor.exp, this means that the breakpoint
set at the destructor will be hit 4 times.
Clang, on the other hand, makes the single-parameter version call the 2
parameter version, probably in an attempt to reduce the size of the
resulting executable. This means that the gdb.cp/mb-ctor.exp will hit 6
breakpoints before finishing, and is the reason why this test was
failing. To make this test stop failing, a compiler check is added and
another "continue" instruction is issued to account for this difference.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
When attempting to run the gdb.cp/classes.exp test using Clang++, the
test fails to prepare with -Wnon-c-typedef-for-linkage like the
previously fixed gdb.cp/class2.exp. Upon fixing this, the test shows 5
unexpected failures. One such failures is:
ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
private:
int a;
public:
class_with_public_typedef::INT b;
private:
typedef int INT;
}
(gdb) FAIL: gdb.cp/classes.exp: ptype class class_with_public_typedef // wrong access specifier for typedef: private
While g++ provided the following output:
ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
private:
int a;
public:
class_with_public_typedef::INT b;
typedef int INT;
}
(gdb) PASS: gdb.cp/classes.exp: ptype class class_with_public_typedef
This error happens because Clang does not add DW_AT_accessibility to
typedefs inside classes, and without this information GDB defaults to
assuming the typedef is private. Since there is nothing that GDB can do
about this, these tests have been set as xfails, and Clang bug 57608 has
been filed.
Bug: https://github.com/llvm/llvm-project/issues/57608
Approved-by: Tom Tromey <tom@tromey.com>
|
|
When attempting to test gdb.cp/class2.exp using Clang, it fails to
prepare with the following error:
Executing on host: clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc (timeout = 300)
builtin_spawn -ignore SIGHUP clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
^
Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
public:
^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
^
1 warning generated.
gdb compile failed, /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
^
Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
public:
^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
^
1 warning generated.
UNTESTED: gdb.cp/class2.exp: failed to prepare
This can be silenced by adding -Wno-non-c-typedef-for-linkage for Clang
11 or later. The test shows no failures with this change.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
When resolving overloaded functions, GDB relies on knowing relationships
between types, i.e. if a type inherits from another. However, some
compilers may not add complete information for given types as a way to
reduce unnecessary debug information. In these cases, GDB would just say
that it couldn't resolve the method or function, with no extra
information.
The problem is that sometimes the user may not know that the type
information is incomplete, and may just assume that there is a bug in
GDB. To improve the user experience, we attempt to detect if the
overload match failed because of an incomplete type, and warn the user
of this.
This commit also adds a testcase confirming that the message is only
triggered in the correct scenario. This test was not developed as an
expansion of gdb.cp/overload.cc because it needed the dwarf assembler,
and porting all of overload.cc seemed unnecessary.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR c++/29243 points out that "info func" on a certain C++ executable
will cause an infinite loop in gdb.
I tracked this down to a bug introduced by commit 6b5a7bc76 ("Handle
member pointers directly in generic_value_print"). Before this
commit, the C++ code to print a member pointer would wind up calling
value_print_scalar_formatted; but afterward it simply calls
generic_value_print and gets into a loop.
This patch restores the previous behavior and adds a regression test.
|
|
Clang attempts to minimize the size of the debug-info by not adding
complete information about types that aren't constructed in a given
file. Specifically, this meant that there was minimal information about
class B in the test gdb.cp/converts.exp. To fix this, we just need to
construct any object of type B in that file.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When running gdb.cp/ptype-flags.exp using Clang, we get an unexpected
failure when printing the type of a class with an internal typedef. This
happens because Clang doesn't add accessibility information for typedefs
inside classes (see https://github.com/llvm/llvm-project/issues/57608
for more info). To help with Clang testing, an XFAIL was added to this
test.
|
|
When a class inherits from a typedef'd baseclass, GDB may be unable to
find the baseclass if the user is not using the typedef'd name, as is
tested on gdb.cp/virtbase2.exp; the reason that test case is working
under gcc is that the dwarf generated by gcc links the class to the
original definition of the baseclass, not to the typedef. If the
inheritance is linked to the typedef, such as how clang does it,
gdb.cp/virtbase2.exp starts failing.
This can also be seen in gdb.cp/impl-this.exp, when attempting to print
D::Bint::i, and GDB not being able to find the baseclass Bint.
This happens because searching for baseclasses only uses the macro
TYPE_BASECLASS_NAME, which returns the typedef'd name. However, we can't
switch that macro to checking for typedefs, otherwise we wouldn't be
able to find the typedef'd name anymore. This is fixed by searching for
members or baseclasses by name, we check both the saved name and the
name after checking for typedefs.
This also fixes said long-standing bug in gdb.cp/impl-this.exp when the
compiler adds information about typedefs in the debuginfo.
|
|
Consider the test-case contained in this patch.
With g++ (7.5.0) we have for "ptype A":
...
type = class A {
public:
int a;
A(void);
~A();
}
...
and with clang++ (13.0.1):
...
type = class A {
public:
int a;
A(void);
~A(void);
}
...
and we observe that the destructor is printed differently.
There's a difference in debug info between the two cases: in the clang case,
there's one artificial parameter, but in the g++ case, there are two, and
these similar cases are handled differently in cp_type_print_method_args.
This is due to this slightly convoluted bit of code:
...
i = staticp ? 0 : 1;
if (nargs > i)
{
while (i < nargs)
...
}
else if (varargs)
gdb_printf (stream, "...");
else if (language == language_cplus)
gdb_printf (stream, "void");
...
The purpose of "i = staticp ? 0 : 1" is to skip the printing of the implicit
this parameter.
In commit 5f4d1085085 ("c++/8218: Destructors w/arguments"), skipping of other
artificial parameters was added, but using a different method: rather than
adjusting the potential loop start, it skips the parameter in the loop.
The observed difference in printing is explained by whether we enter the loop:
- in the clang case, the loop is not entered and we print "void".
- in the gcc case, the loop is entered, and nothing is printed.
Fix this by rewriting the code to:
- always enter the loop
- handle whether arguments need printing in the loop
- keep track of how many arguments are printed, and
use that after the loop to print void etc.
such that we have the same for both gcc and clang:
...
A(void);
~A(void);
...
Note that I consider the discussion of whether we want to print:
- A(void) / ~A(void), or
- A() / ~A()
out-of-scope for this patch.
Tested on x86_64-linux.
|
|
This patch adds the needed define ASM_REG for PowerPC.
The patch was run on a Power 10 system. The gdb Summary for the run lists
2 expected passes, no unexpected failures or untested testcases.
Please let me know if this patch is acceptable for mainline.
Carl Love
|
|
When running the test-case included with this patch, we run into:
...
(gdb) print ptm^M
$1 = gdb/gdbtypes.h:695: internal-error: loc_bitpos: \
Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.^M
...
while printing a c++ pointer-to-member.
Fix this by skipping static fields in cp_find_class_member, such that we have:
...
(gdb) print ptm^M
$1 = &A::i^M
...
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29294
|
|
When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
only tested objects allocated on the stack. This commit adds a couple of
dynamic allocations and tests if GDB can stop in it as well.
|
|
It is not necessary to call get_compiler_info before calling
test_compiler_info, and, after recent commits that removed setting up
the gcc_compiled, true, and false globals from get_compiler_info,
there is now no longer any need for any test script to call
get_compiler_info directly.
As a result every call to get_compiler_info outside of lib/gdb.exp is
redundant, and this commit removes them all.
There should be no change in what is tested after this commit.
|
|
Currently, breakpoint locations that are enabled while their parent
breakpoint is disabled are displayed with "y" in the Enb colum of
"info breakpoints":
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep n <MULTIPLE>
1.1 y 0x00000000000011b6 in ...
1.2 y 0x00000000000011c2 in ...
1.3 n 0x00000000000011ce in ...
Such locations won't trigger a break, so to avoid confusion, show "y-"
instead. For example:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep n <MULTIPLE>
1.1 y- 0x00000000000011b6 in ...
1.2 y- 0x00000000000011c2 in ...
1.3 n 0x00000000000011ce in ...
The "-" sign is inspired on how the TUI represents breakpoints on the
left side of the source window, with "b-" for a disabled breakpoint.
Change-Id: I9952313743c51bf21b4b380c72360ef7d4396a09
|
|
The previous patch to add -prompt/-lbl to gdb_test introduced a
regression: Before, you could specify an explicit empty message to
indicate you didn't want to PASS, like so:
gdb_test COMMAND PATTERN ""
After said patch, gdb_test no longer distinguishes
no-message-specified vs empty-message, so tests that previously would
be silent on PASS, now started emitting PASS messages based on
COMMAND. This in turn introduced a number of PATH/DUPLICATE
violations in the testsuite.
This commit fixes all the regressions I could see.
This patch uses the new -nopass feature introduced in the previous
commit, but tries to avoid it if possible. Most of the patch fixes
DUPLICATE issues the usual way, of using with_test_prefix or explicit
unique messages.
See previous commit's log for more info.
In addition to looking for DUPLICATEs, I also looked for cases where
we would now end up with an empty message in gdb.sum, due to a
gdb_test being passed both no message and empty command. E.g., this
in gdb.ada/bp_reset.exp:
gdb_run_cmd
gdb_test "" "Breakpoint $decimal, foo\\.nested_sub \\(\\).*"
was resulting in this in gdb.sum:
PASS: gdb.ada/bp_reset.exp:
I fixed such cases by passing an explicit message. We may want to
make such cases error out.
Tested on x86_64 GNU/Linux, native and native-extended-gdbserver. I
see zero PATH cases now. I get zero DUPLICATEs with native testing
now. I still see some DUPLICATEs with native-extended-gdbserver, but
those were preexisting, unrelated to the gdb_test change.
Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
|
|
To look for code paths that lead to create_breakpoints_sal creating
multiple breakpoints, I ran the whole testsuite with this hack:
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -8377,8 +8377,7 @@ create_breakpoints_sal (struct gdbarch *gdbarch,
int from_tty,
int enabled, int internal, unsigned flags)
{
- if (canonical->pre_expanded)
- gdb_assert (canonical->lsals.size () == 1);
+ gdb_assert (canonical->lsals.size () == 1);
surprisingly, the assert never failed...
The way to get to create_breakpoints_sal with multiple lsals is to use
"set multiple-symbols ask" and then select multiple options from the
menu, like so:
(gdb) set multiple-symbols ask
(gdb) b overload1arg
[0] cancel
[1] all
[2] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg()
[3] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(char)
[4] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(double)
[5] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(float)
[6] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(int)
[7] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(long)
[8] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(short)
[9] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(signed char)
[10] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned char)
[11] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned int)
[12] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned long)
[13] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned short)
> 2-3
Breakpoint 2 at 0x1532: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 107.
Breakpoint 3 at 0x154b: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 110.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
... which would trigger the assert.
This commit makes gdb.cp/ovldbreak.exp test this scenario. It does
that by making set_bp_overloaded take a list of expected created
breakpoints rather than just one breakpoint. It converts the
procedure to use gdb_test_multiple instead of send_gdb/gdb_expect
along the way.
Change-Id: Id87d1e08feb6670440d926f5344e5081f5e37c8e
|
|
Many test cases had a few lines in the beginning that look like:
if { condition } {
continue
}
Where conditions varied, but were mostly in the form of ![runto_main] or
[skip_*_tests], making it quite clear that this code block was supposed
to finish the test if it entered the code block. This generates TCL
errors, as most of these tests are not inside loops. All cases on which
this was an obvious mistake are changed in this patch.
|
|
When running test-case gdb.cp/break-f-std-string.exp on openSUSE Leap 15.3
with system gcc 7.5.0, I run into:
...
(gdb) whatis /r std::string^M
No symbol "string" in namespace "std".^M
(gdb) FAIL: gdb.cp/break-f-std-string.exp: _GLIBCXX_USE_CXX11_ABI=1: \
whatis /r std::string
...
The same for gcc 8.2.1, but it passes with gcc 9.3.1.
At source level (as we can observe in the .ii file with -save-temps) we have
indeed:
...
namespace std {
namespace __cxx11 {
typedef basic_string<char> string;
}
}
...
while with gcc 9.3.1, we have instead:
...
namespace std {
namespace __cxx11 {
...
}
typedef basic_string<char> string;
}
...
due to gcc commit 33b43b0d8cd ("Define std::string and related typedefs
outside __cxx11 namespace").
Fix this by adding the missing typedef for gcc version 5 (the first version to
have the dual abi) to 8 (the last version missing aforementioned gcc commit).
Tested on x86_64-linux, with:
- system gcc 7.5.0
- gcc 4.8.5, 8.2.1, 9.3.1, 10.3.0, 11.2.1
- clang 8.0.1, 12.0.1
|
|
If you try to set a breakpoint at a function such as "b
f(std::string)", and the current language is C, the breakpoint fails
to be set, like so:
(gdb) set language c
break f(std::string)
Function "f(std::string)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)
The problem is that the code in GDB that expands the std::string
typedef hits this in c-typeprint.c:
/* If we have "typedef struct foo {. . .} bar;" do we want to
print it as "struct foo" or as "bar"? Pick the latter for
C++, because C++ folk tend to expect things like "class5
*foo" rather than "struct class5 *foo". We rather
arbitrarily choose to make language_minimal work in a C-like
way. */
if (language == language_c || language == language_minimal)
{
if (type->code () == TYPE_CODE_UNION)
gdb_printf (stream, "union ");
else if (type->code () == TYPE_CODE_STRUCT)
{
if (type->is_declared_class ())
gdb_printf (stream, "class ");
else
gdb_printf (stream, "struct ");
}
else if (type->code () == TYPE_CODE_ENUM)
gdb_printf (stream, "enum ");
}
I.e., std::string is expanded to "class std::..." instead of just
"std::...", and then the "f(class std::..." symbol doesn't exist.
Fix this by making cp-support.c:inspect_type print the expanded
typedef type using the language of the symbol whose type we're
expanding the typedefs for -- in the example in question, the
"std::string" typedef symbol, which is a C++ symbol.
Use type_print_raw_options as it seems to me that in this scenario we
always want raw types, to match the real symbol names.
Adjust the gdb.cp/break-f-std-string.exp testcase to try setting a
breakpoint at "f(std::string)" in both C and C++.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
|
Currently, on any remotely modern GNU/Linux system,
gdb.cp/no-dmgl-verbose.exp fails like so:
break 'f(std::string)'
Function "f(std::string)" not defined.
(gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)'
break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
Function "f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)" not defined.
(gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined
This testcase was added back in 2011, here:
[patch] Remove DMGL_VERBOSE
https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html
Back then, the testcase would pass cleanly. It turns out that the
reason it fails today is that the testcase is exercising something in
GDB that only makes sense if the program is built for the pre-C++11
libstc++ ABI. Back then the C++11 ABI didn't exist yet, but nowadays,
you need to compile with -D_GLIBCXX_USE_CXX11_ABI=0 to use the old
ABI. See "Dual ABI" in the libstdc++ manual, at
<https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>.
If we tweak the gdb.cp/no-dmgl-verbose.exp testcase to force the old
ABI with -D_GLIBCXX_USE_CXX11_ABI=0, then it passes cleanly.
So why is it that setting a breakpoint at "f(std::string)" fails with
modern ABI, but passes with old ABI?
This is where libiberty demangler's DMGL_VERBOSE option comes in. The
Itanium ABI mangling scheme has a shorthand form for std::string (and
some other types). See
<https://itanium-cxx-abi.github.io/cxx-abi/abi.html>:
"In addition, the following catalog of abbreviations of the form "Sx" are used:
<substitution> ::= St # ::std::
<substitution> ::= Sa # ::std::allocator
<substitution> ::= Sb # ::std::basic_string
<substitution> ::= Ss # ::std::basic_string < char,
::std::char_traits<char>,
::std::allocator<char> >
<substitution> ::= Si # ::std::basic_istream<char, std::char_traits<char> >
<substitution> ::= So # ::std::basic_ostream<char, std::char_traits<char> >
<substitution> ::= Sd # ::std::basic_iostream<char, std::char_traits<char> >
"
When the libiberty demangler encounters such a abbreviation, by
default, it expands it to the user-friendly typedef "std::string",
"std::iostream", etc.. If OTOH DMGL_VERBOSE is specified, the
abbreviation is expanded to the underlying, non-typedefed fullname
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
etc. as documented in the Itanium ABI, and pasted above. You can see
the standard abbreviations/substitutions in
libiberty/cp-demangle.c:standard_subs.
Back before Jan's patch in 2011, there were parts of GDB that used
DMGL_VERBOSE, and others that did not, leading to mismatches. The
solution back then was to stop using DMGL_VERBOSE throughout.
GDB has code in place to let users set a breakpoint at a function with
typedefs in its parameters, like "b f(uint32_t)". Demangled function
names as they appear in the symbol tables almost (more on this is in a
bit) never have typedefs in them, so when processing "b f(uint32_t)"
GDB first replaces "uint32_t" for its underlying type, and then sets a
breakpoint on the resulting prototype, in this case "f(unsigned int)".
Now, if DMGL_VERBOSE is _not_ used, then the demangler demangles the
mangled name of a function such as "void f(std::string)" that was
mangled using the standard abbreviations mentioned above really as:
"void f(std::string)".
For example, the mangled name of "void f(std::string)" if you compile
with old pre-C++11 ABI is "_Z1fSs". That uses the abbreviation "Ss",
so if you demangle that without DMGL_VERBOSE, you get:
$ echo "_Z1fSs" | c++filt --no-verbose
f(std::string)
while with DMGL_VERBOSE you'd get:
$ echo "_Z1fSs" | c++filt
f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)
If, when the user sets a breakpoint at "f(std::string)", GDB would
replace the std::string typedef for its underlying type using the same
mechanism I mentioned for the "f(uint32_t)" example above, then GDB
would really try to set a breakpoint at "f(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >)", and that would fail,
as the function symbol GDB knows about for that function, given no
DMGL_VERBOSE, is "f(std::string)".
For this reason, the code that expands typedefs in function parameter
names has an exception for std::string (and other standard
abbreviation types), such that "std::string" is never
typedef-expanded.
And here lies the problem when you try to do "b f(std::string)" with a
program compiled with the C++11 ABI. In that case, std::string
expands to a different underlying type, like so:
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
and this symbol naturally mangles differently, as:
_Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
and then because this doesn't use the shorthand mangling abbreviation
for "std::string" anymore, it always demangles as:
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
Now, when using the C++11 ABI, and you set a breakpoint at
"f(std::string)", GDB's typedefs-in-parameters expansion code hits the
exception for "std::string" and doesn't expand it, so the breakpoint
fails to be inserted, because the symbol that exists is really the
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
one, not "f(std::string)".
So to fix things for C++11 ABI, clearly we need to remove the
"std::string" exception from the typedef-in-parameters expansion
logic. If we do just that, then "b f(std::string)" starts working
with the C++11 ABI.
However, if we do _just_ that, and nothing else, then we break
pre-C++11 ABI...
The solution is then to in addition switch GDB to always use
DMGL_VERBOSE. If we do this, then pre-C++11 ABI symbols works the
same as C++11 ABI symbols overall -- the demangler expands the
standard abbreviation for "std::string" as "std::basic_string<char,
std::char_traits<char>, std::allocator<char> >" and letting GDB expand
the "std::string" typedef (etc.) too is no longer a problem.
To avoid getting in the situation where some parts of GDB use
DMGL_VERBOSE and others not, this patch adds wrappers around the
demangler's entry points that GDB uses, and makes those force
DMGL_VERBOSE.
The point of the gdb.cp/no-dmgl-verbose.exp testcase was to try to
ensure that DMGL_VERBOSE doesn't creep back in:
gdb_test {break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'} \
{Function ".*" not defined\.} \
"DMGL_VERBOSE-demangled f(std::string) is not defined"
This obviously no longer makes sense to have, since we now depend on
DMGL_VERBOSE. So the patch replaces gdb.cp/no-dmgl-verbose.exp with a
new gdb.cp/break-f-std-string.exp testcase whose purpose is to make
sure that setting a breakpoint at "f(std::string)" works. It
exercises both pre-C++11 ABI and C++11 ABI.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
|
When running test-case gdb.cp/casts.exp with target board unix/-m32, I run
into:
...
(gdb) print (unsigned long long) &gd == gd_value^M
$31 = false^M
(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
...
With some additional printing, we can see in more detail why the comparison
fails:
...
(gdb) print /x &gd^M
$31 = 0xffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x &gd
print /x (unsigned long long)&gd^M
$32 = 0xffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x (unsigned long long)&gd
print /x gd_value^M
$33 = 0xffffffffffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x gd_value
print (unsigned long long) &gd == gd_value^M
$34 = false^M
(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
...
The gd_value is set by this assignment:
...
unsigned long long gd_value = (unsigned long long) &gd;
...
The problem here is directly casting from a pointer to a non-pointer-sized
integer.
Fix this by adding an intermediate cast to std::uintptr_t.
Tested on x86_64-linux with native and target board unix/-m32.
|
|
Starting with gcc 12.1 / gcc 11.3, for test-case gdb.cp/align.exp we run into:
...
align.cc:29:23: error: invalid application of 'alignof' to a void type^M
29 | unsigned a_void = alignof (void);^M
| ^~~~~~~~~~~~~~^M
...
Fix this by using __alignof__ instead.
Tested on x86_64-linux, with gcc 7.5.0, gcc 12.1 and clang 12.0.1.
|
|
PR c++/28907 points out that casting from a derived class to a base
class fails in some situations. The problem turned out to be a
missing use of value_embedded_offset. One peculiarity here is that,
if you managed to construct a pointer-to-derived with an embedded
offset of 0, the cast would work -- for example, one of the two new
tests here passes without the patch.
This embedded offset stuff is an endless source of bugs. I wonder if
it's possible to get rid of it somehow.
Regression tested on x86-64 Fedora 34.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28907
|
|
GDB prints the wrong type for typedefs in case there is another typedef
available for the same raw type (gdb/16040). The reason is that the
current hashmap based substitution mechanism always compares the target
type of a typedef and not its scoped name.
The original output of GDB for a program like
~~~~
namespace ns
{
typedef double scoped_double;
}
typedef double global_double;
class TypedefHolder
{
public:
double a;
ns::scoped_double b;
global_double c;
private:
typedef double class_double;
class_double d;
double method1(ns::scoped_double) { return 24.0; }
double method2(global_double) { return 24.0; }
};
int main()
{
TypedefHolder th;
return 0;
}
~~~~
is
~~~~
(gdb) b 27
Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27.
(gdb) r
Starting program: /tmp/typedefholder
Breakpoint 1, main () at TypedefHolder.cc:27
27 return 0;
(gdb) ptype th
type = class TypedefHolder {
public:
class_double a;
class_double b;
class_double c;
private:
class_double d;
class_double method1(class_double);
class_double method2(class_double);
typedef double class_double;
}
~~~~
Basically all attributes of a class which have the raw type "double" are
substituted by "class_double".
With the patch the output is the following
~~~~
type = class TypedefHolder {
public:
double a;
ns::scoped_double b;
global_double c;
private:
class_double d;
double method1(ns::scoped_double);
double method2(global_double);
typedef double class_double;
}
~~~~
|
|
This patch adds support for wild template parameter list matches, similar
to how ABI tags or function overloads are now handled.
With this patch, users will be able to "gloss over" the details of matching
template parameter lists. This is accomplished by adding (yet more) logic
to strncmp_iw_with_mode to skip parameter lists if none is explicitly given
by the user.
Here's a simple example using gdb.linespec/cpls-ops.exp:
Before
------
(gdb) ptype test_op_call
type = struct test_op_call {
public:
void operator()(void);
void operator()(int);
void operator()(long);
void operator()<int>(int *);
}
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations)
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x400583 in test_op_call::operator()(int)
at cpls-ops.cc:43
1.2 y 0x40058e in test_op_call::operator()()
at cpls-ops.cc:47
1.3 y 0x40059e in test_op_call::operator()(long)
at cpls-ops.cc:51
The breakpoint at test_op_call::operator()<int> was never set.
After
-----
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations)
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x400583 in test_op_call::operator()(int)
at cpls-ops.cc:43
1.2 y 0x40058e in test_op_call::operator()()
at cpls-ops.cc:47
1.3 y 0x40059e in test_op_call::operator()(long)
at cpls-ops.cc:51
1.4 y 0x4008d0 in test_op_call::operator()<int>(int*)
at cpls-ops.cc:57
Similar to how scope lookups work, passing "-qualified" to the break command
will cause a literal lookup of the symbol. In the example immediately above,
this will cause GDB to only find the three non-template functions.
|
|
PR c++/28901 points out a bug in C++ overload resolution. When
comparing two overloads, one might be better than the other for
certain parameters -- but, if that one also has some invalid
conversion, then it should never be considered the better choice.
Instead, a valid-but-not-apparently-quite-as-good overload should be
preferred.
This patch fixes this problem by changing how overload comparisons are
done. I don't believe it should affect any currently valid overload
resolution; nor should it affect resolutions where all the choices are
equally invalid.
|
|
Add `set print array-indexes' tests for C/C++ arrays, complementing one
for Fortran arrays.
|
|
Add `set print repeats' tests for C/C++ arrays, complementing one for
Fortran arrays and covering the different interpretation of the `set
print elements' setting in particular where the per-dimension count of
the elements handled is matched against the trigger rather than the
total element count as with Fortran arrays.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
Fixes PR gdb/28681. It was observed that after using the `finish`
command an incorrect value was displayed in some cases. Specifically,
this behaviour was observed on an x86-64 target.
Consider this test program:
struct A
{
int i;
A ()
{ this->i = 0; }
A (const A& a)
{ this->i = a.i; }
};
A
func (int i)
{
A a;
a.i = i;
return a;
}
int
main ()
{
A a = func (3);
return a.i;
}
And this GDB session:
$ gdb -q ex.x
Reading symbols from ex.x...
(gdb) b func
Breakpoint 1 at 0x401115: file ex.cc, line 14.
(gdb) r
Starting program: /home/andrew/tmp/ex.x
Breakpoint 1, func (i=3) at ex.cc:14
14 A a;
(gdb) finish
Run till exit from #0 func (i=3) at ex.cc:14
main () at ex.cc:23
23 return a.i;
Value returned is $1 = {
i = -19044
}
(gdb) p a
$2 = {
i = 3
}
(gdb)
Notice how after the `finish` the contents of $1 are junk, but, when I
immediately ask for the value of `a`, I get back the correct value.
The problem here is that after the finish command GDB calls the
function amd64_return_value to figure out where the return value can
be found (on x86-64 targets anyway).
This function makes the wrong choice for the struct A in our case, as
sizeof(A) <= 8, then amd64_return_value decides that A will be
returned in a register. GDB then reads the return value register an
interprets the contents as an instance of A.
Unfortunately, A is not trivially copyable (due to its copy
constructor), and the sys-v specification for argument and return
value passing, says that any non-trivial C++ object should have space
allocated for it by the caller, and the address of this space is
passed to the callee as a hidden first argument. The callee should
then return the address of this space as the return value.
And so, the register that GDB is treating as containing an instance of
A, actually contains the address of an instance of A (in this case on
the stack), this is why GDB shows the incorrect result.
The call stack within GDB for where we actually go wrong is this:
amd64_return_value
amd64_classify
amd64_classify_aggregate
And it is in amd64_classify_aggregate that we should be classifying
the type as AMD64_MEMORY, instead of as AMD64_INTEGER as we currently
do (via a call to amd64_classify_aggregate_field).
At the top of amd64_classify_aggregate we already have this logic:
if (TYPE_LENGTH (type) > 16 || amd64_has_unaligned_fields (type))
{
theclass[0] = theclass[1] = AMD64_MEMORY;
return;
}
Which handles some easy cases where we know a struct will be placed
into memory, that is (a) the struct is more than 16-bytes in size,
or (b) the struct has any unaligned fields.
All we need then, is to add a check here to see if the struct is
trivially copyable. If it is not then we know the struct will be
passed in memory.
I originally structured the code like this:
if (TYPE_LENGTH (type) > 16
|| amd64_has_unaligned_fields (type)
|| !language_pass_by_reference (type).trivially_copyable)
{
theclass[0] = theclass[1] = AMD64_MEMORY;
return;
}
This solved the example from the bug, and my small example above. So
then I started adding some more extensive tests to the GDB testsuite,
and I ran into a problem. I hit this error:
gdbtypes.h:676: internal-error: loc_bitpos: Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.
This problem is triggered from:
amd64_classify_aggregate
amd64_has_unaligned_fields
field::loc_bitpos
Inside the unaligned field check we try to get the bit position of
each field. Unfortunately, in some cases the field location is not
FIELD_LOC_KIND_BITPOS, but is FIELD_LOC_KIND_DWARF_BLOCK.
An example that shows this bug is:
struct B
{
short j;
};
struct A : virtual public B
{
short i;
A ()
{ this->i = 0; }
A (const A& a)
{ this->i = a.i; }
};
A
func (int i)
{
A a;
a.i = i;
return a;
}
int
main ()
{
A a = func (3);
return a.i;
}
It is the virtual base class, B, that causes the problem. The base
class is represented, within GDB, as a field within A. However, the
location type for this field is a DWARF_BLOCK.
I spent a little time trying to figure out how to convert the
DWARF_BLOCK to a BITPOS, however, I realised that, in this case at
least, conversion is not needed.
The C++ standard says that a class is not trivially copyable if it has
any virtual base classes. And so, in this case, even if I could
figure out the BITPOS for the virtual base class fields, I know for
sure that I would immediately fail the trivially_copyable check. So,
lets just reorder the checks in amd64_classify_aggregate to:
if (TYPE_LENGTH (type) > 16
|| !language_pass_by_reference (type).trivially_copyable
|| amd64_has_unaligned_fields (type))
{
theclass[0] = theclass[1] = AMD64_MEMORY;
return;
}
Now, if we have a class with virtual bases we will fail quicker, and
avoid the unaligned fields check completely.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28681
|
|
Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's
debugformat field") changes the debug format string in "info source" to
show the actual DWARF version, rather than always show "DWARF 2".
However, it failed to consider that some tests checked for the "DWARF 2"
string to see if the test program is compiled with DWARF debug
information. Since everything is compiled with DWARF 4 or 5 nowadays,
that changed the behavior of those tests. Notably, it prevent the
tests using skip_inline_var_tests to run.
Grep through the testsuite for "DWARF 2" and change all occurrences I
could find to use "DWARF [0-9]" instead (that string is passed to TCL's
string match).
Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885
|
|
Basic ambiguity detection assumes that when 2 fields with the same name
have the same byte offset, it must be an unambiguous request. This is not
always correct. Consider the following code:
class empty { };
class A {
public:
[[no_unique_address]] empty e;
};
class B {
public:
int e;
};
class C: public A, public B { };
if we tried to use c.e in code, the compiler would warn of an ambiguity,
however, since A::e does not demand an unique address, it gets the same
address (and thus byte offset) of the members, making A::e and B::e have the
same address. however, "print c.e" would fail to report the ambiguity,
and would instead print it as an empty class (first path found).
The new code solves this by checking for other found_fields that have
different m_struct_path.back() (final class that the member was found
in), despite having the same byte offset.
The testcase gdb.cp/ambiguous.exp was also changed to test for this
behavior.
|
|
This commit supplements whatis and ptype command tests for print of
const-volatile qualifiers.
gdb/testsuite/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb.cp/ptype-cv-cp.cc: New const and volatile typedef
variables.
* gdb.cp/ptype-cv-cp.exp: Add new tests.
|
|
Make ptype print const/volatile qualifiers when template or typedef
attributes are substituted.
For a programm like
~~~
template<typename DataT>
class Cfoo
{
typedef float myfloat;
public:
DataT me0;
const DataT me1=1;
const myfloat me2=2.0;
};
int main()
{
Cfoo<int> cfoo;
return 0;
}
~~~
gdb outputs the following type for cfoo's attributes:
~~~
(gdb) b 14
Breakpoint 1 at 0x1170: file tmp.cc, line 14.
(gdb) run
Starting program: /tmp
Breakpoint 1, main () at tmp.cc:14
14 return 0;
(gdb) ptype cfoo
type = class Cfoo<int> [with DataT = int] {
public:
DataT me0;
DataT me1;
myfloat me2;
private:
typedef float myfloat;
}
~~~
The cv qualifiers (const in this case) are ignored for me1 and me2.
After:
~~~
(gdb) ptype cfoo
type = class Cfoo<int> [with DataT = int] {
public:
DataT me0;
const DataT me1;
const myfloat me2;
private:
typedef float myfloat;
}
~~~
gdb/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb/c-typeprint.c: Print cv qualifiers in case of parameter
substitution.
gdb/testsuite/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb.cp/templates.cc: New template class Cfoo with const,
template, typdef and integer attributes.
* gdb.cp/templates.exp: Add new test using ptype and ptype/r
commmands for template class CFoo.
|
|
Replaces a hard coded line number with a use of gdb_get_line_number.
I suspect that the line number has, over time, come adrift from where
it was supposed to be stopping. When the test was first added, line
770 pointed at the final 'return 0' in function main. Over time, as
things have been added, line 770 now points at some random location in
the middle of main.
So, I've marked the 'return 0' with a comment, and now the test will
always stop there.
I also removed an old comment from 1997 talking about how these tests
will only pass with the HP compiler, followed by an additional comment
from 2000 saying that the tests now pass with GCC.
I get the same results before and after this change.
|
|
GDB test fails while running the test case gdb.cp/koenig.exp using
clang compiler:
[...]
p foo (p_union)
No symbol "p_union" in current context.
(gdb) FAIL: gdb.cp/koenig.exp: p foo (p_union)
[...]
In the testcase, "p_union" is an unused/uninitialized variable of
anonymous union type. Clang does not emit symbol for unused anonymous
union/struct variables at any optimization level. Since the compiler
itself is not emitting the symbol for "p_union", debug info is also
not emitted when built with debug option. If the anonymous union is
initialized (or used), then clang emits the symbol "p_union" which
enables emitting debug info for "p_union".
[...]
p foo (p_union)
Cannot resolve function foo to any overloaded instance
(gdb) PASS: gdb.cp/koenig.exp: p foo (p_union)
[...]
|
|
The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line. To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.
On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.
|
|
As follow-up to this discussion:
https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html
... make runto_main not pass no-message to runto. This means that if we
fail to run to main, for some reason, we'll emit a FAIL. This is the
behavior we want the majority of (if not all) the time.
Without this, we rely on tests logging a failure if runto_main fails,
otherwise. They do so in a very inconsisteny mannet, sometimes using
"fail", "unsupported" or "untested". The messages also vary widly.
This patch removes all these messages as well.
Also, remove a few "fail" where we call runto (and not runto_main). by
default (without an explicit no-message argument), runto prints a
failure already. In two places, gdb.multi/multi-re-run.exp and
gdb.python/py-pp-registration.exp, remove "message" passed to runto.
This removes a few PASSes that we don't care about (but FAILs will still
be printed if we fail to run to where we want to). This aligns their
behavior with the rest of the testsuite.
Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
|
|
Minimize gdb restarts, applying the following rules:
- don't use prepare_for_testing unless necessary
- don't use clean_restart unless necessary
Also, if possible, replace build_for_executable + clean_restart
with prepare_for_testing for brevity.
Touches 68 test-cases.
Tested on x86_64-linux.
|
|
Please consider below testcase with intended error.
``````````
constexpr const char cstring[] = "Eta";
template <const char*, typename T> class Column {};
using quick = Column<cstring,double>; // cstring without '&'
void lookup() {
quick c1;
c1.ls();
}
``````````
It produces below error.
``````````
no member named 'ls' in 'Column<&cstring, double>'.
``````````
Please note that error message contains '&' for cstring, which is absent
in actual program.
Clang++ does not generate & in such cases and this should also be
accepted as correct output.
gdb/testsuite/ChangeLog:
* gdb.cp/templates.exp: Accept different but correct output
from the Clang++ compiled binary also.
|
