This patch updates gdb/MAINTAINERS with ARC as a target and
myself as the maintainer. There is no mention of "-Werror"
because that is enabled by default for gdb/ targets now.
gdb/ChangeLog:
* MAINTAINERS: Add ARC target and maintainer.
ARC Linux targets differences from baremetal:
- No support for hardware single instruction stepping.
- Different access rules to registers.
- Use of another instruction for breakpoints.
v2: Changes after Tom's remarks [1]
arc-linux-tdep.c
- Use true/false instead of TRUE/FALSE.
- arc_linux_sw_breakpoint_from_kind (): Break long lines into two.
- arc_linux_sw_breakpoint_from_kind (): Remove starting blank line.
- Use explicit number evaluation, e.g: if (a & b) -> if ((a & b) != 0)
arc-tdep.c
- Use explicit number evaluation, e.g: if (a & b) -> if ((a & b) != 0)
gdb/configure.tgt
- arc*-*-linux*): Remove "build_gdbserver=yes".
v3: Changes after Simon's remarks [2]
arc-linux-tdep.c
- Use "return trap_size" instead of cryptic "return 2".
- Removed unnecessary curly braces.
- Removed "void" from "_initialize_arc_linux_tdep (void)".
v5: Changes after Simon's remarks [3]
- Remove unnecessary empty lines.
- Replace "breakpoint uses" with "breakpoints use" in a comment.
- "return condition;" i.s.o. "if (condition) return true; else return false;"
[1] Tom's remarks
https://sourceware.org/pipermail/gdb-patches/2020-April/167887.html
[2] Simon's remarks on v2
https://sourceware.org/pipermail/gdb-patches/2020-May/168513.html
[3] Simon's remarks on v4
https://sourceware.org/pipermail/gdb-patches/2020-August/170994.html
gdb/ChangeLog:
2020-08-25 Anton Kolesov <anton.kolesov@synopsys.com>
* configure.tgt: ARC support for GNU/Linux.
* Makefile.in (ALL_TARGET_OBJS): Likewise.
* arc-linux-tdep.c: New file.
* arc-tdep.h (ARC_STATUS32_L_MASK, ARC_STATUS32_DE_MASK): Declare.
* arc-tdep.c (arc_write_pc): Use it.
For ARC there are registers that are not part of a required set in XML
target descriptions by default, but are almost always present on ARC
targets and are universally exposed by the ptrace interface. Hardware
loop registers being one of them.
LP_START and LP_END auxiliary registers are hardware loop start and end.
Formally, they are optional, but it is hard to find an ARC configuration
that doesn't have them. They are always present in processors that can
run GNU/Linux. GDB needs to know about those registers to implement
proper software single stepping, since they affect what instruction
will be next.
This commit adds the code to check for the existance of "lp_start" and
"lp_end" in XML target descriptions. If they exist, then the function
reports that the target supports hardware loops.
gdb/ChangeLog:
* arc-tdep.c (arc_check_for_hardware_loop): New.
* arc-tdep.h (gdbarch_tdep): New field has_hw_loops.
gdb/doc/ChangeLog:
* gdb.texinfo (Synopsys ARC): Document LP_START, LP_END and BTA.
A few changes have been made to make the register support simpler,
more flexible and extendible. The trigger for most of these changes
are the remarks [1] made earlier for v2 of this patch. The noticeable
improvements are:
- The arc XML target features are placed under gdb/features/arc
- There are two cores (based on ISA) and one auxiliary feature:
v1-core: ARC600, ARC601, ARC700
v2-core: ARC EM, ARC HS
aux: common in both
- The XML target features represent a minimalistic sane set of
registers irrespective of application (baremetal or linux).
- A concept of "feature" class has been introduced in the code.
The "feature" object is constructed from BFD and GDBARCH data.
It contains necessary information (ISA and register size) to
determine which XML target feature to use.
- A new structure (ARC_REGISTER_FEATURE) is added that allows
providing index, names, and the necessity of registers. This
simplifies the sanity checks and future extendibility.
- Documnetation has been updated to reflect ARC features better.
- Although the feature names has changed, there still exists
backward compatibility with older names through
find_obsolete_[core,aux]_names() functions.
The last two points were inspired from RiscV port.
[1]
https://sourceware.org/pipermail/gdb-patches/2020-May/168511.html
gdb/ChangeLog:
* arch/arc.h
(arc_gdbarch_features): New class to stir the selection of target XML.
(arc_create_target_description): Use FEATURES to choose XML target.
(arc_lookup_target_description): Use arc_create_target_description
to create _new_ target descriptions or return the already created
ones if the FEATURES is the same.
* arch/arc.c: Implementation of prototypes described above.
* gdb/arc-tdep.h (arc_regnum enum): Add more registers.
(arc_gdbarch_features_init): Initialize the FEATURES struct.
* arc-tdep.c (*_feature_name): Make feature names consistent.
(arc_register_feature): A new struct to hold information about
registers of a particular target/feature.
(arc_check_tdesc_feature): Check if XML provides registers in
compliance with ARC_REGISTER_FEATURE structs.
(arc_update_acc_reg_names): Add aliases for r58 and r59.
(determine_*_reg_feature_set): Which feature name to look for.
(arc_gdbarch_features_init): Given MACH and ABFD, initialize FEATURES.
(mach_type_to_arc_isa): Convert from a set of binutils machine types
to expected ISA enums to be used in arc_gdbarch_features structs.
* features/Makefile (FEATURE_XMLFILES): Add new files.
* gdb/features/arc/v1-aux.c: New file.
* gdb/features/arc/v1-aux.xml: Likewise.
* gdb/features/arc/v1-core.c: Likewise.
* gdb/features/arc/v1-core.xml: Likewise.
* gdb/features/arc/v2-aux.c: Likewise.
* gdb/features/arc/v2-aux.xml: Likewise.
* gdb/features/arc/v2-core.c: Likewise.
* gdb/features/arc/v2-core.xml: Likewise.
* NEWS (Changes since GDB 9): Announce obsolence of old feature names.
gdb/doc/ChangeLog:
* gdb.texinfo (Synopsys ARC): Update the documentation for ARC
Features.
gdb/testsuite/ChangeLog:
* gdb.arch/arc-tdesc-cpu.xml: Use new feature names.
Commit 1eb8556f5a ("gdb: add infrun_debug_printf macro") changed the
debug output format for `set debug infrun 1`. The test
gdb.threads/stepi-random-signal.exp uses that debug output, and was
updated, but not correctly. It results in this failure:
FAIL: gdb.threads/stepi-random-signal.exp: stepi (no random signal)
Fix it by adjusting the pattern in the test.
gdb/testsuite/ChangeLog:
PR gdb/26532
* gdb.threads/stepi-random-signal.exp: Update pattern.
Change-Id: If5fa525e9545e32a286effe6a6184358374bd37c
Commit 1eb8556f5a ("gdb: add infrun_debug_printf macro") changed the
debug output format for `set debug infrun 1`. It broke test
gdb.base/ui-redirect.exp, which I missed:
FAIL: gdb.base/ui-redirect.exp: debugging: continue
Fix it by adjusting the pattern in the test to the new reality.
gdb/testsuite/ChangeLog:
PR gdb/26532
* gdb.base/ui-redirect.exp: Update pattern.
Change-Id: Ie8a8f6675e35a0cab55109b1534b44eb51baec9d
gdb.dwarf2/dw2-dir-file-name.exp fails to build using Clang because
the generated assembly language contains .ascii directives with more
than one string literal. gdb.dwarf2/dw2-restore.exp fails to build
using Clang because it contains .func and .endfunc directives.
This commit causes Clang to invoke the system assembler to assemble
the relevant files.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-dir-file-name.exp: Use system assembler
when compiling with clang.
* gdb.dwarf2/dw2-restore.exp: Likewise
gdb.cp/ambiguous.exp failed to build using clang with the following
error:
gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.cp/ambiguous.cc:70:36:
warning: direct base 'A1' is inaccessible due to ambiguity:
class JVA1 -> class KV -> class A1
class JVA1 -> class A1 [-Winaccessible-base]
class JVA1 : public KV, public LV, public A1 {
^~~~~~~~~
This commit builds this testcase with -Wno-inaccessible-base when
using clang, to avoid this failure.
Furthermore, gdb.cp/ambiguous.exp has been disabled when using GCC
since 1998. This commit enables this testcase, building with
-Wno-inaccessible-base when using GCC >= 10.1, and -w otherwise.
gdb/testsuite/ChangeLog:
* gdb.cp/ambiguous.exp: Enable test when compiling with GCC.
Add additional_flags=-Wno-inaccessible-base when compiling
with GCC >= 10.1 or clang. Add additional_flags=-w when
compiling with GCC < 10.
Fix bug PR m2/26372, GDB's inability to parse multi-dimensional
modula-2 arrays.
We previously had two rules for handling the parsing of array
sub-scripts. I have reproduced them here with the actual handler
blocks removed to make the bug clearer:
exp : exp '[' non_empty_arglist ']'
;
exp : exp '[' exp ']'
;
non_empty_arglist
: exp
;
non_empty_arglist
: non_empty_arglist ',' exp
;
This is ambiguous as the pattern "exp '[' exp" could match either of
the 'exp' rules. Currently it just so happens that the parser picks
the second 'exp' rule which means we can only handle a single array
index.
As the handler code for the first 'exp' pattern will correctly handle
and number of array indexes then lets just remove the second pattern.
gdb/ChangeLog:
PR m2/26372
* m2-exp.y (exp): Improve comment for non_empty_arglist case, add
an assert. Remove single element array indexing pattern as the
MULTI_SUBSCRIPT support will handle this case too.
gdb/testsuite/ChangeLog:
PR m2/26372
* gdb.modula2/multidim.c: New file.
* gdb.modula2/multidim.exp: New file.
Here is a bugfix for Pr 26372 [Modula-2] Parsing of multi-subscript arrays.
Also included is a dejagnu testcase. No extra regressions are caused on
Debian GNU/Linux Buster amd64.
gdb/ChangeLog:
2020-08-25 Gaius Mulley <gaiusmod2@gmail.com>
PR m2/26372
* m2-exp.y: Rewrite array subscript rules to support multidimension
array access. (ArgumentList) replaces non_empty_arglist.
gdb/testsuite/ChangeLog:
2020-08-25 Gaius Mulley <gaiusmod2@gmail.com>
PR m2/26372
* testsuite/gdb.modula2/multidim.exp: New file.
* testsuite/gdb.modula2/multidim.c: New file.
The implementation is in valprint.c, so the declaration belongs in
valprint.h.
gdb/ChangeLog:
* value.h (valprint_check_validity): Move declaration from
here...
* valprint.h (valprint_check_validity): ... to here.
Change-Id: Ibe577d3696720099e6d79888d4ee8e3c1bf05a26
I noticed that when a test uses `runto_main` and a GDB internal error
happens while running to main, no error or fail is emitted. This is
because `runto_main` uses the `no-message` option of `runto`.
As a result, if a test fails to run to main and exits, no sign that
something went wrong is emitted. For example, add this always-false
assertion to compute_frame_id:
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -545,6 +545,7 @@ static void
compute_frame_id (struct frame_info *fi)
{
gdb_assert (!fi->this_id.p);
+ gdb_assert (false);
if (frame_debug)
fprintf_unfiltered (gdb_stdlog, "{ compute_frame_id (fi=%d) ",
... and run gdb.dwarf2/dw2-align.exp. No fail or sign that something
went wrong is shown. It just appears as if the test gets skipped.
A developer introducing such a regression in this test today would
likely notice it, because we are used to diff-ing test results. So we
would see some PASSes dispappear for no good reason and look into it.
But I find it worrysome for two reasons:
1. Scripts that analyze regressions (such as the one on the buildbot)
may only look for new FAILs or new ERRORs. It would probably miss
this.
2. Imagine that we one day have a testsuite that runs cleanly (some
people might already run subsets of the testsuite and expect it to
all pass), we would just run the testsuite and check that there are
no fails. It would be easy to miss something like this.
In case of internal error, I suggest making `runto` emit a FAIL even if
`no-message` was passed. This is different from other failure modes
that might be expected (whchi rightfully cause the test to simply be
skipped). An internal error is always bad, so if it happens it should
noisily fail.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (runto): Always emit fail on internal error.
Change-Id: I6e6faed4868ea821541a23042b2d01c30058b0d3
To help ensure that all debug statements have the same format, introduce
the debug_prefixed_vprintf helper. Implement linux_nat_debug_printf_1
and infrun_debug_printf_1 with it.
I would eventually like to style the module and function name with some
color, to help them stick out, but I don't really know how to do that
yet, it can always be done later.
gdb/ChangeLog:
* debug.h: New file.
* debug.c (debug_prefixed_vprintf): New function.
* infrun.c (infrun_debug_printf_1): Use debug_prefixed_vprintf.
* linux-nat.c (linux_nat_debug_printf_1): Likewise.
Change-Id: Iccc290a2dc6b5fffcbe1c2866ed8d804ad380764
Introduce this macro to print debug statements in the infrun.c file,
same idea as what was done in 9327494e0e ("gdb: add
linux_nat_debug_printf macro").
Although in this case, there are places outside infrun.c that print
debug statements if debug_infrun is set. So the macro has to be
declared in the header file, so that it can be used in these other
files.
Note one special case. In stop_all_threads, I've used an explicit
if (debug_infrun)
infrun_debug_printf_1 ("stop_all_threads", "done");
for the message in the SCOPE_EXIT. Otherwise, the message appears like
this:
[infrun] operator(): done
Until we find a better solution for extracting a meaningful function
name for lambda functions, I think it's fine to handle these special
cases manually, they are quite rare.
Some tests need to be updated, because they rely on some infrun debug
statements.
gdb/ChangeLog:
* infrun.h (infrun_debug_printf_1): New function declaration.
(infrun_debug_printf): New macro.
* infrun.c (infrun_debug_printf_1): Use infrun_debug_printf
throughout.
(infrun_debug_printf): New function.
* breakpoint.c (should_be_inserted): Use infrun_debug_printf.
(handle_jit_event): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/gdb-sigterm.exp (do_test): Update expected regexp.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Likewise.
* gdb.threads/stepi-random-signal.exp: Likewise.
Change-Id: I66433c8a9caa64c8525ab57c593022b9d1956d5c
Building with a really old flex and a really new g++ is probably not
recommended, but it should not cause compile errors.
gdb/ChangeLog:
* ada-lex.l: Extend register warnings diagnostics comment for g++.
include/ChangeLog:
* diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER): Also define
for GCC version 7.0 or higher.
I'm dealing these days with a class of bugs that involve trying to get a
certain frame's id while we are in the process of computing it. In other
words, compute_frame_id being called for a frame, eventually calling
get_frame_id for that same frame. I don't think this is ever supposed to
happen, as that creates a cyclic dependency.
Usually, these problems cause some failure down the line. I'm proposing with
this patch to catch them as early as possible, as soon as the situation
described above happens. I think that helps because the failed assertion will
be closer to the root of the problem.
To do so, the patch changes the frame_info::this_id::p flag from a boolean (is
the frame id computed or not) to a tri-state:
- the frame id is not computed
- the frame id is being computed
- the frame id is computed
Then, we can properly assert that get_frame_id doesn't get called for a frame
whose id is being computed.
To illustrate how that can help, let's imagine we apply the following change to
frame_unwind_got_optimized:
--- a/gdb/frame-unwind.c
+++ b/gdb/frame-unwind.c
@@ -260,8 +260,7 @@ frame_unwind_got_optimized (struct frame_info *frame, int regnum)
mark_value_bytes_optimized_out (val, 0, TYPE_LENGTH (type));
VALUE_LVAL (val) = lval_register;
VALUE_REGNUM (val) = regnum;
- VALUE_NEXT_FRAME_ID (val)
- = get_frame_id (get_next_frame_sentinel_okay (frame));
+ VALUE_NEXT_FRAME_ID (val) = get_frame_id (frame);
return val;
}
... and run the following command, which leads to a failed assertion (you need
to run the corresponding test to generate the binary first):
$ ./gdb -q -nx testsuite/outputs/gdb.dwarf2/dw2-undefined-ret-addr/dw2-undefined-ret-addr -ex "b stop_frame" -ex r
Without this patch applied, we catch the issue indirectly, when the top-level
get_frame_id tries to stash the frame:
/home/smarchi/src/binutils-gdb/gdb/frame.c:593: internal-error: frame_id get_frame_id(frame_info*): Assertion `stashed' failed.
...
#9 0x0000000001af1c3a in internal_error (file=0x1cea060 "/home/smarchi/src/binutils-gdb/gdb/frame.c", line=593, fmt=0x1ce9f80 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
#10 0x0000000000e9b413 in get_frame_id (fi=0x6210005105e0) at /home/smarchi/src/binutils-gdb/gdb/frame.c:593
#11 0x0000000000e99e35 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7fff1d8b9760) at /home/smarchi/src/binutils-gdb/gdb/frame.c:308
#12 0x000000000149a261 in print_frame_args (fp_opts=..., func=0x6210000dd7d0, frame=0x6210005105e0, num=-1, stream=0x60300008a580) at /home/smarchi/src/binutils-gdb/gdb/stack.c:750
#13 0x000000000149d938 in print_frame (fp_opts=..., frame=0x6210005105e0, print_level=0, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/smarchi/src/binutils-gdb/gdb/stack.c:1394
#14 0x000000000149c0c8 in print_frame_info (fp_opts=..., frame=0x6210005105e0, print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/smarchi/src/binutils-gdb/gdb/stack.c:1119
#15 0x0000000001498100 in print_stack_frame (frame=0x6210005105e0, print_level=0, print_what=SRC_AND_LOC, set_current_sal=1) at /home/smarchi/src/binutils-gdb/gdb/stack.c:366
#16 0x00000000010234b7 in print_stop_location (ws=0x7fff1d8ba1f0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:8366
#17 0x000000000102362d in print_stop_event (uiout=0x607000018660, displays=true) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:8382
...
It freaks out because the frame is already in the stash: it was added by an
inner call to get_frame_id, called indirectly by compute_frame_id. Debugging
this failure is difficult because we have to backtrack to where this happened.
With the patch applied, we catch the issue earlier, here:
/home/smarchi/src/binutils-gdb/gdb/frame.c:601: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->this_id.p != frame_id_status::COMPUTING' failed
...
#9 0x0000000001af22bc in internal_error (file=0x1cea6e0 "/home/smarchi/src/binutils-gdb/gdb/frame.c", line=601, fmt=0x1cea600 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
#10 0x0000000000e9b7e3 in get_frame_id (fi=0x62100050dde0) at /home/smarchi/src/binutils-gdb/gdb/frame.c:601
#11 0x0000000000e989b3 in frame_unwind_got_optimized (frame=0x62100050dde0, regnum=16) at /home/smarchi/src/binutils-gdb/gdb/frame-unwind.c:264
#12 0x0000000000cbe386 in dwarf2_frame_prev_register (this_frame=0x62100050dde0, this_cache=0x62100050ddf8, regnum=16) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:1267
#13 0x0000000000e9f569 in frame_unwind_register_value (next_frame=0x62100050dde0, regnum=16) at /home/smarchi/src/binutils-gdb/gdb/frame.c:1266
#14 0x0000000000e9eaab in frame_register_unwind (next_frame=0x62100050dde0, regnum=16, optimizedp=0x7ffca814ade0, unavailablep=0x7ffca814adf0, lvalp=0x7ffca814ae10, addrp=0x7ffca814ae20, realnump=0x7ffca814ae00, bufferp=0x7ffca814aec0 "") at /home/smarchi/src/binutils-gdb/gdb/frame.c:1169
#15 0x0000000000e9f233 in frame_unwind_register (next_frame=0x62100050dde0, regnum=16, buf=0x7ffca814aec0 "") at /home/smarchi/src/binutils-gdb/gdb/frame.c:1225
#16 0x0000000000f84262 in i386_unwind_pc (gdbarch=0x6210000eed10, next_frame=0x62100050dde0) at /home/smarchi/src/binutils-gdb/gdb/i386-tdep.c:1969
#17 0x0000000000ec95dd in gdbarch_unwind_pc (gdbarch=0x6210000eed10, next_frame=0x62100050dde0) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3062
#18 0x0000000000cb5e9d in dwarf2_tailcall_sniffer_first (this_frame=0x62100050dde0, tailcall_cachep=0x62100050dee0, entry_cfa_sp_offsetp=0x7ffca814b160) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/frame-tailcall.c:387
#19 0x0000000000cbdd38 in dwarf2_frame_cache (this_frame=0x62100050dde0, this_cache=0x62100050ddf8) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:1198
#20 0x0000000000cbe026 in dwarf2_frame_this_id (this_frame=0x62100050dde0, this_cache=0x62100050ddf8, this_id=0x62100050de40) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:1226
#21 0x0000000000e9b447 in compute_frame_id (fi=0x62100050dde0) at /home/smarchi/src/binutils-gdb/gdb/frame.c:580
#22 0x0000000000e9b89e in get_frame_id (fi=0x62100050dde0) at /home/smarchi/src/binutils-gdb/gdb/frame.c:613
#23 0x0000000000e99e35 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7ffca814b610) at /home/smarchi/src/binutils-gdb/gdb/frame.c:315
#24 0x000000000149a8e3 in print_frame_args (fp_opts=..., func=0x6210000dd7d0, frame=0x62100050dde0, num=-1, stream=0x60300008a520) at /home/smarchi/src/binutils-gdb/gdb/stack.c:750
#25 0x000000000149dfba in print_frame (fp_opts=..., frame=0x62100050dde0, print_level=0, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/smarchi/src/binutils-gdb/gdb/stack.c:1394
#26 0x000000000149c74a in print_frame_info (fp_opts=..., frame=0x62100050dde0, print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/smarchi/src/binutils-gdb/gdb/stack.c:1119
#27 0x0000000001498782 in print_stack_frame (frame=0x62100050dde0, print_level=0, print_what=SRC_AND_LOC, set_current_sal=1) at /home/smarchi/src/binutils-gdb/gdb/stack.c:366
#28 0x0000000001023b39 in print_stop_location (ws=0x7ffca814c0a0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:8366
#29 0x0000000001023caf in print_stop_event (uiout=0x607000018660, displays=true) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:8382
...
Now, we can clearly see that get_frame_id for frame `fi=0x62100050dde0` gets
called while compute_frame_id is active for that frame. The backtrace is more
helpful to identify the root of the problem.
gdb/ChangeLog:
* frame.c (enum class frame_id_status): New.
(struct frame_info) <this_id::p>: Change type to frame_id_status.
(fprintf_frame): Update.
(compute_frame_id): Set frame id status to "computing" on entry.
Set it back to "not_computed" on failure and to "computed" on
success.
(get_frame_id): Assert the frame id is not being computed.
(create_sentinel_frame): Use frame_id_status::COMPUTED.
(create_new_frame): Likewise.
(frame_cleanup_after_sniffer): Update assert.
Change-Id: I5f1a25fafe045f756bd75f358892720b30ed20c9
As reported by Tom here [1], commit 888bdb2b74 ("gdb: change regcache
list to be a map") overlooked an important case, causing a regression.
When registers_changed_ptid is called with a pid-like ptid, it used to
clear all the regcaches for that pid. That commit accidentally removed
that behavior. We need to handle the `ptid.is_pid ()` case in
registers_changed_ptid.
The most trivial way of fixing it would be to iterate on all ptids of a
target and delete the entries where the ptid match the pid. But the
point of that commit was to avoid having to iterate on ptids to
invalidate regcaches, so that would feel like a step backwards.
The only logical solution I see is to add yet another map level, so that
we now have:
target -> (pid -> (ptid -> regcaches))
This patch implements that and adds a test for the case of calling
registers_changed_ptid with a pid-like ptid.
[1] https://sourceware.org/pipermail/gdb-patches/2020-August/171222.html
gdb/ChangeLog:
* regcache.c (pid_ptid_regcache_map): New type.
(target_ptid_regcache_map): Remove.
(target_pid_ptid_regcache_map): New type.
(regcaches): Change type to target_pid_ptid_regcache_map.
(get_thread_arch_aspace_regcache): Update.
(regcache_thread_ptid_changed): Update, handle pid-like ptid
case.
(regcaches_size): Update.
(regcache_count): Update.
(registers_changed_ptid_target_pid_test): New.
(_initialize_regcache): Register new test.
Change-Id: I4c46e26d8225c177dbac9488b549eff4c68fa0d8
The selftest `regcaches` selftest is a bit too broad for my taste,
testing the behavior of get_thread_arch_aspace_regcache and various
cases of registers_changed_ptid. Since I'll want to test even more
scenarios of registers_changed_ptid, passing different sets of
parameters, it will be difficult to do in a single test case. It is
difficult to change something at some point in the test case while make
sure it doesn't compromise what comes after, that we still test the
scenarios that we intended to test. So, split the test case in multiple
smaller ones.
- Split the test case in multiple, where each test case starts from
scratch and tests one specific scenario.
- Introduce the populate_regcaches_for_test function, which is used by
the various test cases to start with a regcache container populated
with a few regcaches for two different targets.
- populate_regcaches_for_test returns a regcache_test_data object, which
contains the test targets that were used to create the regcaches. It
also takes care to call registers_changed at the beginning and end of
the test to ensure the test isn't influenced by existing regcaches,
and cleans up after itself.
- Move the regcache_count lambda function out of
regcache_thread_ptid_changed, so it can be used in
other tests.
- For get_thread_arch_aspace_regcache, test that getting a regcache that
already exists does not increase the count of existing regcaches.
- For registers_changed_ptid, test the three cases we handle today:
(nullptr, minus_one_ptid), (target, minus_one_ptid) and (target,
ptid). The (target, minus_one_ptid) case was not tested prior to this
patch.
gdb/ChangeLog:
* regcache.c (regcache_count): New.
(struct regcache_test_data): New.
(regcache_test_data_up): New.
(populate_regcaches_for_test): New.
(regcaches_test): Remove.
(get_thread_arch_aspace_regcache_test): New.
(registers_changed_ptid_all_test): New.
(registers_changed_ptid_target_test): New.
(registers_changed_ptid_target_ptid_test): New.
(regcache_thread_ptid_changed): Remove regcache_count lambda.
(_initialize_regcache): Register new tests.
Change-Id: Id4280879fb40ff3aeae49b01b95359e1359c3d4b
Do these misc changes to test_get_thread_arch_aspace_regcache:
- Rename to get_thread_arch_aspace_regcache_and_check. The following
patch introduces a selftest for get_thread_arch_aspace_regcache, named
get_thread_arch_aspace_regcache_test. To avoid confusion between the
two functions, rename this one to
get_thread_arch_aspace_regcache_and_check, I think it describes better
what it does.
- Remove gdbarch parameter. We always pass the same gdbarch (the
current inferior's gdbarch), so having a parameter is not useful. It
would be interesting to actually test with multiple gdbarches, to
verify that the regcache container can hold multiple regcaches (with
different architectures) for a same (target, ptid). But it's not the
case as of this patch.
- Verify that the regcache's arch is correctly set.
- Remove the aspace parameter. We always pass NULL here, so it's not
useful to have it as a parameter. Also, instead of passing a NULL
aspace to get_thread_arch_aspace_regcache and verifying that we get a
NULL aspace back, pass the current inferior's aspace (just like we use
the current inferior's gdbarch).
gdb/ChangeLog:
* regcache.c (test_get_thread_arch_aspace_regcache): Rename to...
(get_thread_arch_aspace_regcache_and_check): ... this. Remove
gdbarch and aspace parameter. Use current inferior's aspace.
Validate regcache's arch value.
(regcaches_test): Update.
Change-Id: I8b4c2303b4f91f062269043d1f7abe1650232010
It currently does not work to run the `regcaches` selftest while
debugging something. This is because we expect that there exists no
regcache at the start of the test. If we are debugging something, there
might exist some regcaches.
Fix it by making the test clear regcaches at the start.
While at it, make the test clean up after it self and clear the
regcaches at the end too.
gdb/ChangeLog:
* regcache.c (regcaches_test): Call registers_changed.
Change-Id: I9d4f83ecb0ff9721a71e2c5cbd19e6e6d4e6c30c
Currently, GDB is not able to set a breakpoint at subprogram post
prologue for flang generated binaries. This is due to clang having
two line notes one before and another after the prologue.
Now the end of prologue is determined using symbol table, which was
the way for clang generated binaries already. Since clang and flang
both share same back-end it is true for flang as well.
gdb/ChangeLog
* amd64-tdep.c (amd64_skip_prologue): Using symbol table
to find the end of prologue for flang compiled binaries.
* arm-tdep.c (arm_skip_prologue): Likewise.
* i386-tdep.c (i386_skip_prologue): Likewise.
* producer.c (producer_is_llvm): New function.
(producer_parsing_tests): Added new tests for clang/flang.
* producer.h (producer_is_llvm): New declaration.
gdb/testsuite/ChangeLog
* gdb.fortran/vla-type.exp: Skip commands not required for
the Flang compiled binaries after prologue fix.
The debug prints inside linux-nat.c almost all have a prefix that
indicate in which function they are located. This prefix is an
abbreviation of the function name. For example, this print is in the
`linux_nat_post_attach_wait` function:
if (debug_linux_nat)
fprintf_unfiltered (gdb_stdlog,
"LNPAW: Attaching to a stopped process\n");
Over time, the code has changed, things were moved, and many of these
prefixes are not accurate anymore. Also, unless you know the
linux-nat.c file by heart, it's a bit cryptic what LLR, LNW, RSRL, etc,
all mean.
To address both of these issues, I suggest adding this macro for
printing debug statements, which automatically includes the function
name. It also includes the `[linux-nat]` prefix to clarify which part
of GDB printed this (I think that, ideally, all debug prints would
include such a tag).
The `__func__` magic symbol is used to get the function name.
Unfortunately, in the case of methods, it only contains the method name,
not the class name. So we'll get "wait", where I would have liked to
get "linux_nat_target::wait". But at least with the `[linux-nat]` tag
in the front, it's not really ambiguous.
I've made the macro automatically include the trailing newline, because
it wouldn't make sense to call it twice to print two parts of one line,
the `[linux-nat]` tag would be printed in the middle.
An advantage of this (IMO) is that it's less verbose, we don't have to
check for `if (debug_linux_nat)` everywhere.
Another advantage is that it's easier to customize the output later,
without having to touch all call sites.
Here's an example of what it looks like in the end:
[linux-nat] linux_nat_wait_1: enter
[linux-nat] wait: [process -1], [TARGET_WNOHANG]
gdb/ChangeLog:
* linux-nat.c (linux_nat_debug_printf): New function.
(linux_nat_debug_printf_1): New macro. Use throughout the file.
Change-Id: Ifcea3255b91400d3ad093cd0b75d3fac241cb998
Introduce Makefile variables DEBUGINFOD_CFLAGS and DEBUGINFOD_LIBS
that map to the configuration variables of the same names.
Replace @DEBUGINFOD_LIBS@ with $(DEBUGINFOD_LIBS) in the definition
of CLIBS in order to conform to the usage of other *_LIBS variables
in Makefile.in.
Add DEBUGINFOD_CFLAGS to INTERNAL_CFLAGS_BASE. This fixes an issue
where GDB would fail to find debuginfod.h if it was not installed
in a default location searched by the compiler.
gdb/ChangeLog:
* Makefile.in (DEBUGINFOD_CFLAGS, DEBUGINFOD_LIBS): New variables.
(INTERNAL_CFLAGS_BASE): Add DEBUGINFOD_CFLAGS.
(CLIBS): Add DEBUGINFOD_LIBS.
On IA64 built failed as:
```
ia64-linux-nat.c:352:29: error: 'gdbarch_num_regs' was not declared in this scope
352 | if (regno < 0 || regno >= gdbarch_num_regs (gdbarch))
| ^~~~~~~~~~~~~~~~
```
The fix includes "gdbarch.h" header where symbol is declared.
* ia64-linux-nat.c: Include "gdbarch.h" to declare used
'gdbarch_num_regs'.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
In PR rust/26197, Tom de Vries notes that the variant part rewrite
caused some regressions for the Rust compiler he has. This compiler
is unusual in that it combines a relatively recent rustc with a
relatively old LLVM -- so variant parts are not emitted using DWARF.
Most of the bugs in that PR were already fixed by earlier patches, but
some lingered. After some research we found that some of these never
did work -- which is consistent with the investigations we did into
the debug info -- but instead were xfail'd. This patch updates the
xfails to cope with the new output. (After this, just one failure
remains.)
Tom de Vries tested this using his rustc and suggested a fix that
appears in this version.
gdb/testsuite/ChangeLog
2020-08-17 Tom de Vries <tdevries@suse.de>
Tom Tromey <tromey@adacore.com>
PR rust/26197:
* gdb.rust/simple.exp (xfail_pattern): Update for new failure.
I happened to notice that using -var-create at a certain spot in an
Ada program caused a crash. This happens because
ada_get_decoded_value can return NULL -- in particular, deeper in the
code it can hit this return in ada_type_of_array:
descriptor = desc_bounds (arr);
if (value_as_long (descriptor) == 0)
return NULL;
This patch avoids the crash by handling this NULL return.
gdb/ChangeLog
2020-08-17 Tom Tromey <tromey@adacore.com>
* ada-varobj.c (ada_varobj_decode_var): Handle case where
ada_get_decoded_value returns NULL.
gdb/testsuite/ChangeLog
2020-08-17 Tom Tromey <tromey@adacore.com>
* gdb.ada/mi_var_access.exp: New file.
* gdb.ada/mi_var_access/mi_access.adb: New file.
* gdb.ada/mi_var_access/pck.adb: New file.
* gdb.ada/mi_var_access/pck.ads: New file.
An internal test failed on a riscv64-elf cross build because
Inferior.search_memory returned a negative value. I tracked this down
to to use of PyLong_FromLong in infpy_search_memory. Then, I looked
at other conversions of CORE_ADDR to Python and fixed these as well.
I don't think there is a good way to write a test for this.
gdb/ChangeLog
2020-08-17 Tom Tromey <tromey@adacore.com>
* python/py-inferior.c (infpy_search_memory): Use
gdb_py_object_from_ulongest.
* python/py-infevents.c (create_inferior_call_event_object)
(create_memory_changed_event_object): Use
gdb_py_object_from_ulongest.
* python/py-linetable.c (ltpy_entry_get_pc): Use
gdb_py_object_from_ulongest.
This variable is really a boolean, so use the bool type.
gdb/ChangeLog:
* dwarf2/loc.c (dwarf2_loc_desc_get_symbol_read_needs): Use
bool.
Change-Id: I814a47d1200f3b88722c54c822fd49607a6b77be
When debugging gdb in batch mode with executable mixed-lang-stack and doing a
backtrace at breakpt:
...
$ gdb --args gdb \
-batch \
outputs/gdb.fortran/mixed-lang-stack/mixed-lang-stack \
-ex "b breakpt" \
-ex r \
-ex bt
...
and stopping at resolve_dynamic_type to print the type:
...
(gdb) b resolve_dynamic_type
Breakpoint 1 at 0x6b020c: file gdbtypes.c, line 2633.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>call recursive_dump_type (type, 0)
>continue
>end
(gdb) run
...
we eventually run into an assert for the dynamic type of "str":
...
Thread 1 "gdb" hit Breakpoint 1, resolve_dynamic_type (type=0x22204f0, \
valaddr=..., addr=4199408) at gdbtypes.c:2633
2633 = {check_typedef (type), valaddr, addr, NULL};
type node 0x22204f0
name '<NULL>' (0x0)
code 0xd (TYPE_CODE_STRING)
length 0
...
nfields 0 0x22204b0
gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: \
Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
when trying to print the high bound of a TYPE_CODE_RANGE, which has m_kind
PROP_LOCEXPR, while the code in resolve_dynamic_type assumes PROP_CONST.
Fix this by extending the printing of TYPE_CODE_RANGE to allow
PROP_LOCEXPR/PROP_LOCLIST as well, such that we have instead:
...
nfields 0 0x1fbc020
low 1 high (dynamic)
...
Tested on x86_64-linux.
gdb/ChangeLog:
2020-08-17 Tom de Vries <tdevries@suse.de>
PR gdb/26393
* gdbtypes.c (dump_dynamic_prop): New function.
(recursive_dump_type): Use dump_dynamic_prop for TYPE_CODE_RANGE.
In PR25350, an internal error was reported:
...
(gdb) break *eh2+0x7e
Breakpoint 1 at 0x13e2: file small.c, line 38.
(gdb) run
Starting program: a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Breakpoint 1, 0x00005555555553e2 in eh2 (
frame.c:558: internal-error: frame_id get_frame_id(frame_info*): \
Assertion `stashed' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
The internal error does not reproduce after recent commit 547ce8f00b
"[gdb/backtrace] Fix printing of fortran string args".
Add the corresponding test-case as regression test, given that the code is
rather atypical.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-08-16 Tom de Vries <tdevries@suse.de>
PR gdb/25350
* gdb.base/eh_return.c: New test.
* gdb.base/eh_return.exp: New file.
In gdb.fortran/mixed-lang-stack.f90, we have fortran function mixed_func_1d:
...
subroutine mixed_func_1d(a, b, c, d, str)
use, intrinsic :: iso_c_binding, only: c_int, c_float, c_double
use, intrinsic :: iso_c_binding, only: c_float_complex
implicit none
integer(c_int) :: a
real(c_float) :: b
real(c_double) :: c
complex(c_float_complex) :: d
character(len=*) :: str
...
which we declare in C in gdb.fortran/mixed-lang-stack.c like this:
...
extern void mixed_func_1d_ (int *, float *, double *, complex float *,
char *, size_t);
...
The fortran string parameter str is passed as a char *, and an additional
argument str_ for the string length. The type used for the string length
argument is size_t, but for gcc 7 and earlier, the actual type is int
instead ( see
https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html ).
Fix this by declaring the string length type depending on the gcc version:
...
#if !defined (__GNUC__) || __GNUC__ > 7
typedef size_t fortran_charlen_t;
#else
typedef int fortran_charlen_t;
...
Tested on x86_64-linux, with gcc-7 and gcc-8.
gdb/testsuite/ChangeLog:
2020-08-15 Tom de Vries <tdevries@suse.de>
* gdb.fortran/mixed-lang-stack.c (fortran_charlen_t): New type.
(mixed_func_1d_): Use fortran_charlen_t in decl.
When running test-case gdb.fortran/mixed-lang-stack.exp, it passes, but we
find in gdb.log:
...
(gdb) bt^M
...
#7 0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
e=<error reading variable: value requires 140737488341744 bytes, which \
is more than max-value-size>, g=..., _e=6) at mixed-lang-stack.f90:87^M
...
while a bit later in gdb.log, we have instead for the same frame (after
adding a gdb_test_no_output "set print frame-arguments all" to prevent
getting "e=..."):
...
(gdb) up^M
#7 0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
e='abcdef', g=( a = 1.5, b = 2.5 ), _e=6) at mixed-lang-stack.f90:87^M
...
The difference is that in the latter case, we print the frame while it's
selected, while in the former, it's not.
The problem is that while trying to resolve the dynamic type of e in
resolve_dynamic_type, we call dwarf2_evaluate_property with a frame == NULL
argument, and then use the selected frame as the context in which to evaluate
the dwarf property, effectively evaluating a DW_OP_fbreg operation in the
wrong frame context.
Fix this by temporarily selecting the frame of which we're trying to print the
arguments in print_frame_args, borrowing code from print_frame_local_vars that
was added to fix a similar issue in commit 16c3b12f19 "error/internal-error
printing local variable during "bt full".
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-15 Tom de Vries <tdevries@suse.de>
PR backtrace/26390
* stack.c (print_frame_args): Temporarily set the selected
frame to FRAME while printing the frame's arguments.
gdb/testsuite/ChangeLog:
2020-08-15 Tom de Vries <tdevries@suse.de>
PR backtrace/26390
* gdb.fortran/mixed-lang-stack.exp: Call bt with -frame-arguments all.
Update expected pattern.
This patches changes low_prepare_to_resume in the ppc linux native target
to always clear the watchpoint when the old PTRACE_SET_DEBUGREG interface
is used, even if another watchpoint GDB requested to the target is
written right after using the same call.
The reason for this is that there were some older kernel versions for
which overwriting a watchpoint with PTRACE_SET_DEBUGREG would not
re-activate the watchpoint if it was previouly disabled following a hit.
This happened when the kernel was configured with CONFIG_HW_BREAKPOINT on
and uses perf events to install watchpoints.
Previously, the ppc linux native target would immediately remove or
insert watchpoints following a request from the upper layers. This was
changed in commit 227c0bf4b3 to fix other
issues, which caused watchpoint requests to be applied to the inferior
only in low_prepare_to_resume, right before the inferior is resumed.
Usually, but maybe not always, after a hit, GDB will remove the
watchpoint, resume the inferior for a single-step, possibly report the
watchpoint hit to the user, and then re-insert the watchpoint before the
inferior is next resumed. In this case there would be no problems, but
since I can't guarantee that there aren't other paths in GDB that allow
the user to set a new watchpoint after the first one hit, and after its
deletion by GDB, but before the inferior is resumed, there is a chance
that PTRACE_SET_DEBUGREG could be called directly without the watchpoint
first having been cleared, which could cause a false negative with the
older kernel versions.
This issue would affect kernel versions starting from this commit:
5aae8a53708025d4e718f0d2e7c2f766779ddc71
Up to the fix in this commit:
a53fd61ac2f411745471c1c877d5e072fbbf0e5c
gdb/ChangeLog:
PR breakpoints/26385
* ppc-linux-nat.c (ppc_linux_nat_target::low_prepare_to_resume):
Always clear watchpoint with PTRACE_SET_DEBUGREG.
In commit 227c0bf4b3, which fixed some
watchpoint bugs, I compared the return value of some ptrace calls with ==
-1 and != -1. Althought this should be correct, since the rest of the
file uses < 0 and >= 0, I have modified this for consistency.
gdb/ChangeLog:
* ppc-linux-nat.c (ppc_linux_dreg_interface::detect)
(ppc_linux_nat_target::low_prepare_to_resume): Use ptrace () < 0
and >= to check return value instead of == -1 and != -1.
Introduce the gdb_argv::as_array_view method, as a way to easily pass
the parsed arguments array to a function taking an array view. There is
currently one caller where we can use this (which prompted the
suggestion to implement this method).
Add some selftests for the new method, which at the same time test a
little bit gdb_argv. As far as I know, it's not tested currently.
gdb/ChangeLog:
* utils.h (class gdb_argv) <as_array_view>: New method.
* utils.c (gdb_argv_as_array_view_test): New.
(_initialize_utils): Register selftest.
* maint.c (maintenance_selftest): Use the new method.
Change-Id: I0645037613ed6549aabe60f14a36f3494513b177
Define supports_dumpcore and dumpcore for NetBSD, that wraps
the ptrace(2) call with the PT_DUMPCORE operation.
gdb/ChangeLog:
* nbsd-nat.h (nbsd_nat_target::supports_dumpcore)
(nbsd_nat_target::dumpcore): New declarations.
* nbsd-nat.c (nbsd_nat_target::supports_dumpcore)
(nbsd_nat_target::dumpcore): New functions.
Add new API for systems with native kernel support for dumping
a process on demand. Wire it into the gdb's gcore functionality.
gdb/ChangeLog:
* target.h (supports_dumpcore, dumpcore): New
function declarations.
* target.c (supports_dumpcore, dumpcore): New
functions.
* target-delegates.c: Rebuild.
* gcore.c (gcore_command): Use target_supports_dumpcore ()
and target_dumpcore ().
Store query information in user_data struct instead of global variables.
gdb/ChangeLog:
* debuginfod-support.c: Replace global variables with user_data.
I found myself wanting to run a few specific selftests while developing.
I thought it would be nice to be able to provide multiple test names
when running `maintenant selftests`. The arguments to that command is
currently interpreted as a single filter (not split by spaces), it now
becomes a list a filters, split by spaces. A test is executed when it
matches at least one filter.
Here's an example of the result in GDB:
(gdb) maintenance selftest xml
Running selftest xml_escape_text.
Running selftest xml_escape_text_append.
Ran 2 unit tests, 0 failed
(gdb) maintenance selftest xml unord
Running selftest unordered_remove.
Running selftest xml_escape_text.
Running selftest xml_escape_text_append.
Ran 3 unit tests, 0 failed
(gdb) maintenance selftest xml unord foobar
Running selftest unordered_remove.
Running selftest xml_escape_text.
Running selftest xml_escape_text_append.
Ran 3 unit tests, 0 failed
Since the selftest machinery is also shared with gdbserver, I also
adapted gdbserver. It accepts a `--selftest` switch, which accepts an
optional filter argument. I made it so you can now pass `--selftest`
multiple time to add filters.
It's not so useful right now though: there's only a single selftest
right now in GDB and it's for an architecture I can't compile. So I
tested by adding dummy tests, here's an example of the result:
$ ./gdbserver --selftest=foo
Running selftest foo.
foo
Running selftest foobar.
foobar
Ran 2 unit tests, 0 failed
$ ./gdbserver --selftest=foo --selftest=bar
Running selftest bar.
bar
Running selftest foo.
foo
Running selftest foobar.
foobar
Ran 3 unit tests, 0 failed
gdbsupport/ChangeLog:
* selftest.h (run_tests): Change parameter to array_view.
* selftest.c (run_tests): Change parameter to array_view and use
it.
gdb/ChangeLog:
* maint.c (maintenance_selftest): Split args and pass array_view
to run_tests.
gdbserver/ChangeLog:
* server.cc (captured_main): Accept multiple `--selftest=`
options. Pass all `--selftest=` arguments to run_tests.
Change-Id: I422bd49f08ea8095ae174c5d66a2dd502a59613a
During debugging of PR26362, it was noticed that the malloc size check
in check_type_length_before_alloc wasn't detecting an allocation attempt
of a huge amount of bytes, making GDB run into an internal error.
This happens because we're using an int to store a type's length. When the
type length is large enough, the int will overflow and the max_value_size
check won't work anymore.
The following patch fixes this by making the length variable a ULONGEST.
Printing statements were also updated to show the correct number of bytes.
gdb/ChangeLog:
2020-08-12 Luis Machado <luis.machado@linaro.org>
* value.c (check_type_length_before_alloc): Use ULONGEST to store a
type's length.
Use %s and pulongest to print the length.
Simon noticed that I managed to put this in the "Changes in GDB 9"
section by mistake instead of in the "Changes since GDB 9" section
where it belongs.
gdb/ChangeLog:
* NEWS: Move "Multi-target debugging support" item to the
"Changes since GDB 9" section.
gdb.base/corefile.exp is showing an unexpected failure and an
unresolved testcase when testing against unix/-m32:
(gdb) PASS: gdb.base/corefile.exp: attach: sanity check we see the core file
attach 15741
gdb/dwarf2-frame.c:1009: internal-error: dwarf2_frame_cache* dwarf2_frame_cache(frame_info*, void**): Assertion `fde != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.base/corefile.exp: attach: with core (GDB internal error)
Resyncing due to internal error.
This regressed with:
From 5b6d1e4fa4 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Fri, 10 Jan 2020 20:06:08 +0000
Subject: [PATCH] Multi-target support
The assertion is here:
#0 internal_error (file=0xbffffccb0 <error: Cannot access memory at address 0xbffffccb0>, line=0, fmt=0x555556327320 "en_US.UTF-8") at sr
c/gdbsupport/errors.cc:51
#1 0x00005555557d4e45 in dwarf2_frame_cache (this_frame=0x55555672f950, this_cache=0x55555672f968) at src/gdb/dwarf2/frame.c:1013
#2 0x00005555557d5886 in dwarf2_frame_this_id (this_frame=0x55555672f950, this_cache=0x55555672f968, this_id=0x55555672f9b0) at src/gdb/d
warf2/frame.c:1226
#3 0x00005555558b184e in compute_frame_id (fi=0x55555672f950) at src/gdb/frame.c:558
#4 0x00005555558b19b2 in get_frame_id (fi=0x55555672f950) at src/gdb/frame.c:588
#5 0x0000555555bda338 in scoped_restore_current_thread::scoped_restore_current_thread (this=0x7fffffffd0d8) at src/gdb/thread.c:1458
#6 0x00005555556ce41f in scoped_restore_current_pspace_and_thread::scoped_restore_current_pspace_and_thread (During symbol reading: .debug_line address at offset 0x1db2d3
is 0 [in module /home/pedro/gdb/cascais-builds/binutils-gdb/gdb/gdb]
this=0x7fffffffd0d0) at src/gdb/progspace-and-thread.h:29
#7 0x0000555555898ea6 in remove_target_sections (owner=0x555556935550) at src/gdb/exec.c:798
#8 0x0000555555b700b6 in symfile_free_objfile (objfile=0x555556935550) at src/gdb/symfile.c:3742
#9 0x000055555565050e in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd190
: 0x555556935550) at /usr/include/c++/9/bits/std_function.h:300
#10 0x0000555555a3053d in std::function<void (objfile*)>::operator()(objfile*) const (this=0x555556752a20, __args#0=0x555556935550) at /usr/include/c++/9/bits/std_function.
h:688
#11 0x0000555555a2ff01 in gdb::observers::observable<objfile*>::notify (this=0x5555562eaa80 <gdb::observers::free_objfile>, args#0=0x555556935550) at /net/cascais.nfs/gdb/b
inutils-gdb/src/gdb/../gdbsupport/observable.h:106
#12 0x0000555555a2c56a in objfile::~objfile (this=0x555556935550, __in_chrg=<optimized out>) at src/gdb/objfiles.c:521
#13 0x0000555555a31d46 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c1f6f0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
#14 0x00005555556d3444 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c1f6f0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
#15 0x00005555556cec77 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556b99ee8, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
#16 0x0000555555a2f8da in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556b99ee0, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
#17 0x0000555555a2f8fa in std::shared_ptr<objfile>::~shared_ptr (this=0x555556b99ee0, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
#18 0x0000555555a63fba in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x55555679f0c0, __p=0x555556b99ee0) at /usr/include/c++/9/ext/new_allocator.h:153
#19 0x0000555555a638fb in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556b99ee0) at /usr/include/c++/9/bits/alloc_traits.h:497
#20 0x0000555555a6351c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x55555679f0c0, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556935550}) at /usr/include/c++/9/bits/stl_list.h:1921
#21 0x0000555555a62dab in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x55555679f0c0, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556935550}) at /usr/include/c++/9/bits/list.tcc:158
#22 0x0000555555a614dd in program_space::remove_objfile (this=0x55555679f080, objfile=0x555556935550) at src/gdb/progspace.c:207
#23 0x0000555555a2c4dc in objfile::unlink (this=0x555556935550) at src/gdb/objfiles.c:497
#24 0x0000555555a2da65 in objfile_purge_solibs () at src/gdb/objfiles.c:904
#25 0x0000555555b3af74 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
#26 0x0000555555bbafc7 in target_pre_inferior (from_tty=1) at src/gdb/target.c:1900
#27 0x0000555555940afb in attach_command (args=0x5555563277c7 "15741", from_tty=1) at src/gdb/infcmd.c:2582
...
The problem is that the multi-target commit added a
scoped_restore_current_thread to remove_target_sections (frame #7
above). scoped_restore_current_thread's ctor fetches the selected
frame's frame id. If the frame had not had its frame id computed yet,
it is computed then (frame #4 above). Because it has been determined
earlier that the frame's unwinder is the DWARF unwinder, we end up
here:
static struct dwarf2_frame_cache *
dwarf2_frame_cache (struct frame_info *this_frame, void **this_cache)
{
...
/* Find the correct FDE. */
fde = dwarf2_frame_find_fde (&pc1, &cache->per_objfile);
gdb_assert (fde != NULL);
And, that assertion fails. The assertion is reasonable, because the
DWARF unwinder only claims the frame if it managed to find the FDE
earlier (in dwarf2_frame_sniffer).
(unix/-m32 is thus really a red herring here -- it's just that on
x86_64 -m64, the frame is not claimed by the DWARF unwinder.)
The reason the assertion is failing, is because the objfile that
contains the FDE has been removed from the objfiles list already when
we get here (frame #22 above). This suggests that the fix should be
to invalidate DWARF frames when their objfile is removed. Or to keep
it simple and safe, invalidate the frame cache when an objfile is
removed. That is what this commit does.
OOC, I checked why is it that when you unload a file with plain "(gdb)
file", we don't hit the assertion. It must be because we're already
flushing the frame cache somewhere else in that case. And indeed, we
flush the frame cache here:
(gdb) bt
#0 reinit_frame_cache () at src/gdb/frame.c:1857
#1 0x0000555555ad1ad6 in registers_changed_ptid (target=0x0, ptid=...) at src/gdb/regcache.c:470
#2 0x0000555555ad1b58 in registers_changed () at src/gdb/regcache.c:485
#3 0x00005555558d095e in set_target_gdbarch (new_gdbarch=0x555556d5f5b0) at src/gdb/gdbarch.c:5528
#4 0x0000555555677175 in set_gdbarch_from_file (abfd=0x0) at src/gdb/arch-utils.c:601
#5 0x0000555555897c6b in exec_file_attach (filename=0x0, from_tty=1) at src/gdb/exec.c:409
#6 0x000055555589852d in exec_file_command (args=0x0, from_tty=1) at src/gdb/exec.c:571
#7 0x00005555558985a1 in file_command (arg=0x0, from_tty=1) at src/gdb/exec.c:583
#8 0x000055555572b55f in do_const_cfunc (c=0x55555672e200, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:95
#9 0x000055555572f3d3 in cmd_func (cmd=0x55555672e200, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2181
#10 0x0000555555be1ecc in execute_command (p=0x555556327804 "", from_tty=1) at src/gdb/top.c:668
#11 0x0000555555895427 in command_handler (command=0x555556327800 "file") at src/gdb/event-top.c:588
#12 0x00005555558958af in command_line_handler (rl=...) at src/gdb/event-top.c:773
#13 0x0000555555894b3e in gdb_rl_callback_handler (rl=0x55555a09e240 "file") at src/gdb/event-top.c:219
#14 0x0000555555ccfeec in rl_callback_read_char () at src/readline/readline/callback.c:281
#15 0x000055555589495a in gdb_rl_callback_read_char_wrapper_noexcept () at src/gdb/event-top.c:177
#16 0x0000555555894a08 in gdb_rl_callback_read_char_wrapper (client_data=0x555556327520) at src/gdb/event-top.c:194
#17 0x00005555558952a5 in stdin_event_handler (error=0, client_data=0x555556327520) at src/gdb/event-top.c:516
#18 0x0000555555e027d6 in handle_file_event (file_ptr=0x555558d20840, ready_mask=1) at src/gdbsupport/event-loop.cc:548
#19 0x0000555555e02d88 in gdb_wait_for_event (block=1) at src/gdbsupport/event-loop.cc:673
#20 0x0000555555e01c42 in gdb_do_one_event () at src/gdbsupport/event-loop.cc:215
#21 0x00005555559c47c2 in start_event_loop () at src/gdb/main.c:356
#22 0x00005555559c490d in captured_command_loop () at src/gdb/main.c:416
#23 0x00005555559c6217 in captured_main (data=0x7fffffffdc00) at src/gdb/main.c:1253
#24 0x00005555559c6289 in gdb_main (args=0x7fffffffdc00) at src/gdb/main.c:1268
#25 0x0000555555621756 in main (argc=3, argv=0x7fffffffdd18) at src/gdb/gdb.c:32
gdb/ChangeLog:
PR gdb/26336
* progspace.c (program_space::remove_objfile): Invalidate the
frame cache.
gdb.dwarf2/dw2-op-out-param.S contained a duplicate label, and failed
to build with clang with the following error:
gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.dwarf2/dw2-op-out-param.S:163:1:
error: invalid symbol redefinition
.Ltext5:
^
This commit renames the two labels as .Ltext5a and .Ltext5b, and
updates all references appropriately.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-out-param.S (.Ltext5): Fix duplicate label.
