| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit adds a separate Fortran compiler identification mechanism to
the testsuite, similar to the existing one for C/C++. Before this
change, the options and version for the Fortran compiler specified when
running the testsuite with F90_FOR_TARGET set, was detected via its
respective C compiler. So running the testsuite as
make check TEST=gdb.fortran/*.exp CC_FOR_TARGET=gcc F90_FOR_TARGET=ifx
or even
make check TEST=gdb.fortran/*.exp F90_FOR_TARGET=ifx
would use the gcc compiler inside the procedures get_compiler_info and
test_compiler_info to identify compiler flags and the compiler version.
This could sometimes lead to unpredictable outputs. It also limited
testsuite execution to combinations where C and Fortran compiler would
come from the same family of compiers (gcc/gfortran, icc/ifort, icx/ifx,
clang/flang ..). This commit enables GDB to detect C and Fortran
compilers independently of each other.
As most/nearly all Fortran compilers have a mechanism for preprocessing
files in a C like fashion we added the exact same meachnism that already
existed for C/CXX. We let GDB preprocess a file with the compilers
Fortran preprocessor and evaluate the preprocessor defined macros in that
file.
This enables GDB to properly run heterogeneous combinations of C and
Fortran compilers such as
CC_FOR_TARGET='gcc' and F90_FOR_TARGET='ifort'
or enables one to run the testsuite without specifying a C compiler as in
make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='ifx'
make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='flang'
On the other hand this also requires one to always specify a
identification mechanism for Fortran compilers in the compiler.F90 file.
We added identification for GFORTRAN, FLANG (CLASSIC and LLVM) IFX,
IFORT, and ARMFLANG for now.
Classic and LLVM flang were each tested with their latest releases on
their respective release pages. Both get recognized by the new compiler
identification and we introduced the two names flang-classic and
flang-llvm to distinguish the two. While LLVM flang is not quite mature
enough yet for running the testsuite we still thought it would be a good
idea to include it already. For this we added a case for the fortran_main
procedure. LLVM flang uses 'MAIN__' as opposed to classic flang which
uses 'MAIN_' here.
We did not have the possibility to test ARMFLANG - the versioning scheme
here was extracted from its latest online documentation.
We changed the test_compiler_info procedure to take another optional
argument, the language string, which will be passed though to the
get_compiler_info procedure. Passing 'f90' or 'c++' here will then
trigger the C++/Fortran compiler identification within
get_compiler_info. The latter procedure was extended to also handle
the 'f90' argument (similarly to the already existing 'c++' one).
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
|
The procedure gdb_compile queries its options via
[lsearch -exact $options getting_compiler_info]
to check whether or not it was called in with the option
getting_compiler_info. If it was called with this option it would
preprocess some test input to try and figure out the actual compiler
version of the compiler used. While doing this we cannot again try to
figure out the current compiler version via the 'getting_compiler_info'
option as this would cause infinite recursion. As some parts of the
procedure do recursively test for the compiler version to e.g. set
certain flags, at several places gdb_compile there are checks for the
getting_compiler_info option needed.
In the procedure, there was already a variable 'getting_compiler_info'
which was set to the result of the 'lsearch' query and used instead of
again and again looking for getting_compiler_info in the procedure
options. But, this variable was actually set too late within the code.
This lead to a mixture of querying 'getting_compiler_info' or
doing an lserach on the options passed to the procedure.
I found this inconsistent and instead moved the variable
getting_compiler_info to the front of the procedure. It is set to true
or false depending on whether or not the argument is found in the
procedure's options (just as before) and queried instead of doing an
lsearch on the procedure options in the rest of the procedure.
|
|
Newer Intel compilers emit their dwarf type name in a slightly different
format. Therefore, this needs adjustment to make more tests pass in the
Fortran testsuite.
Co-authored-by: Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
|
The '-J' option is not supported in Intel compilers (ifx and ifort).
The Intel version of the flag is '-module' which serves the same purpose.
|
|
The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
procedure were removed in this commit
commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257
Author: Tom Tromey <tromey@redhat.com>
Date: Wed Jun 29 17:50:47 2011 +0000
over 10 years ago. The last .f files in the testsuite by now are all
being compiled by passing 'f90' to the GDB compile, thus only actually
using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
Gfortran in this case is backwards compatible with most f77 code as
claimed on gcc.gnu.org/fortran.
The reason we'd like to get rid of this now is, that we'll be
implementing a Fortran compiler identification mechanism, similar to the
C/Cpp existing ones. It would be using the Fortran preprocessor macro
defines to identify the Fortran compiler version at hand. We found it
inconsequent to only implement this for f90 but, on the other hand, f77
seems deprecated. So, with this commit we remove the remaining lines for
its support.
|
|
Spotted a duplicate test name in gdb.trace/signal.exp, resolved in
this commit by making use of 'with_test_prefix'.
|
|
Patch
202be274a41a ("opcodes/i386: remove trailing whitespace from insns with zero operands")
causes this regression:
FAIL: gdb.trace/signal.exp: find syscall insn in kill
It's because the test still expects to match a whitespace after the
instruction, which the patch mentioned above removed. Remove the
whitespaces for the regexp.
Change-Id: Ie194273cc942bfd91332d4035f6eec55b7d3a428
|
|
Consider this command defined in Python (in the file test-cmd.py):
class test_cmd (gdb.Command):
"""
This is the first line.
Indented second line.
This is the third line.
"""
def __init__ (self):
super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)
def invoke (self, arg, from_tty):
print ("In test-cmd")
test_cmd()
Now, within a GDB session:
(gdb) source test-cmd.py
(gdb) help test-cmd
This is the first line.
Indented second line.
This is the third line.
(gdb)
I think there's three things wrong here:
1. The leading blank line,
2. The trailing blank line, and
3. Every line is indented from the left edge slightly.
The problem of course, is that GDB is using the Python doc string
verbatim as its help text. While the user has formatted the help text
so that it appears clear within the .py file, this means that the text
appear less well formatted when displayed in the "help" output.
The same problem can be observed for gdb.Parameter objects in their
set/show output.
In this commit I aim to improve the "help" output for commands and
parameters.
To do this I have added gdbpy_fix_doc_string_indentation, a new
function that rewrites the doc string text following the following
rules:
1. Leading blank lines are removed,
2. Trailing blank lines are removed, and
3. Leading whitespace is removed in a "smart" way such that the
relative indentation of lines is retained.
With this commit in place the above example now looks like this:
(gdb) source ~/tmp/test-cmd.py
(gdb) help test-cmd
This is the first line.
Indented second line.
This is the third line.
(gdb)
Which I think is much neater. Notice that the indentation of the
second line is retained. Any blank lines within the help text (not
leading or trailing) will be retained.
I've added a NEWS entry to note that there has been a change in
behaviour, but I didn't update the manual. The existing manual is
suitably vague about how the doc string is used, so I think the new
behaviour is covered just as well by the existing text.
|
|
While working on another patch[1] I had need to touch this code in
i386-dis.c:
ins->obufp = ins->mnemonicendp;
for (i = strlen (ins->obuf) + prefix_length; i < 6; i++)
oappend (ins, " ");
oappend (ins, " ");
(*ins->info->fprintf_styled_func)
(ins->info->stream, dis_style_mnemonic, "%s", ins->obuf);
What this code does is add whitespace after the instruction mnemonic
and before the instruction operands.
The problem I ran into when working on this code can be seen by
assembling this input file:
.text
nop
retq
Now, when I disassemble, here's the output. I've replaced trailing
whitespace with '_' so that the issue is clearer:
Disassembly of section .text:
0000000000000000 <.text>:
0: 90 nop
1: c3 retq___
Notice that there's no trailing whitespace after 'nop', but there are
three spaces after 'retq'!
What happens is that instruction mnemonics are emitted into a buffer
instr_info::obuf, then instr_info::mnemonicendp is setup to point to
the '\0' character at the end of the mnemonic.
When we emit the whitespace, this is then added starting at the
mnemonicendp position. Lets consider 'retq', first the buffer is
setup like this:
'r' 'e' 't' 'q' '\0'
Then we add whitespace characters at the '\0', converting the buffer
to this:
'r' 'e' 't' 'q' ' ' ' ' ' ' '\0'
However, 'nop' is actually an alias for 'xchg %rax,%rax', so,
initially, the buffer is setup like this:
'x' 'c' 'h' 'g' '\0'
Then in NOP_Fixup we spot that we have an instruction that is an alias
for 'nop', and adjust the buffer to this:
'n' 'o' 'p' '\0' '\0'
The second '\0' is left over from the original buffer contents.
However, when we rewrite the buffer, we don't afjust mnemonicendp,
which still points at the second '\0' character.
Now, when we insert whitespace we get:
'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0'
Notice the whitespace is inserted after the first '\0', so, when we
print the buffer, the whitespace is not printed.
The fix for this is pretty easy, I can change NOP_Fixup to adjust
mnemonicendp, but now a bunch of tests start failing, we now produce
whitespace after the 'nop', which the tests don't expect.
So, I could update the tests to expect the whitespace....
...except I'm not a fan of trailing whitespace, so I'd really rather
not.
Turns out, I can pretty easily update the whitespace emitting code to
spot instructions that have zero operands and just not emit any
whitespace in this case. So this is what I've done.
I've left in the fix for NOP_Fixup, I think updating mnemonicendp is
probably a good thing, though this is not really required any more.
I've then updated all the tests that I saw failing to adjust the
expected patterns to account for the change in whitespace.
[1] https://sourceware.org/pipermail/binutils/2022-April/120610.html
|
|
The recent DWARF indexer rewrite introduced a regression when debugging
a forking program.
Here is a way to reproduce the issue (there might be other ways, but one
is enough and this one mimics the situation we encountered). Consider a
program which forks, and the child loads a shared library and calls a
function in this shared library:
if (fork () == 0)
{
void *solib = dlopen (some_solib, RTLD_NOW);
void (*foo) () = dlsym (some_solib, "foo");
foo ();
}
Suppose that this program is compiled without debug info, but the shared
library it loads has debug info enabled.
When debugging such program with the following options:
- set detach-on-fork off
- set follow-fork-mode child
we see something like:
(gdb) b foo
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo) pending.
(gdb) run
Starting program: a.out
[Attaching after process 19720 fork to child process 19723]
[New inferior 2 (process 19723)]
[Switching to process 19723]
Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so
(gdb) list
Fatal signal: Segmentation fault
----- Backtrace -----
0x55a278f77d76 gdb_internal_backtrace_1
../../gdb/bt-utils.c:122
0x55a278f77f83 _Z22gdb_internal_backtracev
../../gdb/bt-utils.c:168
0x55a27940b83b handle_fatal_signal
../../gdb/event-top.c:914
0x55a27940bbb1 handle_sigsegv
../../gdb/event-top.c:987
0x7effec0343bf ???
/build/glibc-sMfBJT/glibc-2.31/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x55a27924c9d3 _ZNKSt15__uniq_ptr_implI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE6_M_ptrEv
/usr/include/c++/9/bits/unique_ptr.h:154
0x55a279248bc9 _ZNKSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE3getEv
/usr/include/c++/9/bits/unique_ptr.h:361
0x55a2792ae718 _ZN27dwarf2_base_index_functions23find_last_source_symtabEP7objfile
../../gdb/dwarf2/read.c:3164
0x55a279afb93e _ZN7objfile23find_last_source_symtabEv
../../gdb/symfile-debug.c:139
0x55a279aa3040 _Z20select_source_symtabP6symtab
../../gdb/source.c:365
0x55a279aa22a1 _Z34set_default_source_symtab_and_linev
../../gdb/source.c:268
0x55a27903c44c list_command
../../gdb/cli/cli-cmds.c:1185
0x55a279051233 do_simple_func
../../gdb/cli/cli-decode.c:95
0x55a27905f221 _Z8cmd_funcP16cmd_list_elementPKci
../../gdb/cli/cli-decode.c:2514
0x55a279c3b0ba _Z15execute_commandPKci
../../gdb/top.c:660
0x55a27940a6c3 _Z15command_handlerPKc
../../gdb/event-top.c:598
0x55a27940b032 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
../../gdb/event-top.c:797
0x55a279caf401 tui_command_line_handler
../../gdb/tui/tui-interp.c:278
0x55a279409098 gdb_rl_callback_handler
../../gdb/event-top.c:230
0x55a279ed5df2 rl_callback_read_char
../../../readline/readline/callback.c:281
0x55a279408bd8 gdb_rl_callback_read_char_wrapper_noexcept
../../gdb/event-top.c:188
0x55a279408de7 gdb_rl_callback_read_char_wrapper
../../gdb/event-top.c:205
0x55a27940a061 _Z19stdin_event_handleriPv
../../gdb/event-top.c:525
0x55a27a23771e handle_file_event
../../gdbsupport/event-loop.cc:574
0x55a27a237f5f gdb_wait_for_event
../../gdbsupport/event-loop.cc:700
0x55a27a235d81 _Z16gdb_do_one_eventv
../../gdbsupport/event-loop.cc:237
0x55a2796c2ef0 start_event_loop
../../gdb/main.c:418
0x55a2796c3217 captured_command_loop
../../gdb/main.c:478
0x55a2796c717b captured_main
../../gdb/main.c:1340
0x55a2796c7217 _Z8gdb_mainP18captured_main_args
../../gdb/main.c:1355
0x55a278d0b381 main
../../gdb/gdb.c:32
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
The first issue observed is in the message printed when hitting the
breakpoint. It says that there was a break in the .so file as if there
was no debug info associated with it, but there is. Later, if we try to
display the source where the execution stopped, we have a segfault.
Note that not having the debug info on the main binary is not strictly
required to encounter some issues, it only is to encounter the segfault.
If the main binary has debug information, GDB shows some source form the
main binary, unrelated to where we stopped.
The core of the issue is that GDB never loads the psymtab for the
library. It is not loaded when we first see the .so because in case of
detach-on-fork off, follow-fork-mode child, infrun.c sets
child_inf->symfile_flags = SYMFILE_NO_READ to delay the psymtab loading
as much as possible. If we compare to what was done to handle this
before the new indexer was activated, the psymatb construction for the
shared library was done under
psymbol_functions::expand_symtabs_matching:
bool
psymbol_functions::expand_symtabs_matching (...)
{
for (partial_symtab *ps : require_partial_symbols (objfile))
...
}
The new indexer's expand_symtabs_matching callback does not have a call
to the objfile's require_partial_symbols, so if the partial symbol table
is not loaded at this point, there is no mechanism to fix this.
Instead of requiring each implementation of the quick_functions to check
that partial symbols have been read, I think it is safer to enforce this
when calling the quick functions. The general pattern for calling the
quick functions is:
for (auto *iter : qf)
iter->the_actual_method_call (...)
This patch proposes to wrap the access of the `qf` field with an accessor
which ensures that partial symbols have been read before iterating:
qf_require_partial_symbols. All calls to quick functions are updated
except:
- quick_functions::dump
- quick_functions::read_partial_symbols (from
objfile::require_partial_symbols)
- quick_functions::can_lazily_read_symbols and quick_functions::has_symbols
(from objfile::has_partial_symbols)
Regression tested on x86_64-gnu-linux.
Change-Id: I39a13a937fdbaae613a5cf68864b021000554546
|
|
PR gdb/29128 points out a crash in the new DWARF index code. This
happens if the aranges for a CU claims a PC, but the symtab that is
created during CU expansion does not actually contain the PC. This
can only occur due to bad debuginfo, but at the same time, gdb should
not crash.
This patch fixes the bug and further merges some code into
dwarf2_base_index_functions. This merger helps prevent the same issue
from arising from the other index implementations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29128
|
|
Since ed01945057c "Make gdb_test's question non-optional if specified",
if the question and response parameters are given to gdb_test, the
framework enforces that GDB asks the question. Before this patch, tests
needed to use gdb_test_multiple to enforce this.
This patch updates the gdb.dwarf2/calling-convention.exp testcase to use
gdb_test to check that GDB asks a question. This replaces the more
complicated gdb_test_multiple based implementation.
Tested on x86_64-gnu-linux.
Change-Id: I7216e822ca68f2727e0450970097d74c27c432fe
|
|
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
|
|
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.
I think that not issuing a PASS should be restricted to only a few
cases -- namely in shared routines exported by gdb.exp, which happen
to use gdb_test internally. In tests that iterate an unknown number
of tests exercising some racy scenario. In the latter case, if we
emit PASSes for each iteration, we run into the situation where
different testsuite runs emit a different number of PASSes.
Thus, this patch preserves the current behavior, and, instead, adds a
new "-nopass" option to gdb_test and gdb_test_no_output. Compared to
the old way of supressing PASS with an empty message, this has the
advantage that you can specify a FAIL message that is distinct from
the command string, and, it's also more explicit.
Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
|
|
When running test-case gdb.opt/clobbered-registers-O2.exp with clang 12.0.1, I
get:
...
(gdb) run ^M
Starting program: clobbered-registers-O2 ^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
gen_movsd (operand0=<optimized out>, operand1=<optimized out>) at \
clobbered-registers-O2.c:31^M
31 return *start_sequence(operand0, operand1);^M
(gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: runto: run to start_sequence
...
The problem is that the breakpoint in start_sequence doesn't trigger, because:
- the call to start_sequence in gen_movsd is optimized away, despite the
__attribute__((noinline)), so the actual function start_sequence doesn't get
called, and
- the debug info doesn't contain inlined function info, so there's only one
breakpoint location.
Adding noclone and noipa alongside the noinline attribute doesn't fix this.
Adding the clang-specific attribute optnone in start_sequence does, but since
it inhibits all optimization, that's not a preferred solution in a gdb.opt
test-case, and it would work only for clang and not other compilers that
possibly have the same issue.
Fix this by moving functions start_sequence and gen_movsd into their own
files, as a way of trying harder to enforce noinline/noipa/noclone.
Tested on x86_64-linux.
|
|
When running test-case gdb.opt/clobbered-registers-O2.exp with gcc-12, I run
into:
...
(gdb) PASS: gdb.opt/clobbered-registers-O2.exp: backtracing
print operand0^M
$1 = (unsigned int *) 0x7fffffffd070^M
(gdb) print *operand0^M
$2 = 4195541^M
(gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: print operand0
...
The problem is that starting gcc-12, the assignments to x and y in main are
optimized away:
...
int main(void)
{
unsigned x, y;
x = 13;
y = 14;
return (int)gen_movsd (&x, &y);
...
Fix this by making x and y volatile.
Note that the test-case intends to check the handling of debug info for
optimized code in function gen_movsd, so inhibiting optimization in main
doesn't interfere with that.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29161
|
|
With check-read1 I run into:
...
[infrun] maybe_set_commit_resumed_all_targets: not requesting
commit-resumed for target native, no resumed threads^M
(gdb) FAIL: gdb.base/ui-redirect.exp: debugging: continue
[infrun] fetch_inferior_event: exit^M
...
The problem is that proc gdb_test doesn't pass down the -prompt option to proc
gdb_test_multiple, due to a typo making this lappend without effect:
...
set opts {}
lappend "-prompt $prompt"
...
Fix this by actually appending to opts.
Tested on x86_64-linux.
|
|
When building gdb with -fsanitize=undefined, I run into:
...
$ gdb -q -batch -ex "p -(-0x7fffffffffffffff - 1)"
src/gdb/valarith.c:1385:10: runtime error: signed integer overflow: \
0 - -9223372036854775808 cannot be represented in type 'long int'
$1 = -9223372036854775808
...
Fix this by performing the substraction in scalar_binop using unsigned types.
Tested on x86_64-linux.
|
|
In test-case gdb.base/parse_number.exp, we skip architecture auto in the
$supported_archs loop, to prevent duplicate testing.
Likewise, skip language auto and its alias local in the $::all_languages
loop. This reduces the number of tests from 17744 to 15572.
Tested on x86_64-linux, with a build with --enable-targets=all.
|
|
Currently GDB is not able to debug (Binary generated with Clang) variables
present in shared/private clause of OpenMP Task construct. Please note that
LLVM debugger LLDB is able to debug.
In case of OpenMP, compilers generate artificial functions which are not
present in actual program. This is done to apply parallelism to block of
code.
For non-artifical functions, DW_AT_name attribute should contains the name
exactly as present in actual program.
(Ref# http://wiki.dwarfstd.org/index.php?title=Best_Practices)
Since artificial functions are not present in actual program they not having
DW_AT_name and having DW_AT_linkage_name instead should be fine.
Currently GDB is invalidating any function not havnig DW_AT_name which is why
it is not able to debug OpenMP (Clang).
It should be fair to fallback to check DW_AT_linkage_name in case DW_AT_name
is absent.
|
|
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
|
|
The .quad statement stores the 64-bit hex value in Endian order. When used
to store a 64-bit prefix instructions on Big Endian (BE) systems, the .quad
statement stores the 32-bit suffix followed by the 32-bit prefix rather
than the expected order of prefix word followed by the suffix word. GDB
fetches 32-bits at a time when disassembling instructions. The disassembly
on BE gets messed up since GDB fetches the suffix first and interprets it
as a word instruction not a prefixed instruction. When gdb fetches the
prefix part of the instruction, following the initial suffix word, gdb
associates the prefix word incorrectly with the following 32-bits as the
suffix for the instruction when in fact it is the following instruction.
For example on BE we have two prefixed instructions stored using the
.quad statement as follows:
addr word GDB action
---------------------------------------------
1 suffix inst A <- GDB interprets as a word instruction
2 prefix inst A <- GDB uses this prefix with
3 suffix inst B <- this suffix rather than the suffix at addr 1.
4 prefix inst B
This patch changes the .quad statement into two .longs to explicitly store
the prefix followed by the suffix of the instruction.
The patch rearranges the instructions to put all of the word instructions
together followed by the prefix instructions for clarity.
The patch has been tested on Power 10 and Power 7 BE and LE to verify
the change works as expected.
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/async-shell.exp"
we can see the following message in gdb/testsuite/gdb.sum:
UNSUPPORTED: gdb.base/async-shell.exp: displaced stepping
modify support_displaced_stepping to support displaced stepping
on LoongArch.
With this patch:
PASS: gdb.base/async-shell.exp: run &
PASS: gdb.base/async-shell.exp: shell echo foo
PASS: gdb.base/async-shell.exp: interrupt
PASS: gdb.base/async-shell.exp: process stopped
I did the following tests that use support_displaced_stepping
with this patch on LoongArch, there is no failed testcases.
loongson@linux:~/gdb.git$ grep -r support_displaced_stepping gdb/testsuite/gdb.*
gdb/testsuite/gdb.arch/disp-step-insn-reloc.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/step-over-no-symbols.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/moribund-step.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/async-shell.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/inferior-died.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/step-over-syscall.exp: if {$displaced == "on" && ![support_displaced_stepping]} {
gdb/testsuite/gdb.mi/mi-watch-nonstop.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-ns-stale-regcache.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nonstop.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsmoribund.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsintrall.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsthrexec.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nonstop-exit.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.multi/watchpoint-multi.exp:if [support_displaced_stepping] {
gdb/testsuite/gdb.python/py-evthreads.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/interrupt-while-step-over.exp: if { ${displaced-stepping} != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp: if { $displaced != "off" && ![support_displaced_stepping] } {
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Fix changes that didn't make it into commit:
dd9cd55e990bcc9f8448cac38d242d53974b3604.
Fix missing -wrap on gdb_test_multiple in gdb.base/kill-after-signal.exp
that is causing regression test on x86_64-linux with taskset -c 0.
|
|
This will allow the unwind info to explicitly specify a different value
for the return address from the link register.
Such usage, although uncommon, is valid and useful for signal frames.
It is also supported by aadwarf64 from ARM (Note 9 in [1]).
Ref https://sourceware.org/pipermail/gdb/2022-May/050091.html
[1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names
Signed-off-by: Luis Machado <luis.machado@arm.com>
|
|
This teaches gdb_test to forward the -prompt and -lbl options to
gdb_test_multiple.
The option parsing is done with parse_args.
As a cleanup, instead of using llength and lindex to get at the
positional arguments, use lassign, and check whether the corresponding
variable is empty.
Convert gdb.base/ui-redirect.exp and gdb.xml/tdesc-reload.exp to use
gdb_test -prompt/-lbl instead of gdb_test_multiple as examples.
Change-Id: I243e1296d32c05a421ccef30b63d43a89eaeb4a0
|
|
Move testing of language unknown out of the $supported_archs loop in
gdb.base/parse_number.exp. This reduces total amount of tests from 18466 to
17744.
Tested on x86_64-linux.
|
|
In gdb.base/parse_number.exp, add a new proc hex_for_lang that formats a hex
number appropriately for a given language.
Tested on x86_64-linux.
|
|
After the patch to make gdb_test's question non-optional when
specified, gdb.python/py-connection.exp started failing like so:
$ make check TESTS="gdb.python/py-connection.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
(gdb) PASS: gdb.python/py-connection.exp: info connections while the connection is still around
disconnect^M
Ending remote debugging.^M
(gdb) FAIL: gdb.python/py-connection.exp: kill the inferior
The problem is that "disconnect" when debugging with the native target
asks the user whether to kill the program, while with remote targets,
it doesn't.
Fix it by explicitly killing before disconnecting.
Tested with --target_board unix, native-gdbserver, and native-extended-gdbserver.
Change-Id: Icd85015c76deb84b71894715d43853c1087eba0b
|
|
gdb_test supports handling scenarios where GDB asks a question before
finishing handling some command. The full prototype of gdb_test is:
# gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE
However, QUESTION is a question that GDB _may_ ask, not one that GDB
_must_ ask:
# QUESTION is a question GDB may ask in response to COMMAND, like
# "are you sure?"
# RESPONSE is the response to send if QUESTION appears.
If GDB doesn't raise the question, the test still passes.
I think that this is a misfeature. If GDB regresses and stops asking
a question, the testsuite won't notice. So I think that if a QUESTION
is specified, gdb_test should ensure it comes out of GDB.
Running the testsuite exposed a number of tests that pass
QUESTION/RESPONSE to GDB, but no question comes out. The previous
commits fixed them all, so this commit changes gdb_test's behavior.
A related issue is that gdb_test doesn't enforce that if you specify
QUESTION, that you also specify RESPONSE. I.e., you should pass 1, 2,
3, or 5 arguments to gdb_test, but never 4, or more than 5. Making
gdb_test detect bogus arguments actually regressed some testcases,
also all fixed in previous commits.
Change-Id: I47c39c9034e6a6841129312037a5ca4c5811f0db
|
|
gdb.base/skip.exp abuses gdb_test's support for answering a GDB
question to do this:
# With gcc 9.2.0 we jump once back to main before entering foo here.
# If that happens try to step a second time.
gdb_test "step" "foo \\(\\) at.*" "step 3" \
"main \\(\\) at .*\r\n$gdb_prompt " "step"
After a patch later in this series, gdb_test will FAIL if GDB does NOT
issue the question, so this test would start failing on older GCCs.
Switch to using gdb_test_multiple instead. There are three spots in
the file that have the same pattern, and they're actually in a
sequence of commands that is repeated those 3 times. Factor all that
out to a procedure.
I don't have gcc 9.2 handy, but I do have gcc 6.5, and that one is
affected as well, so update the comment.
Change-Id: If0a7e3cdf5191b4eec95ce0c8845c3a4d801c39e
|
|
gdb.server/connect-with-no-symbol-file.exp's connect_no_symbol_file
does:
gdb_test "file" ".*" "discard symbol table" \
{Discard symbol table from `.*'\? \(y or n\) } "y"
A following patch will make gdb_test expect the question out of GDB if
one is passed down as argument to gdb_test. With that, this test
starts failing. This is because connect_no_symbol_file is called in a
loop, and the first time around, there's a loaded file, so "file" asks
the "Discard symbol table ... ?" question, while in the following
iterations there's no file, so there's no question.
Fix this by not loading a file into GDB in the first place.
Change-Id: I810c036b57842c4c5b47faf340466b0d446d1abc
|
|
A following patch will make gdb_test error out if bogus arguments are
passed, which exposed bugs in a few testcases:
- gdb.python/py-parameter.exp, passing a spurious "1" as extra
parameter, resulting in:
ERROR: Unexpected arguments: {set test-file-param bar.txt} {The name of the file has been changed to bar.txt} {set new file parameter} 1
- gdb.python/py-xmethods.exp, a missing test message, resulting in
the next gdb_test being interpreted as message, question and
response! With the enforcing patch, this was caught with:
ERROR: Unexpected arguments: {p g.mul<char>('a')} {From Python G<>::mul.*} gdb_test {p g_ptr->mul<char>('a')} {From Python G<>::mul.*} {after: g_ptr->mul<char>('a')}
- gdb.base/pointers.exp, missing a quote.
Change-Id: I66f2db4412025a64121db7347dfb0b48240d46d4
|
|
This test is abusing the QUESTION/RESPONSE feature to send an
alternative command to GDB if the first command fails. Like so:
gdb_test "print 'scope0.c'::filelocal" \
"\\\$$decimal = 1" "print 'scope0.c'::filelocal at main" \
"No symbol \"scope0.c\" in current context.*" \
"print '$srcdir/$subdir/scope0.c'::filelocal"
So if 'scope0.c' doesn't work, we try again with
'$srcdir/$subdir/scope0.c'. I strongly suspect this is really an
obsolete test. I think that if '$srcdir/$subdir/scope0.c' works, then
'scope0.c' should have worked too, thus I'd think that if we pass due
to the question path, then it's a bug. So just remove the question
part passed to gdb_test.
Change-Id: I2acc99285f1d519284051b49693b5441fbdfe3cd
|
|
Change-Id: Ib2616dc883e9dc9ee100f6c86d83a921a0113c16
|
|
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.
|
|
I noticed that corefile-run.core ends up in the 'runtest' directory.
It's better, when at all possible, for test files to end up in the
test's designated subdirectory. This patch makes this change.
|
|
If you load a core file into GDB with the --write option, or "set
write on" (equivalent), and then poke memory expecting it to patch the
core binary, you'll notice something odd -- the write seems to
succeed, but in reality, it doesn't. The value you wrote doesn't
persist. Like so:
$ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test
[New LWP 615986]
Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 0x0000555555555131 in ?? ()
(gdb) p *(unsigned char *)0x0000555555555131 = 1
$1 = 1 '\001'
(gdb) p *(unsigned char *)0x0000555555555131
$2 = 185 '\271'
(gdb)
Diffing hexdumps of before/after patching, reveals that a "0x1" was
actually written somewhere in the file. The problem is that the "0x1"
was written at the wrong offset in the file...
That happens because _bfd_elf_set_section_contents does this to seek
to the section's offset:
pos = hdr->sh_offset + offset;
if (bfd_seek (abfd, pos, SEEK_SET) != 0
|| bfd_bwrite (location, count, abfd) != count)
return false;
... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is
incorrect. The reason 'hdr->sh_offset' is zero is that
kernel-generated core files normally don't even have a section header
table (gdb-generated ones do, but that's more an accident than a
feature), and indeed elf_core_file_p doesn't even try to read sections
at all:
/* Core files are simply standard ELF formatted files that partition
the file using the execution view of the file (program header table)
rather than the linking view. In fact, there is no section header
table in a core file.
The process status information (including the contents of the general
register set) and the floating point register set are stored in a
segment of type PT_NOTE. We handcraft a couple of extra bfd sections
that allow standard bfd access to the general registers (.reg) and the
floating point registers (.reg2). */
bfd_cleanup
elf_core_file_p (bfd *abfd)
Changing _bfd_elf_set_section_contents from:
pos = hdr->sh_offset + offset;
to:
pos = section->filepos + offset;
fixes it. If we do that however, the tail end of
_bfd_elf_set_section_contents ends up as a copy of
_bfd_generic_set_section_contents, so just call the latter, thus
eliminating some duplicate code.
New GDB testcase included, which exercises both patching an executable
and patching a core file. Patching an executable already works
without this fix, because in that case BFD reads in the sections
table. Still, we had no testcase for that yet. In fact, we have no
"set write on" testcases at all, this is the first one.
Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227
Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce
|
|
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
|
|
There are assumptions in the test about the long double format
being used. While the results are OK for i387 128-bit long doubles, it
is not correct for IEEE quad 128-bit long doubles.
Also, depending on the target (64-bit/32-bit), long doubles may not
be available at all. And it may be the case that the compiler for a 64-bit
target doesn't support 128-bit long doubles, but GDB might still support it
internally.
Lastly, not every long double format has invalid values. Some formats
consider all values as valid floating point numbers.
These divergences cause the following FAIL's on aarch64/arm:
FAIL: gdb.ada/float-bits.exp: print val_long_double
FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment
With the above in mind, extend the test a little so it behaves well on
different architectures and so it works with different long double
formats.
Main changes:
- Use long double values appropriate for the long double format.
- Test long double assignment to compiler-generated long
double variables.
- Test long double assignment to GDB internal variables.
Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
|
|
On aarch64-linux, with test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp I
run into:
...
(gdb) run ^M
Starting program: dw2-out-of-range-end-of-seq ^M
^M
Program received signal SIGILL, Illegal instruction.^M
main () at src/gdb/testsuite/gdb.dwarf2/main.c:1^M
1 /* This testcase is part of GDB, the GNU debugger.^M
(gdb) FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: runto: run to main
...
There are two problems here:
- the test-case contains a hardcoded "DW_LNS_advance_pc 1" which causes the
breakpoint pointing in the middle of an insn
- the FAIL triggers on aarch64-linux, but not on x86_64-linux, because the
test-case uses 'main_label' as the address of the first and only valid entry
in the line table, and:
- on aarch64-linux, there's no prologue, so main_label and main coincide,
while
- on x86_64-linux, there's a prologue, so main_label is different from main.
Fix these problems by:
- eliminating the use of "DW_LNS_advance_pc 1", and using
"DW_LNE_set_address $main_end" instead, and
- eliminating the use of main_label, using "DW_LNE_set_address $main_start"
instead.
Tested on both x86_64-linux and aarch64-linux.
|
|
When doing a gdb build with --with-expat=no, I run into:
...
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
continue to breakpoint: before pipe call
catch syscall pipe^M
Unknown syscall name 'pipe'.^M
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
catch syscall pipe
catch syscall pipe2^M
Unknown syscall name 'pipe2'.^M
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
catch syscall pipe2
continue^M
Continuing.^M
[Detaching after vfork from child process 18538]^M
[Inferior 1 (process 18537) exited normally]^M
(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
...
This is a regression since recent commit 5463a15c18b ("[gdb/testsuite] Handle
pipe2 syscall in gdb.base/catch-syscall.exp").
Fix this by using pipe/pipe2 syscall numbers instead.
Tested on x86_64-linux.
|
|
When doing a gdb build without --enable-targets, I run into:
...
(gdb) UNSUPPORTED: gdb.base/catch-syscall.exp: multiple targets: \
s390:31-bit vs s390:64-bit: set architecture s390:64-bit
delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break -qualified main^M
No symbol table is loaded. Use the "file" command.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.base/catch-syscall.exp: gdb_breakpoint: set breakpoint at main
...
The problem is that due to recent commit e21d8399303 ("[gdb/testsuite] Remove
target limits in gdb.base/catch-syscall.exp") "clean_restart $binfile" no
longer is called at the end of test_catch_syscall_multi_arch.
Fix this by moving "clean_restart $binfile" back to
test_catch_syscall_multi_arch.
Tested on x86_64-linux.
|
|
On powerpc64le-linux, I ran into:
...
FAIL: gdb.base/maint.exp: maint print objfiles: symtabs
...
The problem is that:
- the "Cooked index in use" line occurs twice in the gdb output:
- once for exec maint, and
- once for "Object file system-supplied DSO".
- the matching of the second "Cooked index in use" also consumes
the "Symtabs:" string, and consequently the corresponding
clause does not trigger and $symtabs remains 0.
Fix this by limiting the output of the command to the exec.
Tested on x86_64-linux and powerpcle-linux.
|
|
Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel.
|
|
In test-case gdb.base/catch-syscall.exp, proc test_catch_syscall_multi_arch we
test for supported targets using istarget, like so:
...
if { [istarget "i*86-*-*"] || [istarget "x86_64-*-*"] } {
...
} elseif { [istarget "powerpc-*-linux*"] \
|| [istarget "powerpc64*-linux*"] } {
...
...
but the tests excercised there can all be executed if gdb is configured with
--enable-targets=all.
Rewrite the proc to iterate over all cases, and check if the test is supported
by trying "set arch $arch1" and "set arch $arch2".
Tested on x86_64-linux, with:
- a gdb build with --enable-targets=all, and
- a gdb build build with my usual --enable-targets setting (too long to
include here) which means the sparc vs sparc:v9 case is unsupported.
|
|
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
|
|
This commit fixes two regressions introduced by
891e4190ba705373eec7b374209478215fff5401.
Reason for the failures was, that on a 32 bit machine the maximum
array length as well as the maximum allocatable memory for arrays
(in bytes) both seem to be limited by the maximum value of a 4
byte (signed) Fortran integer. This lead to compiler errors/unexpected
behavior when compiling/running the test with the -m32 board. This
behavior is compiler dependent and can differ for different compiler
implementations, but generally, it seemed like a good idea to simply
avoid such situations.
The affected tests check for GDB's overflow behavior when using KIND
parameters with GDB implemented Fortran intrinsic functions. If these
KIND parameters are too small to fit the actual intrinsic function's
result, an overflow is expected. This was done for 1, 2, and 4
byte overflows. The last one caused problems, as it tried to allocate
arrays of length/byte-size bigger than the 4 byte signed integers which
would then be used with the LBOUND/UBOUND/SIZE intrinsics.
The tests were adapted to only execute the 4 byte overflow tests when
running on targets with 64 bit. For this, the compiled tests evaluate the
byte size of a C_NULL_PTR via C_SIZEOF, both defined in the ISO_C_BINDING
module. The ISO_C_BINDING constant C_NULL_PTR is a Fortran 2003, the
C_SIZEOF a Fortran 2008 extension. Both have been implemented in their
respective compilers for while (e.g. C_SIZEOF is available since
gfortran 4.6). If this byte size evaluates to less than 8 we skip the
4 byte overflow tests in the compiled tests of size.f90 and
lbound-ubound.f90. Similarly, in the lbound-ubound.exp testsfile we skip
the 4 byte overflow tests if the procedure is_64_target evaluates to false.
In size.f90, additionally, the to-be-allocated amount of bytes did not
fit into 4 byte signed integers for some of the arrays, as it was
approximately 4 times the maximum size of a 4 byte signed integer. We
adapted the dimensions of the arrays in question as the meaningfulness
of the test does not suffer from this.
With this patch both test run fine with the unix/-m32 board and
gcc/gfortran (9.4) as well as the standard board file.
We also thought about completely removing the affected test from the
testsuite. We decided against this as the 32 bit identification comes
with Fortran 2008 and removing tests would have decreased coverage.
A last change that happened with this patch was due to gfortran's and
ifx's type resolution when assigning big constants to Fortran Integer*8
variables. Before the above changes this happened in a parameter
statement. Here, both compilers happily accepted a line like
integer*8, parameter :: var = 2147483647 + 5.
After this change the assignment is not done as a parameter
anymore, as this triggered compile time overflow errors. Instead,
the assignment is done dynamically, depending on the kind of machine one
is on. Sadly, just changing this line to
integer*8 :: var
var = 2147483647 + 5
does not work with ifx (or flang for that matter, they behave similarly
here). It will create an integer overflow in the addition as ifx deduces
the type the additon is done in as Integer*4. So var will actually
contain the value -2147483644 after this. The lines
integer*8 :: var
var = 2147483652
on the other hand fail to compile with gfortran (9.4.0) as the compiler
identifies an Integer overflow here. Finally, to make this work with
all three compilers an additional parameter has been introduced
integer*8, parameter :: helper = 2147483647
integer*8 :: var
var = helper + 5.
This works on all 3 compilers as expected.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29053
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29054
|
