This introduces c_value_print_inner, which implements the
la_value_print_inner method for the C family of languages. In this
patch, it is just a simple wrapper of c_val_print. However,
subsequent patches will convert it to use the value API. The
transformation is done this way to make each patch easier to review.
Future patches will apply this same treatment to other languages as
well.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* opencl-lang.c (opencl_language_defn): Use c_value_print_inner.
* objc-lang.c (objc_language_defn): Use c_value_print_inner.
* c-valprint.c (c_value_print_inner): New function.
* c-lang.h (c_value_print_inner): Declare.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Use
c_value_print_inner.
pascal_object_print_value_fields is only needed in p-valprint.c, so
make it static.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value_fields): Now static.
* p-lang.h (pascal_object_print_value_fields): Don't declare.
This slightly simplifies c_val_print_array by moving a variable to a
more inner scope and removing a dead assignment.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_val_print_array): Simplify.
This introduces value_print_array_elements, which is an analogue of
val_print_array_elements that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print_array_elements): New function.
* valprint.h (value_print_array_elements): Declare.
A couple of spots could be easily converted to use
value_print_scalar_formatted. This patch makes this change.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* printcmd.c (print_formatted): Use value_print_scalar_formatted.
* mips-tdep.c (mips_print_register): Use
value_print_scalar_formatted.
This introduces a value_print_scalar_formatted, which is an analogue
of val_print_scalar_formatted that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (value_print_scalar_formatted): Declare.
* valprint.c (value_print_scalar_formatted): New function.
This introduces generic_value_print, which is a value-based analogue
to generic_val_print. For now this is unused and simply calls
generic_val_print, but subsequent patches will both change this
function to work using the value API directly, and convert callers of
generic_val_print to call this instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (generic_value_print): Declare.
* valprint.c (generic_value_print): New function.
The plan for removing val_print is, essentially, to first duplicate
printing code as needed to use the value API; and then remove the
val_print code. This makes it possible to do the changes
incrementally while keeping everything working.
This adds a new la_value_print_inner function pointer to struct
language_defn. Eventually this will replace la_val_print. This patch
also changes printing to prefer this API, when available -- but no
language defines it yet.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Call la_value_print_inner, if
available.
* rust-lang.c (rust_language_defn): Update.
* p-lang.c (pascal_language_defn): Update.
* opencl-lang.c (opencl_language_defn): Update.
* objc-lang.c (objc_language_defn): Update.
* m2-lang.c (m2_language_defn): Update.
* language.h (struct language_defn) <la_value_print_inner>: New
member.
* language.c (unknown_language_defn, auto_language_defn): Update.
* go-lang.c (go_language_defn): Update.
* f-lang.c (f_language_defn): Update.
* d-lang.c (d_language_defn): Update.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Update.
* ada-lang.c (ada_language_defn): Update.
This changes c_value_print to call common_val_print. This is more
complicated than the usual sort of common_val_print change, due to the
handling of RTTI.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print): Use common_val_print.
gdb/testsuite/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* gdb.base/printcmds.exp (test_print_strings): Add regression
test.
* gdb.base/printcmds.c (charptr): New typedef.
(teststring2): New global.
This changes a spot in cp-valprint.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* cp-valprint.c (cp_print_static_field): Use common_val_print.
This changes a couple spots in f-valprint.c to use common_val_print
rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* f-valprint.c (f77_print_array_1, f_val_print): Use
common_val_print.
This changes some spots in riscv-tdep.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* riscv-tdep.c (riscv_print_one_register_info): Use
common_val_print.
This changes a spot in mi-main.c to use common_val_print rather than
val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* mi/mi-main.c (output_register): Use common_val_print.
This changes some spots in infcmd.c to use common_val_print (which,
despite its name, is a value-based API) rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* infcmd.c (default_print_one_register_info): Use
common_val_print.
A (much) later patch will remove the call to value_check_printable
from common_val_print. This will needed to preserve some details of
how optimized-out structures are printed.
However, doing this will also break dw2-op-out-param.exp. Making the
change causes "bt" to print:
However, the test wants to see:
... operand2=<optimized out>
That is, a wholly-optimized out structure should not print its fields.
So, this patch introduces a new common_val_print_checked, which calls
value_check_printable first, and then arranges to use it in the one
spot that affects the test suite.
I was not completely sure if it would be preferable to change the
test. However, I reasoned that, assuming this output was intentional
in the first place, in a backtrace space is at a premium and so this
is a reasonable approach. In other spots calling common_val_print,
this behavior is probably unintended, or at least a "don't care".
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (common_val_print_checked): Declare.
* valprint.c (common_val_print_checked): New function.
* stack.c (print_frame_arg): Use common_val_print_checked.
This changes val_print and common_val_print to use a new helper
function. A theme in the coming patches is that calls to val_print
itself should be removed. This is the first such patch; at the end of
the series, we'll remove val_print and simplify do_val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): New function, from val_print.
(val_print): Use do_val_print.
(common_val_print): Use do_val_print.
Switching the low-level printing to use the value API means we will be
using more temporary values. This adds a scoped_value_mark to
value_print, so that these intermediates are destroyed in a timely
way.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print): Use scoped_value_mark.
Consider test-case gdb.dwarf2/imported-unit.exp.
It contains a CU with type int:
...
<0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
<12a> DW_AT_language : 4 (C++)
<12b> DW_AT_name : imported_unit.c
<1><13b>: Abbrev Number: 3 (DW_TAG_base_type)
<13c> DW_AT_byte_size : 4
<13d> DW_AT_encoding : 5 (signed)
<13e> DW_AT_name : int
...
which is imported in another CU:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
<d3> DW_AT_language : 4 (C++)
<d4> DW_AT_name : <artificial>
<1><e1>: Abbrev Number: 3 (DW_TAG_imported_unit)
<e2> DW_AT_import : <0x129> [Abbrev Number: 2]
...
However, if we print the partial symbols:
...
$ gdb -batch imported-unit -ex "maint print psymbols"
...
we see type int both in the importing CU:
...
Partial symtab for source file <artificial>@0xc7 (object 0x29f9b80)
...
Depends on 1 other partial symtabs.
0 0x2a24240 imported_unit.c
Global partial symbols:
`main', function, 0x4004b2
Static partial symbols:
`int', type, 0x0
...
and in the imported CU:
...
Partial symtab for source file imported_unit.c (object 0x2a24240)
...
Depends on 0 other partial symtabs.
Shared partial symtab with user 0x29f9b80
Static partial symbols:
`int', type, 0x0
...
This is an artefact resulting from the fact that all CUs in an objfile
share the same storage array for static partial symbols (and another array for
global partial symbols), using a range to describe their symbols.
Then when scanning the partial symbols of a CU and encountering an import, either:
- the referred CU has not been parsed yet, and will be parsed, and the range of
static partial symbols of the referred CU will be a subrange of the range of
static partial symbols of this CU, or
- the referred CU has already been parsed, and the range of static partial
symbols of the referred CU will not be a subrange of the range of static
partial symbols of this CU.
This is inconsistent handling, and confuses the notion of a symbol belonging to
a single symtab.
Furthermore, it might slow down searches, given that the symbol needs to be
skipped twice.
Finally, the same issue holds for global partial symbols, where the range of a
CU is sorted after parsing is finished. Obviously sorting the range of a CU
may invalidate subranges, effectively moving symbols in and out of imported
CUs.
Fix this for both static and global partial symbols, by gathering partial
symbols in a per-CU vector, and adding those symbols to the per-objfile
storage only once complete.
Tested on x86_64-linux, with native and board cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* psymtab.c (partial_symtab::partial_symtab): Don't set
globals_offset and statics_offset. Push element onto
current_global_psymbols and current_static_psymbols stacks.
(concat): New function.
(end_psymtab_common): Set globals_offset and statics_offset. Pop
element from current_global_psymbols and current_static_psymbols
stacks. Concat popped elements to global_psymbols and
static_symbols.
(add_psymbol_to_list): Use current_global_psymbols and
current_static_psymbols stacks.
* psymtab.h (class psymtab_storage): Add current_global_psymbols and
current_static_psymbols fields.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* gdb.dwarf2/imported-unit.exp: Add test.
There are no more callers to deprecated_add_core_fns, now that I have
removed the usage from CRIS and ARM/NetBSD. So this patch cleans up
all the related code and makes corelow.c a lot more readable.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* corelow.c (sniff_core_bfd): Remove.
(class core_target) <m_core_vec>: Remove.
(core_target::core_target): Update.
(core_file_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(sniff_core_bfd): Remove.
(default_check_format): Remove.
(gdb_check_format): Remove.
(core_target_open): Update.
(core_target::get_core_register_section): Update.
(get_core_registers_cb): Update.
(core_target::fetch_registers): Update.
* gdbcore.h (struct core_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(default_check_format): Remove.
Some arm-tdep.c data structures use a bfd_vma. A couple of spots will
warn about an implicit narrowing cast when building a gdb where
CORE_ADDR is 64-bit but bfd_vma is 32-bit.
This patch silences these warnings by changing the types in question
to CORE_ADDR.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* arm-tdep.c (struct arm_mapping_symbol) <value>: Now a
CORE_ADDR.
(struct arm_exidx_entry) <addr>: Now a CORE_ADDR.
A few spots in gdb use sprintf_vma to print a CORE_ADDR. This will
fail on a 32-bit build once CORE_ADDR is always a 64-bit type.
This patch replaces these calls with phex instead.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* remote.c (remote_target::download_tracepoint)
(remote_target::enable_tracepoint)
(remote_target::disable_tracepoint): Use phex, not sprintf_vma.
* breakpoint.c (print_recreate_masked_watchpoint): Use phex, not
sprintf_vma.
symfile-mem.c has some assertions about the size of various types, to
ensure that gdb and BFD don't get out of sync in a way that would
cause bugs.
Once CORE_ADDR is always 64-bit, one of these assertions can fail for
a 32-bit BFD build. However, the real requirement here is just that
CORE_ADDR is wider -- because this code promotes a bfd_vma to a
CORE_ADDR.
This patch corrects the assert.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* symfile-mem.c: Update CORE_ADDR size assert.
The selftest.m4 file is used by gdb, gdbserver and gdbsupport, I think
it belongs in gdbsupport.
gdb/ChangeLog:
* selftest.m4: Move to gdbsupport/.
* acinclude.m4: Update path to selftest.m4.
gdbserver/ChangeLog:
* acinclude.m4: Update path to selftest.m4.
gdbsupport/ChangeLog:
* selftest.m4: Moved from gdb/.
* acinclude.m4: Update path to selftest.m4.
While working on the preceding selftests patches, I noticed that some
selftests-specific files are included in the build even when selftests
are disabled, namely disasm-selftest.c and gdbarch-selftests.c. These
files are entirely #if'ed out when building with selftests disabled.
This is not a huge problem, but I think it would make more sense if
these files were simply not built.
With this patch, I propose to put all the selftests-specific source
files into a SELFTESTS_SRCS Makefile variable (even selftest-arch.c,
which is currently added by the configure script).
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Rename to...
(SELFTESTS_SRCS): ... this. Add disasm-selftests.c,
gdbarch-selfselftests.c and selftest-arch.c.
(SUBDIR_UNITTESTS_OBS): Rename to...
(SELFTESTS_OBS): ... this.
(COMMON_SFILES): Remove disasm-selftests.c and
gdbarch-selftests.c.
* configure.ac: Don't add selftest-arch.{c,o} to
CONFIG_{SRCS,OBS}.
* disasm-selftests.c, gdbarch-selftests.c: Remove GDB_SELF_TEST
preprocessor conditions.
The same is done for gdb, gdbserver and gdbsupport. I therefore think
it makes sense to move that to GDB_AC_COMMON.
It is required to move the call to GDB_AC_COMMON so it is before
GDB_AC_SELFTEST in gdbserver/configure.ac, otherwise the $development
variable isn't set when the code behind GDB_AC_SELFTEST executes.
gdb/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* selftest.m4: Modify comment.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Don't source bfd/development.sh, move
GDB_AC_COMMON higher.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* common.m4: Source bfd/development.sh.
* configure: Re-generate.
Before commit 3d1e5a43cb ("gdbsupport/configure.ac: source
development.sh"), the GDB build in non-development mode (turn
development to false in bfd/development.sh if you want to try) was
broken because the gdbsupport configure script didn't source
bfd/development.sh to set the development variable.
Since the GDB_AC_SELFTEST macro relies on the `development` variable, I
propose to modify it such that it errors out if $development does not
have an expected value of "true" or "false". This could prevent a
future similar problem from happening while refactoring the configure
scripts. It would have caught the problem fixed by the patch mentioned
earlier.
gdb/ChangeLog:
* selftest.m4 (GDB_AC_SELFTEST): Error out if $development is
not "true" or "false".
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
This is in preparation for deleting deprecated_add_core_fns and
related code.
As a side-effect, this makes it possible to read NetBSD/ARM
core files on non-NetBSD/ARM platforms, subject to PR corefiles/25638.
I have removed this comment:
- /* This is ok: we're running native... */
Since we are using the gdbarch from the regcache, we should be
guaranteed to be calling the right function here, so it shouldn't
matter whether we are running native.
Tested by reading a NetBSD/ARM core file on Linux/x86-64 and NetBSD/ARM;
the "info registers" output matches the one from the system GDB.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* Makefile.in (HFILES_NO_SRCDIR): Add new arm-nbsd-tdep.h file.
* arm-nbsd-nat.c (arm_supply_gregset): Moved to arm-nbsd-tdep and
renamed to arm_nbsd_supply_gregset.
(fetch_register): Update to call arm_nbsd_supply_gregset.
(fetch_regs): Remove in favor of fetch_register with a -1 regno.
(arm_netbsd_nat_target::fetch_registers): Update.
(fetch_elfcore_registers): Removed.
(_initialize_arm_netbsd_nat): Removed call to deprecated_add_core_fns.
* arm-nbsd-tdep.c (struct arm_nbsd_reg): New struct.
(arm_nbsd_supply_gregset): Moved from arm-nbsd-nat.c and updated to
not require NetBSD system headers.
(arm_nbsd_regset): New struct.
(arm_nbsd_iterate_over_regset_sections): New function.
(arm_netbsd_init_abi_common): Updated to call
set_gdbarch_iterate_over_regset_sections.
* arm-nbsd-tdep.h: New file.
A patch somewhat like this patch has been in Fedora GDB for well over
a decade. The Fedora patch was written by Jan Kratochvil. The Fedora
version prints a warning and attempts to continue. This version will
error out, fatally. An earlier version of this patch was more like
the Fedora version than this one. Simon Marchi recommended use of an
assertion to test for the infinite recursion; I decided to use an
explicit test (with an "if" statement) along with a call to
internal_error() if the condition is met. This way, I could include
a plea to file a bug report.
It was motivated by a customer reported bug (back in 2006!) which
showed infinite mutual recursion between find_pc_sect_line and
find_pc_line. Here is a portion of the backtrace from the bug report:
(gdb) bt
#0 0x00000000004450a4 in lookup_minimal_symbol_by_pc_section (
pc=251700325328, section=0x570f500) at gdb/minsyms.c:484
#1 0x00000000004bbfb2 in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2057
#2 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#3 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
... (lots and lots of the same two functions with the same parameters)
#1070 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1071 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
#1072 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1073 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
#1074 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
#1075 0x00000000004bc1ff in find_pc_sect_line (pc=251696794399,
section=0x59b0df8, notcurrent=0) at gdb/symtab.c:2081
#1076 0x00000000004bc480 in find_pc_line (pc=251696794399, notcurrent=0)
at gdb/symtab.c:2232
#1077 0x000000000055550e in find_frame_sal (frame=0xb3f3e0, sal=0x7fff1d1a8200)
at gdb/frame.c:1392
#1078 0x00000000004d86fd in set_current_sal_from_frame (frame=0x1648, center=1)
at gdb/stack.c:379
#1079 0x00000000004cf137 in normal_stop () at gdb/infrun.c:3147
...
The test case was a large application. Attempts were made to make a
small(er) test case, but those attempts were not successful.
Therefore, I cannot provide a new test for this patch.
That said, we ought to guard against recursively calling
find_pc_sect_line (via find_pc_line) with the identical PC value that
it had been called with. Should this happen, infinite recursion (as
shown in the above backtrace) is the result. This patch prevents
that from happening.
If this should happens, there is a bug somewhere, perhaps in GDB, perhaps
in some other part of the toolchain or a library. We error out fatally
with a message briefly describing the condition along with a plea to file
a bug report.
I spent some time looking at the surrounding code and commentary which
handle the case of PC being in a stub/trampoline. It first appeared
in the public GDB repository in April, 1999. The ChangeLog entry for
this commit is from 1998-12-31. The relevant portion is:
(find_pc_sect_line): Return correct information if pc is in import
or export stub (trampoline).
What's remarkable about the overall ChangeLog entry is that it's over
2500+ lines long! I believe that this was part of the infamous "HP
merge" (in which insufficient due diligence was given in accepting
a large batch of changes from an outside source). In the years that
followed, much of this code was either significantly revised or
outright removed.
For this particular case, I'm grateful that extensive comments were
provided by "RT". (I haven't been able to figure out who RT is/was.)
I've decided against attempting to revise this stub/trampoline handling
code any further than adding Jan's test which prevents an obvious case
of infinite recursion.
I've tested on Fedora 31, x86-64. I see no regressions. I've also
searched the logfile for the new message, but as expected, no message
was found (which is good).
gdb/ChangeLog:
* symtab.c (find_pc_sect_line): Add check which prevents infinite
recursion.
Change-Id: I595470be6ab5f61ca7e4e9e70c61a252c0deaeaa
While compiling with clang, I noticed it didn't catch cases where my
function declaration didn't match my function definition. This is
normally caught by gcc with -Wmissing-declarations.
On clang, this is caught by -Wmissing-prototypes instead.
Note that on gcc, -Wmissing-prototypes also exists, but is only valid
for C and Objective-C. It gets correctly rejected by the configure
script since gcc rejects it with:
cc1plus: error: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ -Werror
So this warning flag ends up not used for gcc (which is what we want).
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* warning.m4: Enable -Wmissing-prototypes.
A comment in ada-typeprint.c mentions the Unchecked_Variant pragma.
However, this does not exist, and the comment should actually mention
Unchecked_Union.
gdb/ChangeLog
2020-03-11 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (print_choices): Fix comment.
This commit:
commit 8c95582da8
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
Introduced an invalid memory access, by reading outside the bounds of
an array.
This would cause this valgrind error:
==7633== Invalid read of size 4
==7633== at 0x4D002C: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:688)
==7633== by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
==7633== by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
==7633== by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
==7633== by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
==7633== by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
==7633== by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
==7633== by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
==7633== by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
==7633== by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)
==7633== by 0x5DAB58: process_queue(dwarf2_per_objfile*) (read.c:8867)
==7633== by 0x5CB30E: dw2_do_instantiate_symtab(dwarf2_per_cu_data*, bool) (read.c:2374)
==7633== Address 0xa467f48 is 8 bytes before a block of size 16,024 alloc'd
==7633== at 0x4C2CDCB: malloc (vg_replace_malloc.c:299)
==7633== by 0x451FC4: xmalloc (alloc.c:60)
==7633== by 0x4CFFDF: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:678)
==7633== by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
==7633== by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
==7633== by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
==7633== by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
==7633== by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
==7633== by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
==7633== by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
==7633== by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
==7633== by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)
gdb/ChangeLog:
* buildsyms.c (buildsym_compunit::record_line): Avoid accessing
previous item in the list, when the list has no items.
When using the executable from test-case gdb.ada/access_to_packed_array.exp
(read-in using -readnow) and printing the symbols using "maint print symbols",
we run into a segv:
...
$ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols"
...
info: array (<>) of character; computed at runtime
ptr: range 0 .. 2147483647; computed at runtime
Aborted (core dumped)
...
What happens is that dwarf2_evaluate_property gets called and sets the local
frame variable to the current frame, which happens to be NULL. Subsequently
the PROP_LOCLIST handling code is executed, where get_frame_address_in_block
gets called with argument NULL, and the segv is triggered.
Fix this by handling a NULL frame in the PROP_LOCLIST handling code in
dwarf2_evaluate_property.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in
PROP_LOCLIST handling code.
gdb/testsuite/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* gdb.ada/access_to_packed_array.exp: Test printing of expanded
symtabs.
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
Gcc supports an option -feliminate-dwarf2-dups (up until gcc-7, removed in
gcc-8).
When running tests with target board unix/-feliminate-dwarf2-dups, we run
into:
...
(gdb) PASS: gdb.ada/arraydim.exp: print m'length(3)
ptype global_3dim_for_gdb_testing^M
type = array (Unexpected type in ada_discrete_type_low_bound.^M
(gdb) FAIL: gdb.ada/arraydim.exp: ptype global_3dim_for_gdb_testing
...
The DWARF for the variable global_3dim_for_gdb_testing looks as follows:
...
<0><824>: Abbrev Number: 1 (DW_TAG_compile_unit)
<825> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><832>: Abbrev Number: 2 (DW_TAG_array_type)
<833> DW_AT_type : <0x874>
<2><837>: Abbrev Number: 3 (DW_TAG_subrange_type)
<838> DW_AT_type : <0x84a>
<83c> DW_AT_upper_bound : 0
<2><83d>: Abbrev Number: 3 (DW_TAG_subrange_type)
<83e> DW_AT_type : <0x84a>
<842> DW_AT_upper_bound : 1
<2><843>: Abbrev Number: 3 (DW_TAG_subrange_type)
<844> DW_AT_type : <0x84a>
<848> DW_AT_upper_bound : 2
<2><849>: Abbrev Number: 0
<1><84a>: Abbrev Number: 4 (DW_TAG_typedef)
<84b> DW_AT_type : <0x86d>
<1><84f>: Abbrev Number: 0
<0><85b>: Abbrev Number: 5 (DW_TAG_compile_unit)
<861> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><86d>: Abbrev Number: 6 (DW_TAG_base_type)
<86e> DW_AT_byte_size : 8
<86f> DW_AT_encoding : 7 (unsigned)
<870> DW_AT_name : long unsigned int
<1><874>: Abbrev Number: 7 (DW_TAG_base_type)
<875> DW_AT_byte_size : 4
<876> DW_AT_encoding : 5 (signed)
<877> DW_AT_name : int
<1><87b>: Abbrev Number: 8 (DW_TAG_variable)
<87c> DW_AT_name : global_3dim_for_gdb_testing
<882> DW_AT_type : <0x832>
<886> DW_AT_external : 1
...
The DWARF contains an anonymous typedef at 0x84a, referring to 0x86d.
Strictly speaking, the anonymous typedef is illegal DWARF, because a
DW_TAG_typedef is defined to have an DW_AT_name attribute containing the name
of the typedef as it appears in the source program.
The DWARF reading code creates a corresponding type for this typedef, which
goes on to confuse the code handling arrays.
Rather than trying to support the type representing this anonymous typedef in
all the locations where it causes problems, fix this by treating the anonymous
typedef as a forwarder DIE in the DWARF reader.
Tested on x86_64-linux, with target boards unix and
unix/-feliminate-dwarf2-dups.
This fixes ~85 failures for unix/-feliminate-dwarf2-dups.
gdb/ChangeLog:
2020-03-07 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (read_typedef): Treat anonymous typedef as forwarder
DIE.
While working on complex number support, I found a couple of
apparently obsolete coments. This removes them.
2020-03-07 Tom Tromey <tom@tromey.com>
* valops.c (value_literal_complex): Remove obsolete comment.
* gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete
comment.
[ Migrating this from Gerrit: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/321 ]
I noticed that some functions in infcmd and infrun call each other and
all call inferior_thread, while they could just get the thread_info
pointer from their caller. That means less calls to inferior_thread, so
less reliance on global state, since inferior_thread reads
inferior_ptid.
The paths I am unsure about are:
- fetch_inferior_event calls...
- step_command_fsm::should_stop calls...
- prepare_one_step
and
- process_event_stop_test calls...
- set_step_info
Before this patch, prepare_one_step gets the thread pointer using
inferior_thread. After this patch, it gets it from the
execution_control_state structure in fetch_inferior_event. Are we sure
that the thread from the execution_control_state structure is the same
as the one inferior_thread would return? This code path is used when a
thread completes a step, but the user had specified a step count (e.g.
"step 5") so we decide to do one more step. It would be strange (and
even a bug I suppose) if the thread in the ecs structure in
fetch_inferior_event was not the same thread that is prepared to stepped
by prepare_one_step. So I believe passing the ecs thread is fine.
The same logic applies to process_event_stop_test calling
set_step_info.
gdb/ChangeLog:
* infrun.h: Forward-declare thread_info.
(set_step_info): Add thread_info parameter, add doc.
* infrun.c (set_step_info): Add thread_info parameter, move doc
to header.
* infrun.c (process_event_stop_test): Pass thread to
set_step_info call.
* infcmd.c (set_step_frame): Add thread_info pointer, pass it to
set_step_info.
(prepare_one_step): Add thread_info parameter, pass it to
set_step_frame and prepare_one_step (recursive) call.
(step_1): Pass thread to prepare_one_step call.
(step_command_fsm::should_stop): Pass thread to
prepare_one_step.
(until_next_fsm): Pass thread to set_step_frame call.
(finish_command): Pass thread to set_step_info call.
The target_get_tib_address call always fails in this case, and there is an
error when changing the program with the file command:
(gdb) file allocer64.exe
Reading symbols from allocer64.exe...
You can't do that when your target is `exec'
Now it will skip this part, there is no need to rebase the executable without
an inferior anyways.
gdb/ChangeLog:
2020-03-06 Hannes Domani <ssbssa@yahoo.de>
* windows-tdep.c (windows_solib_create_inferior_hook):
Check if inferior is running.
Replace "the the" by "the".
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* NEWS: Fix "the the".
* ctfread.c: Same.
gdb/doc/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* gdb.texinfo: Fix "the the".
gdb/testsuite/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* README: Fix "the the".
* gdb.base/dprintf.exp: Same.
Using verbose, we get some detail on symbol loading:
...
$ gdb a.out -iex "set verbose on"
Reading symbols from a.out...
Reading in symbols for /home/vries/hello.c...done.
(gdb)
...
And using debug symtab-create, much more detail:
...
$ gdb a.out -iex "set verbose on" -iex "set debug symtab-create 1"
Reading symbols from a.out...
Reading minimal symbols of objfile /data/gdb_versions/devel/lto/a.out ...
Installing 30 minimal symbols of objfile /data/gdb_versions/devel/lto/a.out.
Done reading minimal symbols.
Creating one or more psymtabs for objfile /data/gdb_versions/devel/lto/a.out ...
Created psymtab 0x35a3de0 for module ../sysdeps/x86_64/start.S.
Created psymtab 0x353e4e0 for module init.c.
Created psymtab 0x353e560 for module ../sysdeps/x86_64/crti.S.
Created psymtab 0x353e5e0 for module /home/vries/hello.c.
Created psymtab 0x35bd530 for module elf-init.c.
Created psymtab 0x35bd5b0 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...Created compunit symtab 0x354bd20 for hello.c.
done.
(gdb)
...
The "Created compunit symtab" message gets inbetween the "Reading in symbols"
and the trailing "done.". [ Strictly speaking this is a regression since
commit faa17681cc "Make gdb_flush also flush the wrap buffer", but the
same problem happens when using -batch before this commit. ]
Fix this by removing the trailing "done." altogether, such that we get:
...
Created psymtab 0x3590520 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...
Created compunit symtab 0x359dd20 for hello.c.
(gdb)
...
[ Alternatively, we could fix this emitting a "Done reading in symbols" line
or some such, like is done for minimal symbols. See above. ]
[ Note: Removing the trailing "done." for the "Reading symbols from" message
was done in commit 3453e7e409 'Clean up "Reading symbols" output'. ]
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* psymtab.c (psymtab_to_symtab): Don't print "done.".
Copy the .dir-locls.el file from gdb/ to gdbserver/ and gdbsupport/ so
that we get the GNU/GDB style when editing these files in Emacs.
I initially wanted to remove the (c-mode . ((mode . c++))) that
switches c-mode files into c++-mode as we store C++ code in *.cc files
in the gdbserver/ directory, unlike gdb/ where we use *.c, however, I
was forgetting about the header files - we still use *.h for our C++
header files, so for now I left the settings in place to open all C
files in c++-mode.
We now have three copies of this file, which are all identical. It
would be nice if we could remove this duplication, however, for now we
haven't found a good way to do this.
Some options considered were:
1. Use symlinks to only have one copy of the file. This was
rejected as not all targets support symlinks in the way.
2. Have two of the .dir-locals.el files contain some mechanism by
which the third copy of the file is sourced. Though this would, in
theory, be possible, it would involve some advanced Emacs scripting,
would be fragile, and a maintenance burdon.
3. Move the .dir-locals up into top level src/ directory, then use
Emacs dir-locals directory pattern matching to only apply the rules
for the three directories we care about. The problem is that each
directory has to be listed separately, so we still end up having to
duplicate all the rules.
In the end, it was decided that having three copies of the file,
though not ideal, is probably easiest for now. This was all discussed
in this mailing list thread:
https://sourceware.org/ml/gdb-patches/2020-03/msg00024.html
The copyright date in the new files is left as for gdb/.dir-locals.el,
as the new files are a copy of the old, this is inline with this rule:
https://sourceware.org/gdb/wiki/ContributionChecklist#Copyright_Header
gdb/ChangeLog:
* .dir-locals.el: Add a comment referencing the other copies of
this file.
gdbserver/ChangeLog:
* .dir-locals.el: New file.
gdbsupport/ChangeLog:
* .dir-locals.el: New file.
Create .gitattributes files in gdb/, gdbserver/, and gdbsupport/.
The files specify cpp-style diffs for .h and .c files. This is
particularly helpful if a class in a header file is modified.
For instance, if the `stop_requested` field of `thread_info` in
gdb/gdbthread.h is modified, we get the following diff with
'git diff' (using git version 2.17.1):
@@ -379,7 +379,7 @@ public:
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
Note that the context of the change shows up as 'public:'; not so
useful. With the .gitattributes file, we get:
@@ -379,7 +379,7 @@ class thread_info : public refcounted_object
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
The context is successfully shown as 'class thread_info'.
This patch creates a .gitattributes file per each of gdb, gdbserver,
and gdbsupport folders. An alternative would be to define the
attributes in the root folder -- this would impact all the top-level
folders, though. I opted for the more conservative approach.
gdb/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbserver/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbsupport/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
This introduces a string cache on the per-BFD object, replacing the
macro and filename caches. Both of these caches just store strings,
so this consolidation by itself saves a little memory (about the size
of a bcache per objfile).
Then this patch switches some allocations on the objfile obstack to
use this bcache instead. This saves more space; and turns out to be a
bit faster as well.
Here are the before and after "maint time" + "maint space" results of
"file ./gdb":
Command execution time: 4.664021 (cpu), 4.728518 (wall)
Space used: 39190528 (+29212672 for this command)
Command execution time: 4.216209 (cpu), 4.107023 (wall)
Space used: 36667392 (+26689536 for this command)
The main interface to the string cache is a new pair of overloaded
methods, objfile::intern.
gdb/ChangeLog
2020-03-04 Tom Tromey <tom@tromey.com>
* symmisc.c (print_symbol_bcache_statistics)
(print_objfile_statistics): Update.
* symfile.c (allocate_symtab): Use intern.
* psymtab.c (partial_symtab::partial_symtab): Use intern.
* objfiles.h (struct objfile_per_bfd_storage) <filename_cache,
macro_cache>: Remove.
<string_cache>: New member.
(struct objfile) <intern>: New methods.
* elfread.c (elf_symtab_read): Use intern.
* dwarf2/read.c (fixup_go_packaging): Intern package name.
(dwarf2_compute_name, dwarf2_physname)
(create_dwo_unit_in_dwp_v1, create_dwo_unit_in_dwp_v2): Intern
names.
(guess_partial_die_structure_name): Update.
(partial_die_info::fixup): Intern name.
(dwarf2_canonicalize_name): Change parameter to objfile. Intern
name.
(dwarf2_name): Intern name. Update.
* buildsym.c (buildsym_compunit::get_macro_table): Use
string_cache.
I noticed that gnutarget was not "const". Since writing through this
pointer would probably be a bug, I think it ought to be. This patch
makes the change.
gdb/ChangeLog
2020-03-04 Tom Tromey <tom@tromey.com>
* jit.c (bfd_open_from_target_memory): Make "target" const.
* corefile.c (gnutarget): Now const.
* gdbcore.h (gnutarget): Now const.
Revert the change since it breaks existing behavior of "info registers"
for some architectures. At least AArch64 and ARM are impacted by this change.
gdb/ChangeLog:
2020-03-04 Luis Machado <luis.machado@linaro.org>
Revert aa66aac47b due to regressions
in "info registers" for AArch64/ARM.
The change caused "info registers" to not print GPR's.
gdb/ChangeLog:
2020-02-01 Shahab Vahedi <shahab@synopsys.com>
* target-descriptions.c (tdesc_register_in_reggroup_p): Return 0
when reg->group is empty and reggroup is not.
A customer reported a failure to unwind in a certain core dump. A
lengthy investigation showed that the problem came from the
interaction between the tailcall and inline frame sniffers.
Normally, the regular DWARF unwinder may discover a chain of tail
calls ending in the current frame. In this case, it sets a member on
the dwarf2_frame_cache object, so that a subsequent call into the
tailcall sniffer will create the tailcall frames.
However, in this scenario, what happened is that the DWARF unwinder
did find tailcall frames -- but then the PC of the first such frame
was recognized and claimed by the inline frame sniffer.
This then caused unwinding to go astray further up the stack.
This patch fixes the problem by arranging for the tailcall sniffer to
be called before the inline sniffer. This way, if a DWARF frame has
tailcall information, the tailcalls will always be processed first.
This is safe to do, because the tailcall sniffer can only claim a
frame if the previous frame did in fact find this information. (So,
for example, if no DWARF frame is ever found, then this sniffer will
never trigger.)
This patch also partially reverts:
commit 1ec56e88aa
Author: Pedro Alves <palves@redhat.com>
Date: Fri Nov 22 13:17:46 2013 +0000
Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer (move dwarf2_tailcall_sniffer_first elsewhere).
That patch moved the call to dwarf2_tailcall_sniffer_first out of
dwarf2_frame_cache, and into dwarf2_frame_prev_register. However, in
this situation, this is too late -- by the time
dwarf2_frame_prev_register is called, the frame in question is already
recognized by the inline frame sniffer.
Rather than fully revert that patch, though, this just arranges to
call dwarf2_tailcall_sniffer_first from dwarf2_frame_cache -- which is
called shortly after the DWARF frame sniffer succeeds, via
compute_frame_id.
I don't know how to write a test case for this.
gdb/ChangeLog
2020-03-03 Tom Tromey <tromey@adacore.com>
* dwarf2/frame.c (struct dwarf2_frame_cache)
<checked_tailcall_bottom, entry_cfa_sp_offset,
entry_cfa_sp_offset_p>: Remove members.
(dwarf2_frame_cache): Call dwarf2_tailcall_sniffer_first.
(dwarf2_frame_prev_register): Don't call
dwarf2_tailcall_sniffer_first.
(dwarf2_append_unwinders): Don't append tailcall unwinder.
* frame-unwind.c (add_unwinder): New fuction.
(frame_unwind_init): Use it. Add tailcall unwinder.
GDB is not able to print logical true values for Flang compiler.
Actual result:
(gdb) p l
$1 = 4294967295
Expected result:
(gdb) p l
$1 = .TRUE.
This is due to GDB expecting representation of true value being 1.
The Fortran standard doesnt specify how LOGICAL types are represented.
Different compilers use different non-zero values to represent logical
true. The gfortran compiler uses 1 to represent logical true and the
flang compiler uses -1. GDB should accept all the non-zero values as
true.
This is achieved by handling TYPE_CODE_BOOL in f_val_print and
printing any non-zero value as true.
gdb/ChangeLog:
* f-valprint.c (f_val_print): Handle TYPE_CODE_BOOL, any non-zero
value should be printed as true.
gdb/testsuite/ChangeLog:
* gdb.fortran/logical.exp: Add tests that any non-zero value is
printed as true.
Windows executables linked with -dynamicbase get a new base address
when loaded, which makes debugging impossible if the executable isn't
also rebased in gdb.
The new base address is read from the Process Environment Block.
gdb/ChangeLog:
2020-03-03 Hannes Domani <ssbssa@yahoo.de>
* windows-tdep.c (windows_solib_create_inferior_hook): New function.
(windows_init_abi): Set and use windows_so_ops.
Tom Tromey
Tom Tromey
Tom de Vries
Christian Biesinger
Simon Marchi
Kevin Buettner
Andrew Burgess
Simon Marchi
Hannes Domani
John Baldwin
Tankut Baris Aktemur
Luis Machado