| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add a new command to flush the dcache.
gdb/ChangeLog:
* NEWS: Mention new commands.
* target-dcache.c: Add 'cli/cli-cmds.h' include.
(maint_flush_dcache_command): New function.
(_initialize_target_dcache): Create new 'maint flush dcache'
command.
gdb/doc/ChangeLog:
* gdb.texinfo (Caching Target Data): Document 'maint flush
dcache'.
gdb/testsuite/ChangeLog:
* gdb.base/dcache-flush.c: New file.
* gdb.base/dcache-flush.exp: New file.
|
|
We currently have two flushing commands 'flushregs' and 'maint
flush-symbol-cache'. I'm planning to add at least one more so I
thought it might be nice if we bundled these together into one place.
And so I created the 'maint flush ' command prefix. Currently there
are two commands:
(gdb) maint flush symbol-cache
(gdb) maint flush register-cache
Unfortunately, even though both of the existing flush commands are
maintenance commands, I don't know how keen we about deleting existing
commands for fear of breaking things in the wild. So, both of the
existing flush commands 'maint flush-symbol-cache' and 'flushregs' are
still around as deprecated aliases to the new commands.
I've updated the testsuite to use the new command syntax, and updated
the documentation too.
gdb/ChangeLog:
* NEWS: Mention new commands, and that the old commands are now
deprecated.
* cli/cli-cmds.c (maintenanceflushlist): Define.
* cli/cli-cmds.h (maintenanceflushlist): Declare.
* maint.c (_initialize_maint_cmds): Initialise
maintenanceflushlist.
* regcache.c: Add 'cli/cli-cmds.h' include.
(reg_flush_command): Add header comment.
(_initialize_regcache): Create new 'maint flush register-cache'
command, make 'flushregs' an alias.
* symtab.c: Add 'cli/cli-cmds.h' include.
(_initialize_symtab): Create new 'maint flush symbol-cache'
command, make old command an alias.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document 'maint flush symbol-cache'.
(Maintenance Commands): Document 'maint flush register-cache'.
gdb/testsuite/ChangeLog:
* gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...'
commands.
* gdb.base/killed-outside.exp: Likewise.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.perf/gmonster-null-lookup.py: Likewise.
* gdb.perf/gmonster-print-cerr.py: Likewise.
* gdb.perf/gmonster-ptype-string.py: Likewise.
* gdb.python/py-unwind.exp: Likewise.
|
|
Consider this GDB session:
(gdb) define set xxx_yyy
Type commands for definition of "set xxx_yyy".
End with a line saying just "end".
>echo in set xxx_yyy command\n
>end
(gdb) alias set qqq_aaa=set xxx_yyy
(gdb) maintenance deprecate set qqq_aaa
(gdb) set qqq_aaa
Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
No alternative known.
in set xxx_yyy command
(gdb)
Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong. I think the proper warning should read:
(gdb) set qqq_aaa
Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy', is deprecated.
No alternative known.
With the 'set' prefixes added and a comma before the final 'is
deprecated'. That is what this patch does. The expected results are
updated as needed.
gdb/ChangeLog:
* cli/cli-decode.c (deprecated_cmd_warning): Ignore the prefix
result from lookup_cmd_composition_1, use the prefixes from both
the command and the alias instead.
(lookup_cmd_composition_1): Initial prefix command is the based on
the search list being passed in. Simplify the logic for tracking
the prefix command. Replace a use of alloca with a local
std::string.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp: Update expected results.
|
|
I noticed that deprecated aliases that have a prefix don't give a
deprecated command warning. For example looking in mi/mi-main.c we
see this:
c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &setlist);
deprecate_cmd (c, "set mi-async");
c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &showlist);
deprecate_cmd (c, "show mi-async");
So both 'set target-async' and 'show target-async' are deprecated and
should be giving a warning, however, in use we see no warning given.
This is a consequence of how the code that should give this
warning (deprecated_cmd_warning) performs a second command lookup in
order to distinguish between aliases and real commands, and that the
code that calls this (lookup_cmd_1) strips off prefix commands as it
calls itself recursively.
As a result when we are considering an alias like 'set target-async'
we first enter lookup_cmd_1 with text = "set target-async", we spot
the 'set' command prefix and then recursively call lookup_cmd_1 with
text = "target-async".
We spot that 'target-async' is a known alias but that it is
deprecated, and so call deprecated_cmd_warning passing in the value of
text, which remember is now "target-async".
In deprecated_cmd_warning we again perform a command lookup starting
from the top-level cmdlist, but now we're trying to find just
"target-async", this fails (as this command requires the 'set' prefix,
and so no warning is given.
I resolved this issue by passing a command list to the function
deprecated_cmd_warning, this is the list in which the command can be
found.
A new test is added to cover this case.
However, there is an additional problem which will be addressed in a
subsequent patch.
Consider this GDB session:
(gdb) define set xxx_yyy
Type commands for definition of "set xxx_yyy".
End with a line saying just "end".
>echo in set xxx_yyy command\n
>end
(gdb) alias set qqq_aaa=set xxx_yyy
(gdb) maintenance deprecate set qqq_aaa
(gdb) set qqq_aaa
Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
No alternative known.
in set xxx_yyy command
(gdb)
Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong. I think the proper warning should read:
(gdb) set qqq_aaa
Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy' is deprecated.
No alternative known.
With the 'set' prefixes added. A later patch will resolve this
issue.
gdb/ChangeLog:
PR cli/15104
* cli/cli-decode.c (lookup_cmd_1): Pass command list to
deprecated_cmd_warning.
(deprecated_cmd_warning): Take extra parameter, call
lookup_cmd_composition_1 and pass new parameter through.
(lookup_cmd_composition_1): New function, takes implementation of
lookup_cmd_composition but with extra parameter.
(lookup_cmd_composition): Now calls lookup_cmd_composition_1
passing in cmdlist.
* command.h (deprecated_cmd_warning): Add extra parameter to
declaration.
* top.c (execute_command): Pass cmdlist to deprecated_cmd_warning.
gdb/testsuite/ChangeLog:
PR cli/15104
* gdb.base/commands.exp: Add additional tests.
* gdb.base/completion.exp: Add additional tests.
|
|
Consider this gdb session, where on line #3 tab completion is used:
(gdb) alias xxx_yyy_zzz=break
(gdb) maint deprecate xxx_yyy_zzz
(gdb) xxx_yyy_<TAB>
The third line then updates to look like this:
(gdb) xxx_yyy_Warning: 'xxx_yyy_zzz', an alias for the command 'break' is deprecated.
No alternative known.
zzz
What's happened is during tab completion the alias has been resolved
to the actual command being aliased, and at this stage the warning is
issued. Clearly this is not what we want during tab completion.
In this commit I add a new parameter to the lookup function, a boolean
that indicates if the lookup is being done as part of completion.
This flag is used to suppress the warning. Now we get the expected
behaviour, the alias completes without any warning, but the warning is
still given once the user executes the alias.
gdb/ChangeLog:
* cli/cli-decode.c (lookup_cmd_1): Move header comment into
command.h, add extra parameter, and use this to guard giving a
warning.
* command.h (lookup_cmd_1): Add comment from cli/cli-decode.c,
include argument names in declaration, add new argument.
* completer.c (complete_line_internal_1): Remove unneeded
brackets, pass extra argument to lookup_cmd_1.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add additional tests.
|
|
When configuring gdb using --with-mpfr=no and running test-case
gdb.base/float128.exp, we run into:
...
FAIL: gdb.base/float128.exp: print large128 (GDB may be missing MPFR support!)
...
Fix this by detecting that gdb was build without mpfr using the show
configuration command, and changing the FAIL into UNSUPPORTED.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-11 Tom de Vries <tdevries@suse.de>
PR testsuite/26954
* gdb.base/float128.exp: Detect and handle no mpfr support.
|
|
Since commit 7c6f27129631 ("gdb: make get_discrete_bounds check for
non-constant range bounds"), subscripting flexible array member fails:
struct no_size
{
int n;
int items[];
};
(gdb) p *ns
$1 = {n = 3, items = 0x5555555592a4}
(gdb) p ns->items[0]
Cannot access memory at address 0xfffe555b733a0164
(gdb) p *((int *) 0x5555555592a4)
$2 = 101 <--- we would expect that
(gdb) p &ns->items[0]
$3 = (int *) 0xfffe5559ee829a24 <--- wrong address
Since the flexible array member (items) has an unspecified size, the array type
created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0,
Ubuntu 20.04):
0x000000a4: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000038 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000b3)
0x000000ad: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x00000031 "long unsigned int")
This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined
constant low bound (dynamic_prop with kind PROP_CONST) and an undefined
high bound (dynamic_prop with kind PROP_UNDEFINED).
value_subscript gets both bounds of that range using
get_discrete_bounds. Before commit 7c6f27129631, get_discrete_bounds
didn't check the kind of the dynamic_props and would just blindly read
them as if they were PROP_CONST. It would return 0 for the high bound,
because we zero-initialize the range_bounds structure. And it didn't
really matter in this case, because the returned high bound wasn't used
in the end.
Commit 7c6f27129631 changed get_discrete_bounds to return a failure if
either the low or high bound is not a constant, to make sure we don't
read a dynamic prop that isn't a PROP_CONST as a PROP_CONST. This
change made get_discrete_bounds start to return a failure for that
range, and as a result would not set *lowp and *highp. And since
value_subscript doesn't check get_discrete_bounds' return value, it just
carries on an uses an uninitialized value for the low bound. If
value_subscript did check the return value of get_discrete_bounds, we
would get an error message instead of a bogus value. But it would still
be a bug, as we wouldn't be able to print the flexible array member's
elements.
Looking at value_subscript, we see that the low bound is always needed,
but the high bound is only needed if !c_style. So, change
value_subscript to use get_discrete_low_bound and
get_discrete_high_bound separately. This fixes the case described
above, where the low bound is known but the high bound isn't (and is not
needed). This restores the original behavior without accessing a
dynamic_prop in a wrong way.
A test is added. In addition to the case described above, a case with
an array member of size 0 is added, which is a GNU C extension that
existed before flexible array members were introduced. That case
currently fails when compiled with gcc <= 8. gcc <= 8 produces DWARF
similar to the one shown above, while gcc 9 adds a DW_AT_count of 0 in
there, which makes the high bound known. A case where an array member
of size 0 is the only member of the struct is also added, as that was
how PR 28675 was originally reported, and it's an interesting corner
case that I think could trigger other funny bugs.
Question about the implementation: in value_subscript, I made it such
that if the low or high bound is unknown, we fall back to zero. That
effectively makes it the same as it was before 7c6f27129631. But should
we instead error() out?
gdb/ChangeLog:
PR 26875, PR 26901
* gdbtypes.c (get_discrete_low_bound): Make non-static.
(get_discrete_high_bound): Make non-static.
* gdbtypes.h (get_discrete_low_bound): New declaration.
(get_discrete_high_bound): New declaration.
* valarith.c (value_subscript): Only fetch high bound if
necessary.
gdb/testsuite/ChangeLog:
PR 26875, PR 26901
* gdb.base/flexible-array-member.c: New test.
* gdb.base/flexible-array-member.exp: New test.
Change-Id: I832056f80e6c56f621f398b4780d55a3a1e299d7
|
|
Commit:
commit 4d142eaa28c64565b58fcdb5a83377ec9b778cb1
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
AuthorDate: Tue Jul 2 20:06:12 2013 +0000
gdb/testsuite/
* gdb.base/break-on-linker-gcd-function.exp: Replace
prepare_for_testing by build_executable_from_specs and clean_restart.
...
did:
set additional_flags {-ffunction-sections -Wl,--gc-sections}
-if {[prepare_for_testing $testfile.exp $testfile $srcfile \
- [list debug c++ additional_flags=$additional_flags]]} {
+if {[build_executable_from_specs $testfile.exp $testfile \
+ {c++ additional_flags=-Wl,--gc-sections} \
+ $srcfile {debug c++ additional_flags=-ffunction-sections}]} {
and that left the additional_flags variable behind. Remove it.
gdb/testsuite/ChangeLog:
* gdb.base/break-on-linker-gcd-function.exp: Remove unused
'additional_flags' variable.
|
|
Suppose we have the script file below:
break main
commands
print 123
end
run
If started with this script file, GDB executes the breakpoint command:
$ gdb -q -x myscript --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Breakpoint 1, main () at test.c:2
2 return 0;
$1 = 123
(gdb)
However, if we remove the "run" line from the script and pass it with
the '-ex' option instead, the command is not executed:
$ gdb -q -x myscript_no_run --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Starting program: /path/to/test
Breakpoint 1, main () at test.c:2
2 return 0;
(gdb)
If the user enters a command at this point, the breakpoint command
is executed, yielding weird output:
$ gdb -q -x myscript_no_run --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Starting program: /path/to/test
Breakpoint 1, main () at test.c:2
2 return 0;
(gdb) print "a"
$1 = "a"
$2 = 123
When consuming script files, GDB runs bp actions after executing a
command. See `command_handler` in event-top.c:
if (c[0] != '#')
{
execute_command (command, ui->instream == ui->stdin_stream);
/* Do any commands attached to breakpoint we stopped at. */
bpstat_do_actions ();
}
However, for '-ex' commands, `bpstat_do_actions` is not invoked.
Hence, the misaligned output explained above occurs. To fix the
problem, add a call to `bpstat_do_actions` after executing a command.
gdb/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* main.c (catch_command_errors): Add a flag parameter; invoke
`bpstat_do_actions` if the flag is set.
(execute_cmdargs): Update a call to `catch_command_errors`.
gdb/testsuite/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/bp-cmds-run-with-ex.c: New file.
* gdb.base/bp-cmds-run-with-ex.exp: New file.
* gdb.base/bp-cmds-run-with-ex.gdb: New file.
* gdb.gdb/python-interrupts.exp: Update the call to
'catch_command_errors' with the new argument.
* gdb.gdb/python-selftest.exp: Ditto.
|
|
Breakpoint locations are sorted according to their addresses. The
addresses are determined by how the compiler emits the code.
Therefore, we may have a different order of locations depending on the
compiler we use. To make the gdb.base/condbreak-multi-context.exp
test flexible enough for different compilers' output, do not hard-code
location indices.
Tested with GCC and Clang.
gdb/testsuite/ChangeLog:
2020-11-24 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.exp: Do not hard-code location
indices.
|
|
The wiki contains a template for new test cases:
https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Building_the_Example_Program
... which is helpful, because even after many years I can't write all
the boilerplate for writing a test case without doing some mistakes.
However, I think it would be nice to have it in the tree. It's much
faster to cp the files than going to the wiki and copy/pasting the
contents.
As a bonus, the copyright years will get updated in these files, unlike
those in the wiki. So they will always be good when we start a new
test.
If this patch is merged, I plan to change the wiki to just point to
these files.
gdb/testsuite/ChangeLog:
* gdb.base/template.exp: New.
* gdb.base/template.c: New.
Change-Id: I7dbf068a043b48f83cc325087d70e868eee998c6
|
|
When running gdb.base/vla-ptr.exp with clang-10, we run into this FAIL:
...
(gdb) print td_vla^M
$6 = 0x7fffffffd2b0^M
(gdb) FAIL: gdb.base/vla-ptr.exp: print td_vla
...
Clang 10.0.1 generates the following DWARF for td_vla. A variable DIE:
...
<2><19f>: Abbrev Number: 6 (DW_TAG_variable)
<1a0> DW_AT_location : 0x39 (location list)
<1a4> DW_AT_name : td_vla
<1aa> DW_AT_type : <0x1ae>
....
with typedef type:
...
<2><1ae>: Abbrev Number: 7 (DW_TAG_typedef)
<1af> DW_AT_type : <0x1fc>
<1b3> DW_AT_name : typedef_vla
...
pointing to:
...
<1><1fc>: Abbrev Number: 11 (DW_TAG_array_type)
<1fd> DW_AT_type : <0x1d3>
<2><201>: Abbrev Number: 14 (DW_TAG_subrange_type)
<202> DW_AT_type : <0x1f5>
...
The subrange type is missing the count attribute. This was filed as
llvm PR48247 - "vla var with typedef'd type has incomplete debug info".
Mark this as xfail.
gdb/testsuite/ChangeLog:
2020-11-21 Tom de Vries <tdevries@suse.de>
* gdb.base/vla-ptr.exp: Add XFAIL.
|
|
Switch over to using new option processing mechanism for watch,
awatch, and rwatch commands. Add command completion function.
This means that expression completion now works correctly when the
-location flag is used. So previously:
(gdb) watch var.<TAB><TAB>
.... list fields of var ....
But,
(gdb) watch -location var.<TAB><TAB>
.... list all symbols ....
After this commit only the fields of 'var' are listed even when
'-location' is passed.
Another benefit of this change is that '-location' will now complete.
One thing to note is that previous these commands accepted both
'-location' or '-l' (these being synonyms). The new option scheme
doesn't really allow for official short form flags, however, it does
allow for non-ambiguous sub-strings to be used. What this means is
that currently (as these commands only have the '-location' flag) the
user can still use '-l', so there's no change there.
The interactive help text for these commands now emphasises
'-location' as the real option, but does mention that '-l' can also be
used.
gdb/ChangeLog:
* breakpoint.c (struct watch_options): New struct.
(watch_option_defs): New static global.
(make_watch_options_def_group): New function.
(watch_maybe_just_location): Convert option parsing.
(watch_command_completer): New function.
(_initialize_breakpoint): Build help text using options mechanism.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add new completion tests.
|
|
The /FMT specification on the print command currently breaks command
completion, so:
(gdb) p var.<TAB><TAB>
.... list of fields in var .....
But,
(gdb) p/d var.<TAB><TAB>
..... list of all symbols .....
After this commit this issue is now resolved.
There are some other details around tab-completion and /FMT which
hopefully this commit improves. So, before:
(gdb) p/<TAB><TAB>
.... lists all symbols .....
After:
(gdb) p/<TAB><TAB> # Nothing changes...
The thinking here is that after a / the user must type a FMT, but we
don't offer tab completion on FMT characters. Placing a symbol
directly after a / will not do what the user expects, so offering that
seems wrong.
Similarly, before we had:
(gdb) p/d<TAB><TAB>
... lists all symbols starting with 'd' ....
But afterwards:
(gdb) p/d<TAB><TAB> # Adds a single space, so we get:
(gdb) p/d <CURSOR>
As before, typing a symbol where FMT is expected will not do what the
user expects. If the user has added a FMT string then upon tab
completion GDB assumes the FMT string is complete and prepares the
user to type an expression.
In this commit I have also added completion functions for the 'x' and
'display' commands. These commands also support /FMT specifiers and
so share some code with 'print'.
gdb/ChangeLog:
* printcmd.c: Include 'safe-ctype.c'.
(skip_over_slash_fmt): New function.
(print_command_completer): Call skip_over_slash_fmt.
(display_and_x_command_completer): New function.
(_initialize_printcmd): Add command completion for 'x' and
'display'.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add new tests.
|
|
gdb.base/continue-after-aborted-step-over.exp
The test gdb.base/continue-after-aborted-step-over.exp fails on ROCm GDB
[1] when using the unix board (when debugging a standard x86-64/Linux
program), with:
(gdb) b *0^M
Breakpoint 2 at 0x0^M
Warning:^M
Cannot insert breakpoint 2.^M
Cannot access memory at address 0x0^M
^M
(gdb) FAIL: gdb.base/continue-after-aborted-step-over.exp: displaced-stepping=off: b *0
This happens because that build of GDB defaults to "set breakpoint
always-inserted on", for reasons that are unrelevant to explain here.
As soon as the breakpoint is created, GDB tries to insert it and
(expectedly) fails. This causes more text to be output than what the
pattern expects.
It is actually be relevant to run the test with both "set breakpoint
always-inserted" on and off. With it on, it mimics what happens when
running in non-stop mode, with other threads running. This is relevant
for upstream even outside of the ROCm port, so here's a patch for it.
Add this other axis and adjust the "b *0" test to handle the extra
output when it is on.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
gdb/testsuite/ChangeLog:
* gdb.base/continue-after-aborted-step-over.exp: Add "breakpoint
always-inserted" axis.
(do_test): Add breakpoint_always_inserted parameter.
Change-Id: I95126cae563a0b9a72f4a99627809fc34340cd5e
|
|
The "vla_optimized_out" procedure in gdb.base/vla-optimized-out.exp
accepts a "sizeof_result" argument which is substituted into the
regular expression used to check the result of printing the sizeof
a VLA. The -O3 test variants, however, pass a regular expression
fragment as that argument, which expands into a regular expression
that matches any result with a "6" in it. This commit wraps the
substitution with parentheses to prevent these false matches.
gdb/testsuite/ChangeLog:
* gdb.base/vla-optimized-out.exp (p sizeof (a)): Wrap supplied
regexp fragment in parentheses to prevent false matching.
|
|
The function f1 in gdb.base/vla-optimized-out.c sets various
attributes to prevent its being inlined, but Clang inlines it
anyway, causing the test that uses it to fail. This commit
adds the "weak" attribute to cause Clang to keep the function
fully out of line so the test can operate as it should.
gdb/testsuite/ChangeLog:
* gdb.base/vla-optimized-out.c (f1): Add __attribute__ ((weak)).
|
|
In commit:
commit 6d81691950f8c4be4a49a85a672255c140e82468
CommitDate: Sat Sep 19 09:44:58 2020 +0100
gdb/fortran: Move Fortran expression handling into f-lang.c
A bug was introduced that broke GDB's ability to perform debug dumps
of expressions containing function calls. For example this would no
longer work:
(gdb) set debug expression 1
(gdb) print call_me (&val)
Dump of expression @ 0x4eced60, before conversion to prefix form:
Language c, 12 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 OP_M2_STRING 79862864 P...............
2 unknown opcode: 224 79862240 ................
3 OP_VAR_VALUE 40 (...............
4 OP_VAR_VALUE 40 (...............
5 OP_RUST_ARRAY 79861600 `...............
6 UNOP_PREDECREMENT 79861312 @...............
7 OP_VAR_VALUE 40 (...............
8 UNOP_ADDR 61 =...............
9 OP_FUNCALL 46 ................
10 BINOP_ADD 1 ................
11 OP_FUNCALL 46 ................
Dump of expression @ 0x4eced60, after conversion to prefix form:
Expression: `call_me (&main::val, VAL(Aborted (core dumped)
The situation was even worse for Fortran function calls, or array
indexes, which both make use of the same expression opcode.
The problem was that in a couple of places the index into the
expression array was handled incorrectly causing GDB to interpret
elements incorrectly. These issues are fixed in this commit.
There are already some tests to check GDB when 'set debug expression
1' is set, these can be found in gdb.*/debug-expr.exp. Unfortunately
the cases above were not covered.
In this commit I have cleaned up all of the debug-expr.exp files a
little, there was a helper function that had clearly been copied into
each file, this is now moved into lib/gdb.exp.
I've added a gdb.fortran/debug-expr.exp test file, and extended
gdb.base/debug-expr.exp to cover the function call case.
gdb/ChangeLog:
* expprint.c (print_subexp_funcall): Increment expression position
after reading argument count.
* f-lang.c (print_subexp_f): Skip over opcode before calling
common function.
(dump_subexp_body_f): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/debug-expr.c: Add extra function to allow for an
additional test.
* gdb.base/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr. Add an extra test.
* gdb.cp/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr, give the tests names
* gdb.dlang/debug-expr.exp (test_debug_expr): Delete, replace
calls to this proc with gdb_test_debug_expr, give the tests names
* gdb.fortran/debug-expr.exp: New file.
* gdb.fortran/debug-expr.f90: New file.
* lib/gdb.exp (gdb_test_debug_expr): New proc.
|
|
This test fails on my machine:
p /x $pc^M
$2 = 0x55555555514e^M
(gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: get after PC
FAIL: gdb.base/step-over-no-symbols.exp: displaced=off: advanced
This is due to the check added in 5f0e2eb79e6b ("GDB/testsuite: Fix a
catastrophic step-over-no-symbols.exp failure"), that makes sure the PC
values are integer. As documented in the TCL doc [1], "string is
integer" returns 1 if the string is a valid 32-bit integer format. The
PC values are greater than 32 bits, so are not recognized as integers by
that test.
% string is integer -strict 0x55555555
1
% string is integer -strict 0x555555555
0
Replace the "string is integer" test with a regexp one, that verifies
the PC is a hex value.
[1] https://www.tcl.tk/man/tcl/TclCmd/string.htm#M21
gdb/testsuite/ChangeLog:
* gdb.base/step-over-no-symbols.exp (test_step_over): Replace
integer format test with regexp.
Change-Id: I71f8197e7b52e97b4901980544a8d1072aabd362
|
|
The C++ parts of gdb.base/print-file-var.exp failed to build with
Clang because the "-x c++" option added by gdb_compile caused the
compiler to attempt to parse .so files as C++. This commit splits
the compiler and linker options into separate lists, and switches
to building via build_executable_from_specs which can accommodate
this separation.
gdb/testsuite/ChangeLog:
* gdb.base/print-file-var.exp (test): Separate compiler and
linker options, and build using build_executable_from_specs
to accommodate this.
|
|
Clang fails to compile a number of files with the following warning:
unknown attribute 'noclone' ignored [-Wunknown-attributes]. This
commit adds a new header, lib/noclone.h, which defines the macro
ATTRIBUTE_NOCLONE accordingly, and updates the relevant testcases
to use it.
gdb/testsuite/ChangeLog:
* lib/attributes.h: New header.
* gdb.base/backtrace.c: Include the above. Replace
__attribute__(noclone)) with ATTRIBUTE_NOCLONE.
* gdb.base/infcall-nested-structs.c: Likewise.
* gdb.base/vla-optimized-out.c: Likewise.
|
|
Having pagination enabled when handling an inferior event gives the
user an option to quit, which causes early exit in GDB's flow and may
lead to half-baked state. For instance, here is a case where we quit
in the middle of handling an inferior exit:
$ gdb ./a.out
Reading symbols from ./a.out...
(gdb) set height 2
(gdb) run
Starting program: ./a.out
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
Couldn't get registers: No such process.
(gdb) set height unlimited
Couldn't get registers: No such process.
(gdb) info threads
Id Target Id Frame
* 1 process 27098 Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb)
Or suppose having a multi-threaded program like below:
static void *
fun (void *dummy)
{
int a = 1; /* break-here */
return NULL;
}
int
main (void)
{
pthread_t thread;
pthread_create (&thread, NULL, fun, NULL);
pthread_join (thread, NULL);
return 0;
}
If we define a breakpoint at line "break-here", we expect only Thread
2 to hit it.
$ gdb ./a.out
Reading symbols from ./a.out...
(gdb) break 7
Breakpoint 1 at 0x1182: file mt.c, line 7.
(gdb) set height 2
(gdb) run
Starting program: ./a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff77c4700 (LWP 23048)]
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb) set height unlimited
(gdb) info thread
Id Target Id Frame
* 1 Thread 0x7ffff7fe3740 (LWP 23044) "a.out" 0x00007ffff7bbed2d in ...
2 Thread 0x7ffff77c4700 (LWP 23048) "a.out" fun (dummy=0x0) at mt.c:7
(gdb)
The prompt for continuation was triggered because Thread 2 hit the
breakpoint. (If we had hit 'c', we were going to see that stop event,
but we didn't.) The context did not switch to Thread 2. GDB also did
not execute several other things it would normally do in
infrun.c:normal_stop after outputting "[Switching to Thread ...]" (but
it seems harmless in this case). If we 'continue' at this state, both
threads run until termination, and we don't see the breakpoint hit
event ever.
Here is another related and more complicated scenario that leads to a
GDB crash. Create two inferiors, one sitting on top of a native
target, and the other on a remote target, so that we have a
multi-target setting, like so:
(gdb) i inferiors
Num Description Connection Executable
1 process 13786 1 (native) a.out
* 2 process 13806 2 (remote ...) target:a.out
Next, resume both inferiors to run until termination:
(gdb) set schedule-multiple on
(gdb) set height 2
(gdb) continue
Continuing.
--Type <RET> for more, q to quit, c to continue without paging--[Inferior 2 (process 13806) exited normally]
terminate called after throwing an instance of 'gdb_exception_error'
Aborted
Here, GDB first received a termination event from Inferior 1. GDB
attempted to print this event, triggering a "prompt for continue", and
GDB started polling for events, hoping to get an input from the user.
However, the exit event from Inferior 2 was received instead. So, GDB
started processing an exit event while being in the middle of
processing another exit event. It was not ready for this situation
and eventually crashed.
To address these cases, temporarily disable pagination in
fetch_inferior_event. This doesn't affect commands like 'info
threads', 'backtrace', or 'thread apply'.
Regression-tested on X86_64 Linux.
gdb/ChangeLog:
2020-10-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (fetch_inferior_event): Temporarily disable pagination.
gdb/testsuite/ChangeLog:
2020-10-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/paginate-after-ctrl-c-running.exp: Update with no pagination
behavior.
* gdb.base/paginate-bg-execution.exp: Ditto.
* gdb.base/paginate-inferior-exit.exp: Ditto.
* gdb.base/double-prompt-target-event-error.c: Remove.
* gdb.base/double-prompt-target-event-error.exp: Remove.
|
|
The "detach inferiors N" command causes the current inferior to
switch. E.g.:
$ gdb a.out
Reading symbols from a.out...
(gdb) start
...
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (native)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) info inferiors
Num Description Connection Executable
1 process 18242 1 (native) /path/to/a.out
* 2 <null> 1 (native)
(gdb) detach inferiors 1
Detaching from program: /path/to/a.out, process 18242
[Inferior 1 (process 18242) detached]
(gdb) info inferiors
Num Description Connection Executable
* 1 <null> /path/to/a.out
2 <null> 1 (native)
(gdb)
The same switch happens with the "kill inferiors N" command. Prevent
it by restoring the current thread.
gdb/ChangeLog:
2020-10-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
PR gdb/19318
* inferior.c (detach_inferior_command): Restore the current thread.
(kill_inferior_command): Ditto.
gdb/testsuite/ChangeLog:
2020-10-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/kill-detach-inferiors-cmd.exp: Check that 'kill
inferiors' and 'detach inferiors' do not change the current
inferior.
|
|
When running the testsuite with target board readnow, we run into:
...
FAIL: gdb.ada/exec_changed.exp: start second
FAIL: gdb.ada/exec_changed.exp: start just first
FAIL: gdb.base/reread.exp: opts= "" "" : run to foo() second time
FAIL: gdb.base/reread.exp: opts= "" "" : second pass: run to foo() second time
FAIL: gdb.base/reread.exp: opts= "-fPIE" "ldflags=-pie" : \
run to foo() second time
FAIL: gdb.base/reread.exp: opts= "-fPIE" "ldflags=-pie" : second pass: \
run to foo() second time
...
These are FAILs due to PR26800.
Mark these as KFAILs.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-28 Tom de Vries <tdevries@suse.de>
* gdb.ada/exec_changed.exp: Add KFAILs for -readnow.
* gdb.base/reread.exp: Same.
|
|
With test-case gdb.base/relocate.exp and target board readnow, we get:
...
FAIL: gdb.base/relocate.exp: symbol-file with offset
FAIL: gdb.base/relocate.exp: add-symbol-file with offset
FAIL: gdb.base/relocate.exp: add-symbol-file with offset, text address given
FAIL: gdb.base/relocate.exp: add-symbol-file with offset, data address given
...
Fix these FAILs by updating the regexps for -readnow.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-28 Tom de Vries <tdevries@suse.de>
* gdb.base/relocate.exp: Update regexp for -readnow.
|
|
When running test-case gdb.base/multi-forks.exp with target board readnow, we
run into:
...
FAIL: gdb.base/multi-forks.exp: run to exit 1 (timeout)
...
Fix this by using exp_continue.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-27 Tom de Vries <tdevries@suse.de>
* gdb.base/multi-forks.exp: Use exp_continue to fix timeout.
|
|
When running test-case gdb.base/multi-forks.exp I get:
...
DUPLICATE: gdb.base/multi-forks.exp: run to exit 2
DUPLICATE: gdb.base/multi-forks.exp: run to exit 2
...
Fix these by using test_with_prefix.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/maint.exp with target board readnow, we run
into:
...
FAIL: gdb.base/maint.exp: mt expand-symtabs
FAIL: gdb.base/maint.exp: maint print objfiles: psymtabs
FAIL: gdb.base/maint.exp: maint print psymbols -source
FAIL: gdb.base/maint.exp: maint print psymbols -pc
FAIL: gdb.base/maint.exp: maint info line-table with filename of symtab that \
is not currently expanded
...
When using -readnow:
- there are no partial symtabs
- all symtabs are expanded at symbol load time
and these differences from normal behaviour cause the FAILs.
Update the tests for -readnow.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-27 Tom de Vries <tdevries@suse.de>
* gdb.base/maint.exp: Update for -readnow.
|
|
Use the gdb::option framework for the '-force' flag of the 'condition'
command. This gives tab-completion ability for the flag.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.c (struct condition_command_opts): New struct.
(condition_command_option_defs): New static global.
(make_condition_command_options_def_group): New function.
(condition_completer): Update to consider the '-force' flag.
(condition_command): Use gdb::option for the '-force' flag.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak.exp: Update the completion tests to
consider the '-force' flag.
|
|
When running test-case gdb.base/list-ambiguous.exp with target board readnow,
we run into:
...
FAIL: gdb.base/list-ambiguous.exp: list ambiguous_fun
...
The test-case contains two static functions ambiguous_fun, one in
list-ambiguous0.c and one in list-ambiguous1.c.
The list command is supposed to show both, but only the one from
list-ambiguous0.c is shown.
This is due to the section check in find_pc_sect_compunit_symtab. It checks
whether the candidate compunit_symtab contains a symbol that has the required
section. This check is only done for GLOBAL_BLOCK symbols.
The check succeeds for the compunit_symtab for list-ambiguous0.c, because it
contains main, but it fails for list-ambiguous0.c because it has no global
symbols.
Fix this by extending the section check to STATIC_BLOCK symbols.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-10-27 Tom de Vries <tdevries@suse.de>
* symtab.c (find_pc_sect_compunit_symtab): Include STATIC_BLOCK
symbols in section check.
gdb/testsuite/ChangeLog:
2020-10-27 Tom de Vries <tdevries@suse.de>
* gdb.base/list-ambiguous-readnow.exp: New file.
|
|
The previous patch made it possible to define a condition if it's
valid at some locations. If the condition is invalid at all of the
locations, it's rejected. However, there may be cases where the user
knows the condition *will* be valid at a location in the future,
e.g. due to a shared library load.
To make it possible that such condition can be defined, this patch
adds an optional '-force' flag to the 'condition' command, and,
respectively, a '-force-condition' flag to the 'break'command. When
the force flag is passed, the condition is not rejected even when it
is invalid for all the current locations (note that all the locations
would be internally disabled in this case).
For instance:
(gdb) break test.c:5
Breakpoint 1 at 0x1155: file test.c, line 5.
(gdb) cond 1 foo == 42
No symbol "foo" in current context.
Defining the condition was not possible because 'foo' is not
available. The user can override this behavior with the '-force'
flag:
(gdb) cond -force 1 foo == 42
warning: failed to validate condition at location 1.1, disabling:
No symbol "foo" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if foo == 42
1.1 N 0x0000000000001155 in main at test.c:5
Now the condition is accepted, but the location is automatically
disabled. If a future location has a context in which 'foo' is
available, that location would be enabled.
For the 'break' command, -force-condition has the same result:
(gdb) break test.c:5 -force-condition if foo == 42
warning: failed to validate condition at location 0x1169, disabling:
No symbol "foo" in current context.
Breakpoint 1 at 0x1169: file test.c, line 5.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (set_breakpoint_condition): Add a new bool parameter.
* breakpoint.c: Update the help text of the 'condition' and 'break'
commands.
(set_breakpoint_condition): Take a new bool parameter
to control whether condition definition should be forced even when
the condition expression is invalid in all of the current locations.
(condition_command): Update the call to 'set_breakpoint_condition'.
(find_condition_and_thread): Take the "-force-condition" flag into
account.
* linespec.c (linespec_keywords): Add "-force-condition" as an
element.
(FORCE_KEYWORD_INDEX): New #define.
(linespec_lexer_lex_keyword): Update to consider "-force-condition"
as a keyword.
* ada-lang.c (create_ada_exception_catchpoint): Ditto.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_condition_x): Ditto.
* python/py-breakpoint.c (bppy_set_condition): Ditto.
* NEWS: Mention the changes to the 'break' and 'condition' commands.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.exp: Expand to test forcing
the condition.
* gdb.linespec/cpcompletion.exp: Update to consider the
'-force-condition' keyword.
* gdb.linespec/explicit.exp: Ditto.
* lib/completion-support.exp: Ditto.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document the '-force-condition' flag
of the 'break'command.
* gdb.texinfo (Conditions): Document the '-force' flag of the
'condition' command.
|
|
Currently, for a conditional breakpoint, GDB checks if the condition
can be evaluated in the context of the first symtab and line (SAL).
In case of an error, defining the conditional breakpoint is aborted.
This prevents having a conditional breakpoint whose condition may
actually be meaningful for some of the location contexts. This patch
makes it possible to define conditional BPs by checking all location
contexts. If the condition is meaningful for even one context, the
breakpoint is defined. The locations for which the condition gives
errors are disabled.
The bp_location struct is introduced a new field, 'disabled_by_cond'.
This field denotes whether the location is disabled automatically
because the condition was non-evaluatable. Disabled-by-cond locations
cannot be enabled by the user. But locations that are not
disabled-by-cond can be enabled/disabled by the user manually as
before.
For a concrete example, consider 3 contexts of a function 'func'.
class Base
{
public:
int b = 20;
void func () {}
};
class A : public Base
{
public:
int a = 10;
void func () {}
};
class C : public Base
{
public:
int c = 30;
void func () {}
};
Note that
* the variable 'a' is defined only in the context of A::func.
* the variable 'c' is defined only in the context of C::func.
* the variable 'b' is defined in all the three contexts.
With the existing GDB, it's not possible to define a conditional
breakpoint at 'func' if the condition refers to 'a' or 'c':
(gdb) break func if a == 10
No symbol "a" in current context.
(gdb) break func if c == 30
No symbol "c" in current context.
(gdb) info breakpoints
No breakpoints or watchpoints.
With this patch, it becomes possible:
(gdb) break func if a == 10
warning: failed to validate condition at location 1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 3, disabling:
No symbol "a" in current context.
Breakpoint 1 at 0x11b6: func. (3 locations)
(gdb) break func if c == 30
Note: breakpoint 1 also set at pc 0x11ce.
Note: breakpoint 1 also set at pc 0x11c2.
Note: breakpoint 1 also set at pc 0x11b6.
warning: failed to validate condition at location 1, disabling:
No symbol "c" in current context.
warning: failed to validate condition at location 2, disabling:
No symbol "c" in current context.
Breakpoint 2 at 0x11b6: func. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
2 breakpoint keep y <MULTIPLE>
stop only if c == 30
2.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
2.2 N* 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
2.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
Here, uppercase 'N' denotes that the location is disabled because of
the invalid condition, as mentioned with a footnote in the legend of
the table. Locations that are disabled by the user are still denoted
with lowercase 'n'. Executing the code hits the breakpoints 1.2 and
2.3 as expected.
Defining a condition on an unconditional breakpoint gives the same
behavior above:
(gdb) break func
Breakpoint 1 at 0x11b6: func. (3 locations)
(gdb) cond 1 a == 10
warning: failed to validate condition at location 1.1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 1.3, disabling:
No symbol "a" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
Locations that are disabled because of a condition cannot be enabled
by the user:
...
(gdb) enable 1.1
Breakpoint 1's condition is invalid at location 1, cannot enable.
Resetting the condition enables the locations back:
...
(gdb) cond 1
Breakpoint 1's condition is now valid at location 1, enabling.
Breakpoint 1's condition is now valid at location 3, enabling.
Breakpoint 1 now unconditional.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
If a location is disabled by the user, a condition can still be defined
but the location will remain disabled even if the condition is meaningful
for the disabled location:
...
(gdb) disable 1.2
(gdb) cond 1 a == 10
warning: failed to validate condition at location 1.1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 1.3, disabling:
No symbol "a" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 n 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
The condition of a breakpoint can be changed. Locations'
enable/disable states are updated accordingly.
...
(gdb) cond 1 c == 30
warning: failed to validate condition at location 1.1, disabling:
No symbol "c" in current context.
Breakpoint 1's condition is now valid at location 3, enabling.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if c == 30
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 N* 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
(gdb) cond 1 b == 20
Breakpoint 1's condition is now valid at location 1, enabling.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if b == 20
1.1 y 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 n 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
# Note that location 1.2 was disabled by the user previously.
If the condition expression is bad for all the locations, it will be
rejected.
(gdb) cond 1 garbage
No symbol "garbage" in current context.
For conditions that are invalid or valid for all the locations of a
breakpoint, the existing behavior is preserved.
Regression-tested on X86_64 Linux.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (class bp_location) <disabled_by_cond>: New field.
* breakpoint.c (set_breakpoint_location_condition): New function.
(set_breakpoint_condition): Disable a breakpoint location if parsing
the condition string gives an error.
(should_be_inserted): Update to consider the 'disabled_by_cond' field.
(build_target_condition_list): Ditto.
(build_target_command_list): Ditto.
(build_bpstat_chain): Ditto.
(print_one_breakpoint_location): Ditto.
(print_one_breakpoint): Ditto.
(breakpoint_1): Ditto.
(bp_location::bp_location): Ditto.
(locations_are_equal): Ditto.
(update_breakpoint_locations): Ditto.
(enable_disable_bp_num_loc): Ditto.
(init_breakpoint_sal): Use set_breakpoint_location_condition.
(find_condition_and_thread_for_sals): New static function.
(create_breakpoint): Call find_condition_and_thread_for_sals.
(location_to_sals): Call find_condition_and_thread_for_sals instead
of find_condition_and_thread.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.cc: New file.
* gdb.base/condbreak-multi-context.exp: New file.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document disabling of breakpoint
locations for which the breakpoint condition is invalid.
|
|
AArch64 generates functions without a prologue for these two testcases,
therefore we shouldn't expect the function location to be displayed with
an offset.
gdb/testsuite/ChangeLog:
2020-10-22 Luis Machado <luis.machado@linaro.org>
* gdb.base/msym-bp-shl.exp (test_break): Adjust pattern to not
expected an offset from the function.
* gdb.base/msym-bp.exp (test): Likewise.
|
|
Similar to the previous patch, but this time add "-q" to tests that do
"break main", "list main", etc. explicitly.
gdb/testsuite/ChangeLog:
* config/monitor.exp: Use "list -q".
* gdb.arch/gdb1558.exp: Use "break -q".
* gdb.arch/i386-permbkpt.exp: Use "break -q".
* gdb.arch/i386-prologue-skip-cf-protection.exp: Use "break -q".
* gdb.base/break.exp: Use "break -q", "list -q" and "tbreak -q".
* gdb.base/commands.exp: Use "break -q".
* gdb.base/condbreak.exp: Use "break -q".
* gdb.base/ctf-ptype.exp: Use "list -q".
* gdb.base/define.exp: Use "break -q".
* gdb.base/del.exp: Use "break -q".
* gdb.base/fullname.exp: Use "break -q".
* gdb.base/hbreak-in-shr-unsupported.exp: Use "hbreak -q".
* gdb.base/hbreak-unmapped.exp: Use "hbreak -q".
* gdb.base/hbreak2.exp: Use "hbreak -q" and "list -q".
* gdb.base/hw-sw-break-same-address.exp: Use "break -q" and
"hbreak -q".
* gdb.base/included.exp: Use "list -q".
* gdb.base/label.exp: Use "break -q".
* gdb.base/lineinc.exp: Use "break -q".
* gdb.base/list.exp: Use "list -q".
* gdb.base/macscp.exp: Use "list -q".
* gdb.base/pending.exp: Use "break -q".
* gdb.base/prologue-include.exp: Use "break -q".
* gdb.base/ptype.exp: Use "list -q".
* gdb.base/sepdebug.exp: Use "break -q", "list -q" and "tbreak -q".
* gdb.base/server-del-break.exp: Use "break -q".
* gdb.base/style.exp: Use "break -q".
* gdb.base/symbol-without-target_section.exp: Use "list -q".
* gdb.base/watchpoint-reuse-slot.exp: Use "hbreak -q".
* gdb.cp/exception.exp: Use "tbreak -q".
* gdb.dwarf2/dw2-error.exp: Use "break -q".
* gdb.dwarf2/fission-mix.exp: Use "break -q".
* gdb.dwarf2/fission-reread.exp: Use "break -q".
* gdb.dwarf2/pr13961.exp: Use "break -q".
* gdb.linespec/explicit.exp: Use "list -q".
* gdb.linespec/linespec.exp: Use "break -q".
* gdb.mi/mi-simplerun.exp: Use "--qualified".
* gdb.python/py-mi-objfile-gdb.py: Use "list -q".
* gdb.server/bkpt-other-inferior.exp: Use "break -q".
* gdb.server/connect-without-multi-process.exp: Use "break -q".
* gdb.trace/change-loc.exp: Use "break -q".
* gdb.trace/pending.exp: Use "break -q".
* gdb.tui/basic.exp: Use "list -q".
* gdb.tui/list-before.exp: Use "list -q".
* gdb.tui/list.exp: Use "list -q".
* lib/gdb.exp (gdb_has_argv0): Use "break -q".
Change-Id: Iab9408e90ed71cbb111cd737d2d81b5ba8adb108
|
|
In some runtimes, there may be a "main" function in some class or
namespace. The breakpoint created by runto_main may therefore have
unexpected locations on some other functions than the actual main.
These breakpoint locations can unexpectedly get hit during tests and
lead to failures.
I saw this while playing with AMD's ROCm toolchain -- I wrote a board
file to run the testsuite against device kernels. There, the runtime
calls a "main" function before the device kernel code is reached:
Thread 4 "bit_extract" hit Breakpoint 1, 0x00007ffeea140960 in lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
(gdb) bt
#0 0x00007ffeea140960 in lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
#1 0x00007ffeea2257a5 in lld::elf::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
#2 0x00007ffeea1bc374 in COMGR::linkWithLLD(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
#3 0x00007ffeea1bfb09 in COMGR::InProcessDriver::execute(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
#4 0x00007ffeea1c4da9 in COMGR::AMDGPUCompiler::linkToExecutable() () from /opt/rocm/lib/libamd_comgr.so.1
#5 0x00007ffeea1fde20 in dispatchCompilerAction(amd_comgr_action_kind_s, COMGR::DataAction*, COMGR::DataSet*, COMGR::DataSet*, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
#6 0x00007ffeea203a87 in amd_comgr_do_action () from /opt/rocm/lib/libamd_comgr.so.1
...
To avoid that, pass "qualified" to runto, in runto_main, so that
gdb_breakpoint ends up creating a breakpoint with -qualified. This
avoids creating breakpoints locations for other unrelated "main"
functions.
Note: I first tried making runto itself use "-qualified", but that
caused regressions in the gdb.ada/ tests, which use runto without
specifying the whole fully-qualified function name (i.e., without the
package). So I end up restricting the -qualified to
runto_main/mi_runto_main.
The gdb.base/ui-redirect.exp change is necessary because that testcase
is looking at what "save breakpoint" generates.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Expect "break -qualified main" in
saved breakpoints file.
* gdb.guile/scm-breakpoint.exp: Expect "-qualified main" when
inspecting breakpoint list.
* lib/gdb.exp (runto_main): Add "qualified" to options.
* lib/mi-support.exp (mi_runto_helper): Add 'qualified' parameter,
and handle it.
(mi_runto_main): Pass 1 as qualified argument.
Change-Id: I51468359ab0a518f05f7c0394c97f7e33b45fe69
|
|
This commit does 's/runto main/runto_main/g' throughout.
gdb/testsuite/ChangeLog:
* gdb.ada/fun_in_declare.exp: Use "runto_main" instead of
"runto main".
* gdb.ada/small_reg_param.exp: Likewise.
* gdb.arch/powerpc-d128-regs.exp: Likewise.
* gdb.base/annota1.exp: Likewise.
* gdb.base/anon.exp: Likewise.
* gdb.base/breakpoint-in-ro-region.exp: Likewise.
* gdb.base/dprintf-non-stop.exp: Likewise.
* gdb.base/dprintf.exp: Likewise.
* gdb.base/gdb11530.exp: Likewise.
* gdb.base/gdb11531.exp: Likewise.
* gdb.base/gnu_vector.exp: Likewise.
* gdb.base/interrupt-noterm.exp: Likewise.
* gdb.base/memattr.exp: Likewise.
* gdb.base/step-over-syscall.exp: Likewise.
* gdb.base/watch-cond-infcall.exp: Likewise.
* gdb.base/watch-read.exp: Likewise.
* gdb.base/watch-vfork.exp: Likewise.
* gdb.base/watch_thread_num.exp: Likewise.
* gdb.base/watchpoint-stops-at-right-insn.exp: Likewise.
* gdb.guile/scm-frame-inline.exp: Likewise.
* gdb.linespec/explicit.exp: Likewise.
* gdb.opt/inline-break.exp: Likewise.
* gdb.python/py-frame-inline.exp: Likewise.
* gdb.reverse/break-precsave.exp: Likewise.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/consecutive-reverse.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/fstatat-reverse.exp: Likewise.
* gdb.reverse/getresuid-reverse.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/i386-reverse.exp: Likewise.
* gdb.reverse/i386-sse-reverse.exp: Likewise.
* gdb.reverse/i387-env-reverse.exp: Likewise.
* gdb.reverse/i387-stack-reverse.exp: Likewise.
* gdb.reverse/insn-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/pipe-reverse.exp: Likewise.
* gdb.reverse/readv-reverse.exp: Likewise.
* gdb.reverse/recvmsg-reverse.exp: Likewise.
* gdb.reverse/rerun-prec.exp: Likewise.
* gdb.reverse/s390-mvcle.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/solib-reverse.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/step-reverse.exp: Likewise.
* gdb.reverse/time-reverse.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/until-reverse.exp: Likewise.
* gdb.reverse/waitpid-reverse.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
* gdb.threads/kill.exp: Likewise.
* gdb.threads/tid-reuse.exp: Likewise.
Change-Id: I70f457253836019880b4d7fb981936afa56724c2
|
|
Debugging with "maintenance set target-async off" on Linux has been
broken since 5b6d1e4fa4f ("Multi-target support").
The issue is easy to reproduce:
$ ./gdb -q --data-directory=data-directory -nx ./test
Reading symbols from ./test...
(gdb) maintenance set target-async off
(gdb) start
Temporary breakpoint 1 at 0x1151: file test.c, line 5.
Starting program: /home/simark/build/binutils-gdb/gdb/test
... and it hangs there.
The difference between pre-5b6d1e4fa4f and 5b6d1e4fa4f is that
fetch_inferior_event now calls target_wait with TARGET_WNOHANG for
non-async-capable targets, whereas it didn't before.
For non-async-capable targets, this is how it's expected to work when
resuming execution:
1. we call resume
2. the infrun async handler is marked in prepare_to_wait, to immediately
wake up the event loop when we get back to it
3. fetch_inferior_event calls the target's wait method without
TARGET_WNOHANG, effectively blocking until the target has something
to report
However, since we call the target's wait method with TARGET_WNOHANG,
this happens:
1. we call resume
2. the infrun async handler is marked in prepare_to_wait, to immediately
wake up the event loop when we get back to it
3. fetch_inferior_event calls the target's wait method with
TARGET_WNOHANG, the target has nothing to report yet
4. we go back to blocking on the event loop
5. SIGCHLD finally arrives, but the event loop is not woken up, because
we are not in async mode. Normally, we should have been stuck in
waitpid the SIGCHLD would have unblocked us.
We end up in this situation because these two necessary conditions are
met:
1. GDB uses the TARGET_WNOHANG option with a target that can't do async.
I don't think this makes sense. I mean, it's technically possible,
the doc for TARGET_WNOHANG is:
/* Return immediately if there's no event already queued. If this
options is not requested, target_wait blocks waiting for an
event. */
TARGET_WNOHANG = 1,
... which isn't in itself necessarily incompatible with synchronous
targets. It could be possible for a target to support non-blocking
polls, while not having a way to asynchronously wake up the event
loop, which is also necessary to support async. But as of today,
we don't expect GDB and sync targets to work this way.
2. The linux-nat target, even in the mode where it emulates a
synchronous target (with "maintenance set target-async off") respects
TARGET_WNOHANG. Other non-async targets, such as windows_nat_target,
simply don't check / support TARGET_WNOHANG, so their wait method is
always blocking.
Fix the first issue by avoiding using TARGET_WNOHANG on non-async
targets, in do_target_wait_1. Add an assert in target_wait to verify it
doesn't happen.
The new test gdb.base/maint-target-async-off.exp is a simple test that
just tries running to main and then to the end of the program, with
"maintenance set target-async off".
gdb/ChangeLog:
PR gdb/26642
* infrun.c (do_target_wait_1): Clear TARGET_WNOHANG if the
target can't do async.
* target.c (target_wait): Assert that we don't pass
TARGET_WNOHANG to a target that can't async.
gdb/testsuite/ChangeLog:
PR gdb/26642
* gdb.base/maint-target-async-off.c: New test.
* gdb.base/maint-target-async-off.exp: New test.
Change-Id: I69ad3a14598863d21338a8c4e78700a58ce7ad86
|
|
A number of testcases define variables and/or functions which are
referenced by GDB during the test, but which are not referenced from
within the test executable. Clang correctly recognizes that these
variables and functions are unused, and optimizes them out, causing
the testcases in question to fail. This commit adds __attribute__
((used)) in various places to prevent this.
gdb/testsuite/ChangeLog:
* gdb.base/msym-bp.c (foo): Add __attribute__ ((used)).
* gdb.base/msym-bp-2.c (foo): Likewise.
* gdb.base/msym-lang.c (foo): Likewise.
* gdb.base/msym-lang-main.c (foo): Likewise.
* gdb.base/symtab-search-order-1.c (static_global): Likewise.
* gdb.guile/scm-pretty-print.c (eval_func): Likewise.
* gdb.mi/mi-sym-info-1.c (global_f1): Likewise.
* gdb.mi/mi-sym-info-2.c (global_f1, var1, var2): Likewise.
* gdb.multi/watchpoint-multi-exit.c (globalvar): Likewise.
* gdb.python/py-as-string.c (enum_valid, enum_invalid): Likewise.
* gdb.python/py-objfile.c (static_var): Likewise.
* gdb.python/py-symbol.c (rr): Likewise.
* gdb.python/py-symbol-2.c (anon, rr): Likewise.
* gdb.mi/mi-sym-info.exp (lineno1, lineno2): Updated.
|
|
When printing void results without any format letter, they are output
as expected:
(gdb) p $abcd
$1 = void
(gdb) p (void)10
$2 = void
But if any format letter (besides s) is used, it always outputs zero:
(gdb) p/x $abcd
$3 = 0x0
(gdb) p/x (void)10
$4 = 0x0
So this adds void results to the types handled like unformatted prints.
gdb/ChangeLog:
2020-10-09 Hannes Domani <ssbssa@yahoo.de>
PR exp/26714
* printcmd.c (print_formatted): Handle void results as
unformatted prints.
gdb/testsuite/ChangeLog:
2020-10-09 Hannes Domani <ssbssa@yahoo.de>
PR exp/26714
* gdb.base/printcmds.exp: Add tests for void results.
|
|
I noticed a couple of spots where the "disassemble" could style its
output, but currently does not. This patch adds styling to the
function name at the start of the disassembly, and any addresses
printed there.
gdb/ChangeLog
2020-10-08 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (print_disassembly): Style function name and
addresses. Add _() wrappers.
gdb/testsuite/ChangeLog
2020-10-08 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Check that "main"'s name is styled.
|
|
This renames some tests in find.exp, to avoid duplicate test names.
gdb/testsuite/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* gdb.base/find.exp: Rename some tests.
|
|
Two subtests of gdb.base/list.exp failed when built with Clang
because the unused function "unused" was optimized out. This
commit adds __attribute__ ((used)) to both definitions.
gdb/testsuite/ChangeLog:
* gdb.base/list0.c (unused): Add __attribute__ ((used)).
* gdb.base/list1.c (unused): Likewise.
|
|
The ambiguous variable parts of gdb.base/list-ambiguous.exp failed
when built with Clang because the variable in question was unused
and was optimized out. This commit adds __attribute__ ((used)) to
both definitions.
gdb/testsuite/ChangeLog:
* gdb.base/list-ambiguous0.c (ambiguous_var): Add
__attribute__ ((used)).
* gdb.base/list-ambiguous1.c (ambiguous_var): Likewise.
|
|
The gdb.base/overlays.exp test is only currently supported on m32r
baremetal targets, however, when I configure a toolchain for m32r-elf
the test does not compile.
This commit updates the linker script, fixes some TCL errors in the
exp file, and adds some missing includes to the source file so that
the test does compile.
With this test, when run against an m32r-elf toolchain the test mostly
passes, but there are a couple of failures, these are GDB issues and
will be addressed in a later commit.
gdb/testsuite/ChangeLog:
* gdb.base/m32r.ld: Remove SEARCH_DIR line. Add MEMORY regions,
make use of regions throughout.
* gdb.base/overlays.exp: Enclose string with variableds in "..",
not {...}.
* gdb.base/ovlymgr.c: Add 'string.h' and 'stdlib.h' includes.
|
|
Fixes these testsuite fails on Windows:
FAIL: gdb.base/callfuncs.exp: p t_float_complex_values(fc1, fc2)
FAIL: gdb.base/callfuncs.exp: p t_float_complex_many_args(fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4)
FAIL: gdb.base/callfuncs.exp: noproto: p t_float_complex_values(fc1, fc2)
FAIL: gdb.base/callfuncs.exp: noproto: p t_float_complex_many_args(fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4, fc1, fc2, fc3, fc4)
FAIL: gdb.base/call-sc.exp: p/c fun(); call call-sc-tld
FAIL: gdb.base/call-sc.exp: advance to fun for return; return call-sc-tld
FAIL: gdb.base/call-sc.exp: zed L for return; return call-sc-tld
FAIL: gdb.base/call-sc.exp: return foo; return call-sc-tld
FAIL: gdb.base/call-sc.exp: return foo; synchronize pc to main() for 'call-sc-tld'
FAIL: gdb.base/call-sc.exp: return foo; synchronize pc to main() for 'call-sc-tld'
FAIL: gdb.base/call-sc.exp: advance to fun for finish; return call-sc-tld
FAIL: gdb.base/call-sc.exp: zed L for finish; return call-sc-tld
FAIL: gdb.base/call-sc.exp: finish foo; return call-sc-tld (the program is no longer running)
FAIL: gdb.base/call-sc.exp: value foo finished; return call-sc-tld
For function arguments (callfuncs.exp), only TYPE_CODE_COMPLEX was
missing in the types passed via integer registers.
For return values, there were a lot more issues:
- TYPE_CODE_DECFLOAT is NOT returned via XMM0.
- long double is NOT returned via XMM0.
- but __int128 IS returned via XMM0.
- the comments for TYPE_CODE_FLT state that __m128, __m128i and __m128d are
returned by XMM0, and this is correct, but it doesn't actually check for
them, because they are TYPE_CODE_ARRAY with TYPE_VECTOR
So I had to add TYPE_CODE_DECFLOAT to the arguments passed via XMM register,
but I had to remove it from the values returned via XMM0 register.
gdb/ChangeLog:
2020-10-05 Hannes Domani <ssbssa@yahoo.de>
* amd64-windows-tdep.c (amd64_windows_passed_by_integer_register):
Add TYPE_CODE_COMPLEX.
(amd64_windows_return_value): Fix types returned via XMM0.
gdb/testsuite/ChangeLog:
2020-10-05 Hannes Domani <ssbssa@yahoo.de>
* gdb.base/call-sc.c: Fix return struct on stack test case.
* gdb.base/call-sc.exp: Likewise.
|
|
gdb.base/infcall-nested-structs-c++.exp failed to build using Clang
with many variations on the following error:
gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.base/infcall-nested-structs.c:207:46:
warning: self-comparison always evaluates to true [-Wtautological-compare]
This commit builds this testcase with -Wno-tautological-compare when
using Clang, to avoid this failure.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.exp.tcl: Add
additional_flags=-Wno-tautological-compare for C++
tests when compiling using Clang.
|
|
If printing 'envp[$i]' in find_env fails, the testcase goes into an
infinite loop:
Running /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/testenv.exp ...
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[0] ? envp[0] : ""
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[1] ? envp[1] : ""
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[2] ? envp[2] : ""
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[3] ? envp[3] : ""
...
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[2519] ? envp[2519] : ""
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[2520] ? envp[2520] : ""
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[2521] ? envp[2521] : ""
..
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[5128] ? envp[5128] : ""
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[5129] ? envp[5129] : ""
FAIL: gdb.base/testenv.exp: test_inherit_env_var: test1: printf "var1: %s\n", envp[5130] ? envp[5130] : ""
...
Fix that by bailing out of the loop on failure.
gdb/testsuite/ChangeLog:
* gdb.base/testenv.exp (find_env): Bail out if printing 'envp[$i]'
fails.
|
|
Fixes:
src/gdb/testsuite/gdb.base/sizeof.c:54:9: error: cannot initialize a variable of type 'char *' with an lvalue of type 'void *'
... when the testcase is built with a C++ compiler.
gdb/testsuite/ChangeLog:
* gdb.base/sizeof.c (fill): Add cast.
|
|
gdb/testsuite/ChangeLog:
* gdb.base/share-env-with-gdbserver.c (main): Add cast.
|
|
Make these testcases work when compiled as C++ programs.
These testcases use the alias attribute, which requires passing in the
target function's mangled name in C++. To avoid having to figure out
how the functions are mangled, explicitly specify a linkage name.
This is preferred over 'extern "C"' because that doesn't work with
static functions.
gdb/testsuite/ChangeLog:
* gdb.base/prologue.c [__cplusplus] (marker): Explicitly specify
linkage name.
* gdb.base/prologue.exp: Use print /d.
* gdb.base/symbol-alias.exp: Handle C++ output.
* gdb.base/symbol-alias2.c: Handle C++ output.
[__cplusplus] (func): Explicitly specify linkage name.
|
