| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A while back, I changed objfiles to be held via a shared_ptr. The
idea at the time was that this was a step toward writing to the index
cache in the background, and this would let gdb keep a reference alive
to do so. However, since then we've rewritten the DWARF reader, and
the new index can do this without requiring a shared pointer -- in
fact there are patches pending to implement this.
This patch switches objfile management to unique_ptr, which makes more
sense now.
Regression tested on x86-64 Fedora 34.
|
|
The order in which the variables in info common and info locals are
displayed is compiler (and dwarf) dependent. While all symbols should
be displayed the order is not fixed.
I added a gdb_test_multiple that lets ifx and ifort pass in cases where
only the order differs.
|
|
When value-printing a pointer within GDB by default GDB will look for
defined symbols residing at the address of the pointer. For the given
test the Intel/LLVM compiler stacks both display a symbol associated
with a printed pointer while the gnu stack does not. This leads to
failures in the test when running the test with CC_FOR_TARGET='clang'
CXX_FOR_TARGET='clang' F90_FOR_TARGET='flang'"
(gdb) b 37
(gdb) r
(gdb) f 6
(gdb) info args
a = 1
b = 2
c = 3
d = 4 + 5i
f = 0x419ed0 "abcdef"
g = 0x4041a0 <.BSS4>
or CC_FOR_TARGET='icx' CXX_FOR_TARGET='icpx' F90_FOR_TARGET='ifx'"
(gdb) b 37
(gdb) r
(gdb) f 6
(gdb) info args
a = 1
b = 2
c = 3
d = 4 + 5i
f = 0x52eee0 "abcdef"
g = 0x4ca210 <mixed_func_1a_$OBJ>
For the compiled binary the Intel/LLVM compilers both decide to move the
local variable g into the .bss section of their executable. The gnu
stack will keep the variable locally on the stack and not define a
symbol for it.
Since the behavior for Intel/LLVM is actually expected I adapted the
testcase at this point to be a bit more allowing for other outputs.
I added the optional "<SYMBOLNAME>" to the regex testing for g.
The given changes reduce the test fails for Intel/LLVM stack by 4 each.
|
|
While testing mixed-lang-stack I realized that valgrind actually
complained about a double free in the test.
All done
==2503051==
==2503051== HEAP SUMMARY:
==2503051== in use at exit: 0 bytes in 0 blocks
==2503051== total heap usage: 26 allocs, 27 frees, 87,343 bytes allocated
==2503051==
==2503051== All heap blocks were freed -- no leaks are possible
==2503051==
==2503051== For lists of detected and suppressed errors, rerun with: -s
==2503051== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Reason for this is that in mixed-lang-stack.cpp in mixed_func_1f an
object "derived_type obj" goes on the stack which is then passed-by-value
(so copied) to mixed_func_1g. The default copy-ctor will be called but,
since derived_type contains a heap allocated string and the copy
constructor is not implemented it will only be able to shallow copy the
object. Right after each of the functions the object gets freed - on the
other hand the d'tor of derived_type actually is implemented and calls
free on the heap allocated string which leads to a double free. Instead
of obeying the rule of 3/5 I just got rid of all that since it does not
serve the test. The string is now just a const char* = ".." object
member.
|
|
For ifort, ifx, and flang the tests "complete modm" and "complete
modmany" fail. This is because all three emit additional completion
suggestions. These additional suggestions have their origin in symbols
emitted by the compilers which can also be completed from the respective
incomplete word (modm or modmany). For this specific example gfortran
does not emit any additional symbols.
For example, in this test the linkage name for var_a in ifx is
"modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead.
Since modmany_mp_var_a can be completed from modm and also modmany they
will get displayed, while gfortran's symbol starts with "__" and thus will
be ignored (it cannot be a completion of a word starting with "m").
Similar things happen in flang and ifort. Some example output is shown
below:
FLANG
(gdb) complete p modm
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
p modmany_
IFX/IFORT
(gdb) complete p modm
p modmany
p modmany._
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
p modmany_mp_var_a_
p modmany_mp_var_b_
p modmany_mp_var_c_
p modmany_mp_var_i_
GFORTRAN
(gdb) complete p modm
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
I want to emphasize: for Fortran (and also C/C++) the complete command
does not actually check whether its suggestions make sense - all it does
is look for any symbol (in the minimal symbols, partial symbols etc.)
that a given substring can be completed to (meaning that the given substring
is the beginning of the symbol). One can easily produce a similar
output for the gfortran compiled executable. For this look at the
slightly modified "complete p mod" in gfortran:
(gdb) complete p mod
p mod1
p mod1::var_const
...
p mod_1.c
p modcounter
p mode_t
p modf
...
p modify_ldt
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
p module
p module.f90
p module_entry
p moduse
p moduse::var_x
p moduse::var_y
Many of the displayed symbols do not actually work with print:
(gdb) p mode_t
Attempt to use a type name as an expression
(gdb) p mod_1.c
No symbol "mod_1" in current context.
(gdb)
I think that in the given test the output for gfortran only looks nice
"by chance" rather than is actually expected. Expected is any output
that also contains the completions
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
while anythings else can be displayed as well (depending on the
compiler and its emitted symbols).
This, I'd consider all three outputs as valid and expected - one is just
somewhat lucky that gfortran does not produce any additional symbols that
got matched.
The given patch improves test performance for all three compilers
by allowing additional suggested completions inbetween and after
the two given blocks in the test. I did not allow additional print
within the modmany_list block since the output is ordered alphabetically
and there should normally not appear any additional symbols there.
For flang/ifx/ifort I each see 2 failures less (which are exactly the two
complete tests).
As a side note and since I mentioned C++ in the beginning: I also tried
the gdb.cp/completion.exp. The output seems a bit more reasonable,
mainly since C++ actually has a demangler in place and linkage symbols
do not appear in the output of complete. Still, with a poor enough
to-be-completed string one can easily produce similar results:
(gdb) complete p t
...
p typeinfo name for void
p typeinfo name for void const*
p typeinfo name for void*
p typeinfo name for wchar_t
p typeinfo name for wchar_t const*
p typeinfo name for wchar_t*
p t *** List may be truncated, max-completions reached. ***
(gdb) p typeinfo name for void*
No symbol "typeinfo" in current context.
(gdb) complete p B
p BACK_SLASH
p BUF_FIRST
p BUF_LAST
...
p Base
p Base::Base()
p Base::get_foo()
p bad_key_err
p buf
p buffer
p buffer_size
p buflen
p bufsize
p build_charclass.isra
(gdb) p bad_key_err
No symbol "bad_key_err" in current context.
(compiled with gcc/g++ and breaking at main).
This patch is only about making the referenced test more 'fair' for the
other compilers. Generally, I find the behavior of complete a bit
confusing and maybe one wants to change this at some point but this
would be a bigger task.
|
|
This info-types.exp test case had a few issues that this patch fixes.
First, the emitted symbol character(kind=1)/character*1 (different
compilers use different naming converntions here) which is checkedin the
test is not actually expected given the test program. There is no
variable of that type in the test. Still, gfortran emits it for every
Fortran program there is. The reason is the way gfortran handles Fortran's
named main program. It generates a wrapper around the Fortran program
that is quite similar to a C main function. This C-like wrapper has
argc and argv arguments for command line argument passing and the argv
pointer type has a base type character(kind=1) DIE emitted at CU scope.
Given the program
program prog
end program prog
the degbug info gfortran emits looks somewhat like
<0><c>: Abbrev Number: 3 (DW_TAG_compile_unit)
...
<1><2f>: Abbrev Number: 4 (DW_TAG_subprogram)
<30> DW_AT_external : 1
<30> DW_AT_name : (indirect string, ...): main
...
<2><51>: Abbrev Number: 1 (DW_TAG_formal_parameter)
<52> DW_AT_name : (indirect string, ...): argc
...
<2><5d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
<5e> DW_AT_name : (indirect string, ...): argv
...
<62> DW_AT_type : <0x77>
...
<2><6a>: Abbrev Number: 0
...
<1><77>: Abbrev Number: 6 (DW_TAG_pointer_type)
<78> DW_AT_byte_size : 8
<79> DW_AT_type : <0x7d>
<1><7d>: Abbrev Number: 2 (DW_TAG_base_type)
<7e> DW_AT_byte_size : 1
<7f> DW_AT_encoding : 8 (unsigned char)
<80> DW_AT_name : (indirect string, ...): character(kind=1)
<1><84>: Abbrev Number: 7 (DW_TAG_subprogram)
<85> DW_AT_name : (indirect string, ...): prog
...
Ifx and flang do not emit any debug info for a wrapper main method so
the type is missing here. There was the possibility of actually adding
a character*1 type variable to the Fortran executable, but both, ifx and
gfortran chose to emit this variable's type as a DW_TAG_string_type of
length one (instead of a character(kind=1), or whatever the respective
compiler naming convention is). While string types are printed as
character*LENGHT in the fortran language part (e.g. when issuing a
'ptype') they do not generate any symbols inside GDB. In read.c it says
/* These dies have a type, but processing them does not create
a symbol or recurse to process the children. Therefore we can
read them on-demand through read_type_die. */
So they did not add any output to 'info types'. Only flang did emit a
character type here.
As adding a type would have a) not solved the problem for ifx and would
have b) somehow hidden the curious behavior of gfortran, instead, the
check for this character type was chagened to optional with the
check_optional_entry to allow for the symbols's absence and to allow
flang and ifx to pass this test as well.
Second, the line checked for s1 was hardcoded as 37 in the test. Given
that the type is actually defined on line 41 (which is what is emitted by
ifx) it even seems wrong. The line check for s1 was changed to actually
check for 41 and a gfortran bug has been filed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
The test is now marked as xfail for gfortran.
Third, the whole test of checking for the 'Type s1' in info types seemed
questionable. The type s1 is declared iside the scope of the Fortran
program info_types_test. Its DIE however is emitted as a child of the
whole compilation unit making it visible outside of the program's scope.
The 'info types' command checks for types stored in the GLOBAL_BLOCK,
or STATIC_BLOCKm wgucm according to block.h
The GLOBAL_BLOCK contains all the symbols defined in this compilation
whose scope is the entire program linked together.
The STATIC_BLOCK contains all the symbols whose scope is the
entire compilation excluding other separate compilations.
so for gfortran, the type shows up in the output of 'info types'. For
flang and ifx on the other hand this is not the case. The two compilers
emit the type (correctly) as a child of the Fortran program, thus not
adding it to either, the GLOBAL_BLOCK nor the LOCAL_BLOCK. A bug has
been opened for the gfortran scoping issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
While the most correct change might have been removing the check for s1,
the change made here was to only check for this type in case of gfortran
being used as the compiler, as this check also covers the declaration
line issue mentioned above. A comment was added to maybe remove this
check once the scoping issue is resolved (and it starts to fail with
newer gfortran versions). The one used to test these changes was 13.0.
|
|
There was already a similar functionality for the GDBInfoModuleSymbols.
This just extends the GDBInfoSymbols. We will use this feature in a
later commit to make a testcase less GNU specific and more flexible for
other compilers.
Namely, in gdb.fortran/info-types.exp currenlty
GDBInfoSymbols::check_entry is used to verify and test the output of the
info symbols command. The test, however was written with gfortran as a
basis and some of the tests are not fair with e.g. ifx and ifort as
they test for symbols that are not actually required to be emitted. The
lines
GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
and
GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;"
check for types that are either not used in the source file (character1)
or should not be emitted by the compiler at global scope (s1) thus no
appearing in the info symbols command. In order to fix this we will
later use the newly introduced check_optional_entry over check_entry.
|
|
In order for ifx and ifort to emit all debug entries, even for unused
parameters in modules we have to define the '-debug-parameters all' flag.
This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp.
|
|
The test was earlier not using the compiler dependent type print system
in fortran.exp. I changed this. It should generally improve the test
performance for different compilers. For ifx and gfortran I do not see
any failures.
|
|
Currenlty, ifx/ifort cannot compile the given executable as it is not
valid Fortran. It is missing the external keyword on the
no_arg_subroutine. Gfortran compiles the example but this is actually
a bug and there is an open gcc ticket for this here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377
Adding the keyword does not change the gfortran compiling of the example.
It will, however, prevent a future fail once 50377 has been addressed.
|
|
The test specifically tests for the Fortran CHARACTER(KIND=4) which is
not available in ifx/ifort.
Since the other characters are also printed elsewhere, we disable this
test for the unsupported compilers.
|
|
The name for icx and icpx in the testsuite was earlier set to 'intel-*'
by the compiler identification. This commit changes this to 'icx-*'.
Note, that currently these names are not used within the testsuite so no
tests have to be adapted here.
|
|
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.
|
|
Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: I9440052fd28f795d6f7c93a4576beadd21f28885
|
|
In the name matching unit tests in gdb/dwarf2/read.c, explain better
why we test symbols with \377 / 0xff characters (Latin1 'ΓΏ').
Change-Id: I517f13adfff2e4d3cd783fec1d744e2b26e18b8e
|
|
Change-Id: Iac26e1d2e7d8dc8a7d9516e6bdcc5c3fc4af45c8
|
|
Change-Id: I05639ddb3bf620c7297b57ed286adc3aa926b7b6
|
|
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
|
|
The current "Specify Location" section of the GDB manual starts with:
"Several @value{GDBN} commands accept arguments that specify a location
of your program's code."
And then, such commands are documented as taking a "location"
argument. For example, here's a representative subset:
@item break @var{location}
@item clear @var{location}
@item until @var{location}
@item list @var{location}
@item edit @var{location}
@itemx info line @var{location}
@item info macros @var{location}
@item trace @var{location}
@item info scope @var{location}
@item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}
The issue here is that "location" isn't really correct for most of
these commands. Instead, the "location" argument is really a
placeholder that represent an umbrella term for all of the
"linespecs", "explicit location", and "address location" input
formats. GDB parses these and then finds the actual code locations
(plural) in the program that match. For example, a "location"
specified like "-function func" will actually match all the code
locations in the program that correspond to the address/file/lineno of
all the functions named "func" in all the loaded programs and shared
libraries of all the inferiors. A location specified like "-function
func -label lab" matches all the addresses of C labels named "lab" in
all functions named "func". Etc.
This means that several of the commands that claim they accept a
"location", actually end up working with multiple locations, and the
manual doesn't explain that all that well. In some cases, the command
will work with all the resolved locations. In other cases, the
command aborts with an error if the location specification resolves to
multiple locations in the program. In other cases, GDB just
arbitrarily and silently picks whatever is the first resolved code
location (which sounds like should be improved).
To clarify this, I propose we use the term "Location Specification",
with shorthand "locaction spec", when we're talking about the user
input, the argument or arguments that is/are passed to commands to
instruct GDB how to find locations of interest. This is distinct from
the actual code locations in the program, which are what GDB finds
based on the user-specified location spec. Then use "location
specification or the shorter "location spec" thoughout instead of
"location" when we're talking about the user input.
Thus, this commit does the following:
- renames the "Specify Location" section of the manual to "Location
Specifications".
- It then introduces the term "Location Specification", with
corresponding shorthand "location spec", as something distinct from
an actual code location in the program. It explains what a concrete
code location is. It explains that a location specification may be
incomplete, and that may match multiple code locations in the
program, or no code location at all. It gives examples. Some
pre-existing examples were moved from the "Set Breaks" section, and
a few new ones that didn't exist yet were added. I think it is
better to have these centralized in this "Location Specification"
section, since all the other commands that accept a location spec
have an xref that points there.
- Goes through the manual, and where "@var{location}" was used for a
command argument, updated it to say "@var{locspec}" instead. At the
same time, tweaks the description of the affected commands to
describe what happens when the location spec resolves to more than
one location. Most commands just did not say anything about that.
One command -- "maint agent -at @var{location}" -- currently says it
accepts a "location", suggesting it can accept address and explicit
locations too, but that's incorrect. In reality, it only accepts
linespecs, so fix it accordingly.
One MI command -- "-trace-find line" -- currently says it accepts a
"line specification", but it can accept address and explicit
locations too, so fix it accordingly.
Special thanks goes to Eli Zaretskii for reviews and rewording
suggestions.
Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
|
|
Doing a 32-bit build with "--enable-targets=all --disable-sim" fails to link
properly.
--
loongarch-tdep.o: In function `loongarch_gdbarch_init':
binutils-gdb/gdb/loongarch-tdep.c:443: undefined reference to `loongarch_r_normal_name'
loongarch-tdep.o: In function `loongarch_fetch_instruction':
binutils-gdb/gdb/loongarch-tdep.c:37: undefined reference to `loongarch_insn_length'
loongarch-tdep.o: In function `loongarch_scan_prologue(gdbarch*, unsigned long long, unsigned long long, frame_info*, trad_frame_cache*) [clone .isra.4]':
binutils-gdb/gdb/loongarch-tdep.c:87: undefined reference to `loongarch_insn_length'
binutils-gdb/gdb/loongarch-tdep.c:88: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:89: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:90: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:91: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:92: undefined reference to `loongarch_decode_imm'
--
Given the list of 64-bit BFD files in
opcodes/Makefile.am:TARGET64_LIBOPCODES_CFILES, it looks like GDB's
ALL_TARGET_OBS list is including files that should be included in
ALL_64_TARGET_OBS instead.
This patch accomplishes this and enables a 32-bit build with
"--enable-targets=all --disable-sim" to complete.
Moving the bpf, tilegx and loongarch files to the correct list means GDB can
find the correct disassembler function instead of finding a null pointer.
We still need the "--disable-sim" switch (or "--enable-64-bit-bfd") to
make a 32-bit build with "--enable-targets=all" complete correctly
|
|
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.
|
|
Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation
string in cmdpy_init (when creating a custom GDB command in Python).
I think this is all pretty straight forward, the only slight weirdness
is the removal of the call to free toward the end of this function.
Prior to this commit, if an exception was thrown after the GDB command
was created then we would (I think) end up freeing the documentation
string even though the command would remain registered with GDB, which
would surely lead to undefined behaviour.
After this commit we release the doc string at the point that we hand
it over to the command creation routines. If we throw _after_ the
command has been created within GDB then the doc string will be left
live. If we throw during the command creation itself (either from
add_prefix_cmd or add_cmd) then it is up to those functions to free
the doc string (I suspect we don't, but I think in general the
commands are pretty bad at cleaning up after themselves, so I don't
think this is a huge problem).
|
|
Luis noticed that "maint print arc" would crash, because the command
handler did not find "show" in the command name, violating an
invariant. This patch fixes the bug by changing the registration to
use add_basic_prefix_cmd instead.
|
|
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
|
|
Requiring C99 means that uses of bfd_uint64_t can be replaced with
uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
BFD_HOST_64_BIT. This patch does that, removes #ifdef BFD_HOST_*
and tidies a few places that print 64-bit values.
|
|
This fixes the build on older FreeBSD systems without support for
hardware breakpoints/watchpoints.
|
|
The previous patch ensured that partial symbols are read before calling
most of the quick_function's methods.
The psymbol_functions class has the require_partial_symbols method which
serves this exact purpose, and does not need to do it anymore.
This patch renames this method to partial_symbols and makes it an accessor
which asserts that partial symbols have been read at this point.
Regression tested on x86_64-linux.
|
|
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
|
|
After DWARF has been scanned, the cooked index code does a
"finalization" step in a worker thread. This step combines all the
index entries into a single master list, canonicalizes C++ names, and
splits Ada names to synthesize package names.
While this step is run in the background, gdb will wait for the
results in some situations, and it turns out that this step can be
slow. This is PR symtab/29105.
This can be sped up by parallelizing, at a small memory cost. Now
each index is finalized on its own, in a worker thread. The cost
comes from name canonicalization: if a given non-canonical name is
referred to by multiple indices, there will be N canonical copies (one
per index) rather than just one.
This requires changing the users of the index to iterate over multiple
results. However, this is easily done by introducing a new "chained
range" class.
When run on gdb itself, the memory cost seems rather low -- on my
current machine, "maint space 1" reports no change due to the patch.
For performance testing, using "maint time 1" and "file" will not show
correct results. That approach measures "time to next prompt", but
because the patch only affects background work, this shouldn't (and
doesn't) change. Instead, a simple way to make gdb wait for the
results is to set a breakpoint.
Before:
$ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \
-ex 'break main' /tmp/gdb
Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
2.00
After:
$ /bin/time -f%e ./gdb/gdb -nx -q -batch \
-ex 'break main' /tmp/gdb
Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
0.65
Regression tested on x86-64 Fedora 34.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
|
|
When accessing /proc/PID/mem, if pread64/pwrite64/read/write encounters
an error and return -1, linux_proc_xfer_memory_partial return
TARGET_XFER_EOF.
I think it should return TARGET_XFER_E_IO in this case. TARGET_XFER_EOF
is returned when pread64/pwrite64/read/frite returns 0, which indicates
that the address space is gone and the whole process has exited or
execed.
This patch makes this change.
Regression tested on x86_64-linux-gnu.
Change-Id: I6030412459663b8d7933483fdda22a6c2c5d7221
|
|
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
|
|
LOONGARCH_LINUX_NUM_GREGSET should be defined as 45 (32 + 1 + 1 + 11)
due to reserved 11 for extension in glibc, otherwise when execute:
make check-gdb TESTS="gdb.base/corefile.exp"
there exists the following failed testcase:
(gdb) core-file /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
[New LWP 7742]
warning: Unexpected size of section `.reg/7742' in core file.
Core was generated by `/home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile'.
Program terminated with signal SIGABRT, Aborted.
warning: Unexpected size of section `.reg/7742' in core file.
#0 0x000000fff76f4e24 in raise () from /lib/loongarch64-linux-gnu/libc.so.6
(gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This small patch adds support for TYPE_CODE_DECFLOAT in
aapcs_is_vfp_call_or_return_candidate_1 and pass_in_v_vfp_candidate,
so that GDB for AArch64 knows how to pass DFP parameters and how to
read DFP results when calling a function.
Tested on aarch64-linux-gnu, with a GCC with DFP support in the PATH,
all of GDB's DFP tests pass.
|
|
Move the specialization into an explicit std namespace to workaround a
bug in older compilers. GCC 6.4.1 at least fails to compile the previous
version with the following error:
gdb/arch/aarch64.h:48:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive]
struct std::hash<aarch64_features>
|
|
Define a constant for the number of registers stored in a register set
and use this with register_size to compute the size of the
general-purpose register set in core dumps.
This also fixes the build on hosts such as FreeBSD that do not define
an elf_gregset_t type.
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/auxv.exp"
there exist the following unsupported and failed testcases:
UNSUPPORTED: gdb.base/auxv.exp: gcore
FAIL: gdb.base/auxv.exp: load core file for info auxv on native core dump
FAIL: gdb.base/auxv.exp: info auxv on native core dump
FAIL: gdb.base/auxv.exp: matching auxv data from live and core
UNSUPPORTED: gdb.base/auxv.exp: info auxv on gcore-created dump
UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and gcore
we can see the following messages in gdb/testsuite/gdb.log:
gcore /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/auxv/auxv.gcore
Target does not support core file generation.
(gdb) UNSUPPORTED: gdb.base/auxv.exp: gcore
In order to fix the above issues, implement the iterate_over_regset_sections
gdbarch method to iterate over core file register note sections on LoongArch.
By the way, with this patch, the failed testcases in gdb.base/corefile.exp
and gdb.base/gcore.exp can also be fixed.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
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.
|
|
This test in test-case gdb.ada/dynamic-iface.exp passes with gcc 8:
...
(gdb) print obj^M
$1 = (n => 3, a => "ABC", value => 93)^M
(gdb) PASS: gdb.ada/dynamic-iface.exp: print local as interface
...
but fails with gcc 7:
...
(gdb) print obj^M
$1 = ()^M
(gdb) FAIL: gdb.ada/dynamic-iface.exp: print local as interface
...
More concretely, we have trouble finding the type of obj. With gcc 8:
...
$ gdb -q -batch main -ex "b concrete.adb:20" -ex run -ex "ptype obj"
...
type = <ref> new concrete.intermediate with record
value: integer;
end record
...
and with gcc 7:
...
type = <ref> tagged record null; end record
...
The translation from tagged type to "full view" type happens in
ada_tag_value_at_base_address, where we hit this code:
...
/* Storage_Offset'Last is used to indicate that a dynamic offset to
top is used. In this situation the offset is stored just after
the tag, in the object itself. */
if (offset_to_top == last)
{
struct value *tem = value_addr (tag);
tem = value_ptradd (tem, 1);
tem = value_cast (ptr_type, tem);
offset_to_top = value_as_long (value_ind (tem));
}
...
resulting in an offset_to_top for gcc 8:
...
(gdb) p offset_to_top
$1 = -16
...
and for gcc 7:
...
(gdb) p offset_to_top
$1 = 16
...
The difference is expected, it bisects to gcc commit d0567dc0dbf ("[multiple
changes]") which mentions this change.
There's some code right after the code quoted above that deals with this
change:
...
else if (offset_to_top > 0)
{
/* OFFSET_TO_TOP used to be a positive value to be subtracted
from the base address. This was however incompatible with
C++ dispatch table: C++ uses a *negative* value to *add*
to the base address. Ada's convention has therefore been
changed in GNAT 19.0w 20171023: since then, C++ and Ada
use the same convention. Here, we support both cases by
checking the sign of OFFSET_TO_TOP. */
offset_to_top = -offset_to_top;
}
...
but it's not activated because of the 'else'.
Fix this by removing the 'else'.
Tested on x86_64-linux, with gcc 7.5.0.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29057
|
