In switch_thru_all_uis, a pre-c++11 way of removing copy constructor
and assignment operator is used.
This patch uses the DISABLE_COPY_AND_ASSIGN macro which does the right
thing for pre and post c++11.
gdb/Changelog:
2021-01-19 Lancelot SIX <lsix@lancelotsix.com>
* top.h (switch_thru_all_uis): Use DISABLE_COPY_AND_ASSIGN.
With the new member functions for struct trad_frame_saved_reg, there is no
need to invoke some of the set/get functions anymore. This patch removes
those and adjusts all callers.
Even though the most natural initial state of a saved register value is
UNKNOWN, there are target backends relying on the previous initial state
of REALREG set to a register's own number. I noticed this in at least a
couple targets: aarch64 and riscv.
Because of that, I decided to keep the reset function that sets the set of
register values to REALREG. I can't exercise all the targets to make sure
the initial state change won't break things, hence why it is risky to change
the default.
Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04.
gdb/ChangeLog
2021-01-19 Luis Machado <luis.machado@linaro.org>
* trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate
memory and save data.
(trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes)
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p): Remove.
(trad_frame_reset_saved_regs): Adjust documentation.
* trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a
constructor and reset the state of the registers.
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p, trad_frame_set_value)
(trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes): Remove.
(trad_frame_set_reg_realreg): Update to call member function.
(trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.
* aarch64-tdep.c (aarch64_analyze_prologue)
(aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1)
(aarch64_prologue_prev_register): Update to use member functions.
* alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise.
* alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise.
* arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise.
* arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache)
(arm_make_epilogue_frame_cache): Likewise.
* avr-tdep.c (avr_frame_unwind_cache)
(avr_frame_prev_register): Likewise.
* cris-tdep.c (cris_scan_prologue): Likewise.
* csky-tdep.c (csky_frame_unwind_cache): Likewise.
* frv-tdep.c (frv_analyze_prologue): Likewise.
* hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise.
* lm32-tdep.c (lm32_frame_cache): Likewise.
* m32r-tdep.c (m32r_frame_unwind_cache): Likewise.
* m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise.
* mips-tdep.c (set_reg_offset, mips_insn16_frame_cache)
(mips_micro_frame_cache, mips_insn32_frame_cache): Likewise.
(reset_saved_regs): Adjust to set realreg.
* riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to
call member functions.
* rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache)
* s390-tdep.c (s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache): Likewise.
* score-tdep.c (score7_analyze_prologue)
(score3_analyze_prologue, score_make_prologue_cache): Likewise.
* sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise.
* sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise.
* sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise.
* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue)
(tilegx_frame_cache): Likewise.
* v850-tdep.c (v850_frame_cache): Likewise.
* vax-tdep.c (vax_frame_cache): Likewise.
This patch updates the functions setting value bytes in trad-frame to use
a gdb::array_view instead of passing a buffer and a size.
gdb/ChangeLog:
2021-01-19 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_restore_vreg): Pass in an
array_view.
* trad-frame.c (trad_frame_set_value_bytes): Use gdb::array_view
instead of buffer and size.
(trad_frame_set_reg_value_bytes): Likewise.
* trad-frame.h (trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_set_value_bytes): Likewise.
This wasn't supposed to be in here when it was first merged as we
had specifically disabled it for all the tests (and ADI has papers
in place w/the FSF). Clean up this one.
The RISC-V x0 register is hard-coded to zero. As such neither Linux
or FreeBSD supply the value of the register x0 in their core dump
files.
For FreeBSD we take care of this by manually supplying the value of x0
in riscv_fbsd_supply_gregset, however we don't do this for Linux. As
a result after loading a core file on Linux we see this behaviour:
(gdb) p $x0
$1 = <unavailable>
In this commit I make riscv_fbsd_supply_gregset a common function that
can be shared between RISC-V for FreeBSD and Linux, this resolves the
above issue.
There is a similar problem for the two registers `fflags` and `frm`.
These two floating point related CSRs are a little weird. They are
separate CSRs in the RISC-V specification, but are actually sub-fields
of the `fcsr` CSR.
As a result neither Linux or FreeBSD supply the `fflags` or `frm`
registers as separate fields in their core dumps, and so, after
restoring a core dump these register are similarly unavailable.
In this commit I supply `fflags` and `frm` by first asking for the
value of `fcsr`, extracting the two fields, and using these to supply
the values for `fflags` and `frm`.
gdb/ChangeLog:
* riscv-fbsd-tdep.c (riscv_fbsd_supply_gregset): Delete.
(riscv_fbsd_gregset): Use riscv_supply_regset.
(riscv_fbsd_fpregset): Likewise.
* riscv-linux-tdep.c (riscv_linux_gregset): Likewise.
(riscv_linux_fregset): Likewise.
* riscv-tdep.c (riscv_supply_regset): Define new function.
* riscv-tdep.h (riscv_supply_regset): Declare new function.
When running test-case gdb.arch/i386-mpx-sigsegv.exp with target board
unix/-m32, we run into:
...
(gdb) continue^M
Continuing.^M
Saw a #BR! status 1 at 0x8048c2d^M
^M
Program received signal SIGSEGV, Segmentation fault^M
Upper bound violation while accessing address 0x0804c15c^M
Bounds: [lower = 0x00000000, upper = 0x00000000].^M
0x08048a4f in lower (p=0x804c160, a=0x804c180, b=0x804c1a0, c=0x804c1c0, \
d=0x804c1e0, len=1) at i386-mpx-sigsegv.c:79^M
79 value = *(p - len);^M
(gdb) FAIL: gdb.arch/i386-mpx-sigsegv.exp: MPX signal segv Lower: 0
...
The problem is that lower and upper in the Bounds message are 0x0, which is
caused by $_siginfo._sifields._sigfault._addr_bnd.{_lower,_upper} evaluating
to 0x0.
Fix this by copying the si_lower/si_upper fields in
compat_siginfo_from_siginfo.
Tested on x86_64-linux, with target board unix/-m32.
gdb/ChangeLog:
2021-01-18 Tom de Vries <tdevries@suse.de>
PR tdep/27172
* nat/amd64-linux-siginfo.c (cpt_si_lower, cpt_si_upper, SEGV_BNDERR):
New macro.
(compat_siginfo_from_siginfo): Copy cpt_si_lower and cpt_si_upper
for SEGV_BNDERR.
The wait_status variable is only used when the target is in in all-stop
mode. We can therefore move it in the !target_is_non_stop scope. That
lets us remove the assert in the else, that checks that the wait status
is not set. If the variable doesn't exist in that scope, it pretty much
guarantees that it is not set.
gdb/ChangeLog:
* remote.c (remote_target::start_remote): Move wait_status to
narrower scope.
Change-Id: I30979135e3f4f36d04178baa67575c4e58d3b648
Compare pointers to nullptr, not 0. I also fixed a trailing
whitespace in the same function.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* tui/tui.c (tui_is_window_visible): Compare to nullptr, not 0.
Since is_trivially_default_constructible was not implemented before gcc-5
it cannot be used with gcc-4.x.
Fix the build by using conditional compilation around that line.
Use the equivalent is_trivially_constructible<T> instead, since
we already have HAVE_IS_TRIVIALLY_CONSTRUCTIBLE for that purpose.
Fixes: 098caef485 ("Refactor struct trad_frame_saved_regs")
gdb:
2021-01-14 Bernd Edlinger <bernd.edlinger@hotmail.de>
* trad-frame.c (trad_frame_alloc_saved_regs): Avoid compile-error
because is_trivially_default_constructible was first implemented with
gcc-5.
Consider the following test-case small.c:
...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main (void) {
int *p = (int *)malloc (sizeof(int) * 4);
memset (p, 0, sizeof(p));
printf ("p[0] = %d; p[3] = %d\n", p[0], p[3]);
return 0;
}
...
On Ubuntu 20.04, we get:
...
$ gcc -O0 -g small.c
$ gdb -batch a.out -ex start -ex step
Temporary breakpoint 1, main () at small.c:6
6 int *p = (int *) malloc(sizeof(int) * 4);
p[0] = 0; p[3] = 0
[Inferior 1 (process $dec) exited normally]
...
but after switching off the on-by-default fcf-protection, we get the desired
behaviour:
...
$ gcc -O0 -g small.c -fcf-protection=none
$ gdb -batch a.out -ex start -ex step
Temporary breakpoint 1, main () at small.c:6
6 int *p = (int *) malloc(sizeof(int) * 4);
7 memset (p, 0, sizeof(p));
...
Using "set debug infrun 1", the first observable difference between the two
debug sessions is that with -fcf-protection=none we get:
...
[infrun] process_event_stop_test: stepped into dynsym resolve code
...
In this case, "in_solib_dynsym_resolve_code (malloc@plt)" returns true because
"in_plt_section (malloc@plt)" returns true.
With -fcf-protection=full, "in_solib_dynsym_resolve_code (malloc@plt)" returns
false because "in_plt_section (malloc@plt)" returns false, because the section
name for malloc@plt is .plt.sec instead of .plt, which is not handled in
in_plt_section:
...
static inline int
in_plt_section (CORE_ADDR pc)
{
return pc_in_section (pc, ".plt");
}
...
Fix this by handling .plt.sec in in_plt_section.
Tested on x86_64-linux.
[ Another requirement to be able to reproduce this is to have a dynamic linker
with a "malloc" minimal symbol, which causes find_solib_trampoline_target to
find it, such that skip_language_trampoline returns the address for the
dynamic linkers malloc. This causes the step machinery to set a breakpoint
there, and to continue, expecting to hit it. Obviously, we execute glibc's
malloc instead, so the breakpoint is not hit and we continue to program
completion. ]
gdb/ChangeLog:
2021-01-14 Tom de Vries <tdevries@suse.de>
PR breakpoints/27151
* objfiles.h (in_plt_section): Handle .plt.sec.
This commit builds on work started in the following two commits:
commit 24ed6739b6
Date: Thu Jan 30 14:35:40 2020 +0000
gdb/remote: Restore support for 'S' stop reply packet
commit cada5fc921
Date: Wed Mar 11 12:30:13 2020 +0000
gdb: Handle W and X remote packets without giving a warning
This is related to how GDB handles remote targets that send back 'S'
packets.
In the first of the above commits we fixed GDB's ability to handle a
single process, single threaded target that sends back 'S' packets.
Although the 'T' packet would always be preferred to 'S' these days,
there's nothing really wrong with 'S' for this situation.
The second commit above fixed an oversight in the first commit, a
single-process, multi-threaded target can send back a process wide
event, for example the process exited event 'W' without including a
process-id, this also is fine as there is no ambiguity in this case.
In PR gdb/26819 we run into yet another problem with the above
commits. In this case we have a single process with two threads, GDB
hits a breakpoint in thread 2 and then performs a stepi:
(gdb) b main
Breakpoint 1 at 0x1212340830: file infinite_loop.S, line 10.
(gdb) c
Continuing.
Thread 2 hit Breakpoint 1, main () at infinite_loop.S:10
10 in infinite_loop.S
(gdb) set debug remote 1
(gdb) stepi
Sending packet: $vCont;s:2#24...Packet received: S05
../binutils-gdb/gdb/infrun.c:5807: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
What happens in this case is that on the RISC-V target displaced
stepping is not supported, so when the stepi is issued GDB steps just
thread 2. As only a single thread was set running the target decides
that is can get away with sending back an 'S' packet without a
thread-id. GDB then associates the stop with thread 1 (the first
non-exited thread), but as thread 1 was not previously set executing
the assertion seen above triggers.
As an aside I am surprised that the target sends pack 'S' in this
situation. The target is happy to send back 'T' (including thread-id)
when multiple threads are set running, so (to me) it would seem easier
to just always use the 'T' packet when multiple threads are in use.
However, the target only uses 'T' when multiple threads are actually
executing, otherwise an 'S' packet it used.
Still, when looking at the above situation we can see that GDB should
be able to understand which thread the 'S' reply is referring too.
The problem is that is that in commit 24ed6739b6 (above) when a stop
reply comes in with no thread-id we look for the first non-exited
thread and select that as the thread the stop applies too.
What we should really do is select the first non-exited, resumed thread,
and associate the stop event with this thread. In the above example
both thread 1 and 2 are non-exited, but only thread 2 is resumed, so
this is what we should use.
There's a test for this issue included which works with stock
gdbserver by disabling use of the 'T' packet, and enabling
'scheduler-locking' within GDB so only one thread is set running.
gdb/ChangeLog:
PR gdb/26819
* remote.c
(remote_target::select_thread_for_ambiguous_stop_reply): New
member function.
(remote_target::process_stop_reply): Call
select_thread_for_ambiguous_stop_reply.
gdb/testsuite/ChangeLog:
PR gdb/26819
* gdb.server/stop-reply-no-thread-multi.c: New file.
* gdb.server/stop-reply-no-thread-multi.exp: New file.
Change-Id: I9b49d76c2a99063dcc76203fa0f5270a72825d15
The previous patch made the commit_resume implementations in the record
targets unnecessary, as the remote target's commit_resume implementation
won't commit-resume threads for which it didn't see a resume. This
patch removes them.
gdb/ChangeLog:
* record-btrace.c (class record_btrace_target): Remove.
(record_btrace_target::commit_resume): Remove.
* record-full.c (class record_full_target): Remove.
(record_full_target::commit_resume): Remove.
Change-Id: I3a68d3d726fb09d8b7165b4edefc330d27803b27
The next patch moves the target commit_resume method to be a
process_stratum_target-only method. The only non-process targets that
currently implement the commit_resume method are the btrace and full
record targets. The only reason they need to do so is to prevent a
commit resume from reaching the beneath (process) target if they are
currently replaying.
This is important if a record target is used on top of the remote target
(the only process target implementing the commit_resume method).
Currently, the remote target checks the `thread_info::executing` flag of
a thread to know if it should commit resume that thread:
if (!tp->executing || remote_thr->vcont_resumed)
continue;
The `tp->executing` flag is set by infrun when it has asked the target
stack to resume the thread, and therefore if the thread is executing,
from its point of view. It _not_ equivalent to whether the remote
target was asked to resume this thread.
Indeed, if infrun asks the target stack to resume some thread while the
record target is replaying, the record target won't forward the resume
request the remote target beneath, because we don't actually want to
resume the thread on the execution target. But the `tp->executing` flag
is still set, because from the point of view of infrun, the thread
executes. So, if the commit_resume call wasn't intercepted by the
record target as it is today and did reach the remote target, the remote
target would say "Oh, this thread should be executing and I haven't
vCont-resumed it! I must vCont-resume it!". But that would be wrong,
because it was never asked to resume this thread, the resume request did
not reach it. This is why the record targets currently need to
implement commit_resume: to prevent the beneath target from
commit_resuming threads it wasn't asked to resume.
Since commit_resume will become a method on process_stratum_target in
the following patch, record targets won't have a chance to intercept the
calls and that would result in the remote target commit_resuming threads
it shouldn't. To avoid this, this patch makes the remote target track
its own thread resumption state. That means, tracking which threads it
was asked to resume via target_ops::resume. Regardless of the context
of this patch, I think this change makes it easier to understand how
resume / commit_resume works in the remote target. It makes the target
more self-contained, as it only depends on what it gets asked to do via
the target methods, and not on tp->executing, which is a flag maintained
from the point of view of infrun.
I initially made it so this state was only used when the remote target
operates in non-stop mode, since commit_resume is only used when the
target is non-stop. However, it's more consistent and it can be useful
to maintain this state even in all-stop too. In all-stop, receiving a
stop notification for one thread means all threads of the target are
considered stopped.
From the point of view of the remote target, there are three states a
thread can be in:
1. not resumed
2. resumed but pending vCont-resume
3. resumed
State 2 only exists when the target is non-stop.
As of this patch, valid state transitions are:
- 1 -> 2 (through the target resume method if in non-stop)
- 2 -> 3 (through the target commit_resume method if in non-stop)
- 1 -> 3 (through the target resume method if in all-stop)
- 3 -> 1 (through a remote stop notification / reporting an event to the
event loop)
A subsequent patch will make it possible to go from 2 to 1, in case
infrun asks to stop a thread that was resumed but not commit-resumed
yet. I don't think it can happen as of now.
In terms of code, this patch replaces the vcont_resumed field with an
enumeration that explicitly represents the three states described above.
The last_resume_sig and last_resume_step fields are moved to a structure
which is clearly identified as only used when the thread is in the
"resumed but pending vCont-resume" state.
gdb/ChangeLog:
* remote.c (enum class resume_state): New.
(struct resumed_pending_vcont_info): New.
(struct remote_thread_info) <resume_state, set_not_resumed,
set_resumed_pending_vcont, resumed_pending_vcont_info,
set_resumed, m_resume_state, m_resumed_pending_vcont_info>:
New.
<last_resume_step, last_resume_sig, vcont_resumed>: Remove.
(remote_target::remote_add_thread): Adjust.
(remote_target::process_initial_stop_replies): Adjust.
(remote_target::resume): Adjust.
(remote_target::commit_resume): Rely on state in
remote_thread_info and not on tp->executing.
(remote_target::process_stop_reply): Adjust.
Change-Id: I10480919ccb4552faa62575e447a36dbe7c2d523
Add the standard arc_debug_printf, but also arc_linux_debug_printf,
arc_linux_nat_debug_printf and arc_newlib_debug_printf to match the
prefixes currently used in the debug messages.
gdb/ChangeLog:
* arc-tdep.h (arc_debug_printf): New.
* arc-tdep.c: Use arc_debug_printf.
* arc-linux-nat.c (arc_linux_nat_debug_printf): Add and use.
* arc-linux-tdep.c (arc_linux_debug_printf): Add and use.
* arc-newlib-tdep.c (arc_newlib_debug_printf): Add and use.
Change-Id: I5d937566ed7a1925f7982e8809802c8f0560d8c6
Shahab suggested we get rid of the verbosity level for the ARC debug
logging [1]. This patch does that, before doing any other change.
gdb/ChangeLog:
* arc-tdep.h (arc_debug): Change type to bool.
* arc-tdep.c (arc_debug): Change type to bool.
(arc_analyze_prologue): Adjust.
(_initialize_arc_tdep): Use add_setshow_boolean_cmd.
* arc-linux-nat.c (ps_get_thread_area): Adjust.
[1] https://sourceware.org/pipermail/gdb-patches/2021-January/175075.html
Change-Id: I16688bd42ed8978ae1acf57012c8d41a943044a5
Make it return bool and change the advice_printed to bool as well. Move
doc to header file.
gdb/ChangeLog:
* auto-load.h (file_is_auto_load_safe): Change return type to
bool, move comment here.
* auto-load.c (file_is_auto_load_safe): Change return type and
advice_printed to bool. Move comment to header.
Change-Id: Ia7395e7cea8880377800240833316e4be5251d49
... since they are defined in symfile.c.
gdb/ChangeLog:
* top.h (readnow_symbol_files, readnever_symbol_files): Move
declarations to ...
* symfile.h: ... here.
* symfile.c: Update doc.
Change-Id: Ie35a80d236bea70947bc496f66f62c8c621670b4
They are currently in target.h, it would make more sense to have them in
serial.h, since they are defined in serial.c.
gdb/ChangeLog:
* target.h (baud_rate, serial_parity): Move declarations...
* serial.h: ... here.
* main.c: Include serial.h.
* serial.c (baud_rate, serial_parity): Update doc.
Change-Id: Idc983c154c80ccc29b07ce68df3483cefe03fb71
This hook appears to be unused. I guess it was used from insight or
something like that at some point. But I grepped in today's source of
insight [1] and there was no match. So I think it's safe to remove.
gdb/ChangeLog:
* top.c (pre_init_ui_hook): Remove.
[1] https://sourceware.org/git/?p=insight.git
Change-Id: Ia14499a4b6b9d79bb9a526d635fe44a654ef2a27
Consider this GDB session:
(gdb) set language fortran
(gdb) set debug expression 1
(gdb) p .TRUE.
Dump of expression @ 0x4055d90, before conversion to prefix form:
Language fortran, 3 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_BOOL 79 O...............
1 BINOP_ADD 1 ................
2 OP_BOOL 79 O...............
Dump of expression @ 0x4055d90, after conversion to prefix form:
Expression: `TRUE'
Language fortran, 3 elements, 16 bytes each.
0 OP_BOOL Unknown format
1 BINOP_ADD
2 OP_BOOL Unknown format
3 OP_NULL Unknown format
$1 = .TRUE.
The final dump of the OP_BOOL is completely wrong. After this patch
we now get:
(gdb) set language fortran
(gdb) set debug expression 1
(gdb) p .TRUE.
Dump of expression @ 0x2d07470, before conversion to prefix form:
Language fortran, 3 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_BOOL 79 O...............
1 BINOP_ADD 1 ................
2 OP_BOOL 79 O...............
Dump of expression @ 0x2d07470, after conversion to prefix form:
Expression: `TRUE'
Language fortran, 3 elements, 16 bytes each.
0 OP_BOOL TRUE
$1 = .TRUE.
Much better. I added a test for this into the Fortran testsuite.
gdb/ChangeLog:
* expprint.c (dump_subexp_body_standard): Handle OP_BOOL.
gdb/testsuite/ChangeLog:
* gdb.fortran/debug-expr.exp: Add new tests.
Fortran supports symbol based comparison operators as well as the
classic text based comparison operators, so we have:
Text | Symbol
Operator | Operator
---------|---------
.eq. | ==
.ne. | /=
.le. | <=
.ge. | >=
.gt. | >
.lt. | <
This commit adds the symbol based operators as well as some tests.
gdb/ChangeLog:
* f-exp.y (dot_ops): Rename to...
(fortran_operators): ...this. Add a header comment. Add symbol
based operators.
(yylex): Update to use fortran_operators not dot_ops. Remove
special handling for '**', this is now included in
fortran_operators.
gdb/testsuite/ChangeLog:
* gdb.fortran/dot-ops.exp: Add new tests.
I haven't tried this on an actual aarch64 machine, but I am able to
exercise it like this:
(gdb) set debug aarch64
(gdb) maintenance selftest aa
Running selftest aarch64-analyze-prologue.
[aarch64] aarch64_analyze_prologue: prologue analysis gave up addr=0x14 opcode=0xf94013e0
Running selftest aarch64-process-record.
Ran 2 unit tests, 0 failed
gdb/ChangeLog:
* arch/aarch64-insn.h (aarch64_debug_printf): New.
* arch/aarch64-insn.c: Use aarch64_debug_printf.
* aarch64-tdep.c: Use aarch64_debug_printf.
Change-Id: Ifdb40e2816ab8e55a9aabb066d1833d9b5a46094
This is only compile-tested.
gdb/ChangeLog:
* solib-aix.c (solib_aix_debug_printf): New, use throughout
file.
Change-Id: I7ec4baa15ab5b8ad786212b8b9de61c2c447bac1
PR 23672 points out a crash in compile_to_object. This crash came in
during a C++-ization. This patch avoids the crash.
The PR also points out another weird behavior in this code, but that
one requires some setup that I don't have here, and it seems to date
back to the introduction of the compile feature. So, it isn't
addressed here. I will leave the PR open so this bug isn't forgotten.
gdb/ChangeLog
2021-01-09 Tom Tromey <tom@tromey.com>
PR compile/23672
* compile/compile.c (compile_to_object): Avoid crash when
osabi_triplet_regexp returns NULL.
The tracepoint code uses print_expression to reconstruct an expression
string. However, the original expression is already available -- it
was just parsed a bit earlier in the same function. This patch
changes this code to simply save the already-parsed expression, rather
than attempt to reconstruct it.
gdb/ChangeLog
2021-01-09 Tom Tromey <tom@tromey.com>
* tracepoint.h (class collection_list) <append_exp>: Take a
std::string.
* tracepoint.c (collection_list::append_exp): Take a std::string.
(encode_actions_1): Update.
An earlier patch pointed out that nothing in GDB sets void_context_p
when parsing an expression. This patch fixes this omission.
"print" and "call" differ in that the former will print a value that
has void type, while the latter will not. AdaCore has had a patch for
a long time that uses this distinction to help with overload
resolution. In particular, in a "call" context, a procedure will be
chosen, while in a "print" context, a zero-argument function will be
chosen instead.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-01-08 Tom Tromey <tromey@adacore.com>
* parse.c (parse_expression): Add void_context_p parameter. Use
parse_exp_in_context.
* printcmd.c (print_command_1): Change voidprint to bool. Pass to
parse_expression.
(print_command, call_command): Update.
* expression.h (parse_expression): Add void_context_p parameter.
gdb/testsuite/ChangeLog
2021-01-08 Tom Tromey <tromey@adacore.com>
* gdb.ada/voidctx/pck.adb: New file.
* gdb.ada/voidctx/pck.ads: New file.
* gdb.ada/voidctx/voidctx.adb: New file.
* gdb.ada/voidctx.exp: New file.
Consider this Fortran type:
type :: some_type
integer, allocatable :: array_one (:,:)
integer :: a_field
integer, allocatable :: array_two (:,:)
end type some_type
And a variable declared:
type(some_type) :: some_var
Now within GDB we try this:
(gdb) set $a = some_var
(gdb) p $a
$1 = ( array_one =
../../src/gdb/value.c:3968: internal-error: Unexpected lazy value type.
Normally, when an internalvar ($a in this case) is created, it is
non-lazy, the value is immediately copied out of the inferior into
GDB's memory.
When printing the internalvar ($a) GDB will extract each field in
turn, so in this case `array_one`. As the original internalvar is
non-lazy then the extracted field will also be non-lazy, with its
contents immediately copied from the parent internalvar.
However, when the field has a dynamic type this is not the case, in
value_primitive_field we see that any field with dynamic type is
always created lazy. Further, the content of this field will usually
not have been captured in the contents buffer of the original value, a
field with dynamic location is effectively a pointer value contained
within the parent value, with rules in the DWARF for how to
dereference the pointer.
So, we end up with a lazy lval_internalvar_component representing a
field within an lval_internalvar. This eventually ends up in
value_fetch_lazy, which currently does not support
lval_internalvar_component, and we see the error above.
My original plan for how to handle this involved extending
value_fetch_lazy to handle lval_internalvar_component. However, when
I did this I ran into another error:
(gdb) set $a = some_var
(gdb) p $a
$1 = ( array_one = ((1, 1) (1, 1) (1, 1)), a_field = 5, array_two = ((0, 0, 0) (0, 0, 0)) )
(gdb) p $a%array_one
$2 = ((1, 1) (1, 1) (1, 1))
(gdb) p $a%array_one(1,1)
../../src/gdb/value.c:1547: internal-error: void set_value_address(value*, CORE_ADDR): Assertion `value->lval == lval_memory' failed.
The problem now is inside set_value_component_location, where we
attempt to set the address for a component if the original parent
value has a dynamic location. GDB does not expect to ever set the
address on anything other than an lval_memory value (which seems
reasonable).
In order to resolve this issue I initially thought about how an
internalvar should "capture" the value of a program variable at the
moment the var is created. In an ideal world (I think) GDB would be
able to do this even for values with dynamic type. So in our above
example doing `set $a = some_var` would capture the content of
'some_var', but also the content of 'array_one', and also 'array_two',
even though these content regions are not contained within the region
of 'some_var'.
Supporting this would require GDB values to be able to carry around
multiple non-contiguous regions of memory as content in some way,
which sounds like a pretty huge change to a core part of GDB.
So, I wondered if there was some other solution that wouldn't require
such a huge change.
What if values with a dynamic location were though of like points with
automatic dereferencing? Given this C structure:
struct foo_t {
int *val;
}
struct foo_t my_foo;
Then in GDB:
(gdb) $a = my_foo
We would expect GDB to capture the pointer value in '$a', but not the
value pointed at by the pointer. So maybe it's not that unreasonable
to think that given a dynamically typed field GDB will capture the
address of the content, but not the actual content itself.
That's what this patch does.
The approach is to catch this case in set_value_component_location.
When we create a component location (of an lval_internalvar) that has
a dynamic data location, the lval_internalvar_component is changed
into an lval_memory. After this, both of the above issues are
resolved. In the first case, the lval_memory is still lazy, but
value_fetch_lazy knows how to handle that. In the second case, when
we access an element of the array we are now accessing an element of
an lval_memory, not an lval_internalvar_component, and calling
set_value_address on an lval_memory is fine.
gdb/ChangeLog:
* value.c (set_value_component_location): Adjust the VALUE_LVAL
for internalvar components that have a dynamic location.
gdb/testsuite/ChangeLog:
* gdb.fortran/intvar-dynamic-types.exp: New file.
* gdb.fortran/intvar-dynamic-types.f90: New file.
The function create_exception_master_breakpoint in gdb/breakpoint.c attempts
to set a master exception breakpoint in each objfile. It tries this using
a libgcc/unwind probe, and if that fails then using the
_Unwind_DebugHook symbol:
...
for (objfile *objfile : current_program_space->objfiles ())
{
/* Try using probes. */
if (/* successful */)
continue;
/* Try using _Unwind_DebugHook */
}
...
The preference scheme works ok both if the objfile has debug info, and if it's
stripped.
But it doesn't work when the objfile has a .gnu_debuglink to a .debug file
(and the .debug file is present). What happens is that:
- we first encounter objfile libgcc.debug
- we try using probes, and this fails
- so we try _Unwind_DebugHook, which succeeds
- next we encounter objfile libgcc
- we try using probes, and this succeeds.
So, we end up with a master exception breakpoint in both libgcc (using probes)
and libgcc.debug (using _Unwind_DebugHook).
This eventually causes:
...
(gdb) PASS: gdb.cp/nextoverthrow.exp: post-check - next over a throw 3
next^M
src/gdb/infrun.c:6384: internal-error: \
void process_event_stop_test(execution_control_state*): \
Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' \
failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) FAIL: gdb.cp/nextoverthrow.exp: next
past catch (GDB internal error)
...
To trigger this internal-error, we need to use gcc-10 or later to compile the
test-case, such that it contains the fix for gcc PR97774 - "Incorrect line
info for try/catch".
Fix this by only trying to install the master exception breakpoint in
libgcc.debug using the _Unwind_DebugHook method, if the install using probes
in libgcc failed.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-01-08 Tom de Vries <tdevries@suse.de>
PR gdb/26881
* breakpoint.c (create_exception_master_breakpoint_probe)
(create_exception_master_breakpoint_hook): Factor out
of ...
(create_exception_master_breakpoint): ... here. Only try to install
the master exception breakpoint in objfile.debug using the
_Unwind_DebugHook method, if the install using probes in objfile
failed.
Since this commit:
commit a5c641b57b
Date: Thu Oct 8 16:45:59 2020 +0100
gdb/fortran: Add support for Fortran array slices at the GDB prompt
A bug was introduced into GDB. Consider this Fortan array:
integer, dimension (1:10) :: array
array = 1
Now inside GDB:
(gdb) set $var = array
(gdb) set $var(1) = 2
Left operand of assignment is not an lvalue.
The problem is that the new code for slicing Fortran arrays now does
not set the lval type correctly for arrays that are not in memory.
This is easily fixed by making use of value_from_component.
After this the above example behaves as you'd expect.
gdb/ChangeLog:
* f-lang.c (fortran_value_subarray): Call value_from_component.
gdb/testsuite/ChangeLog:
* gdb.fortran/intvar-array.exp: New file.
* gdb.fortran/intvar-array.f90: New file.
This allows gdb to quickly dump & process the memory map that the sim
knows about. This isn't fully accurate, but is largely limited by the
gdb memory map format. While the sim supports RWX bits, gdb can only
handle RW or RO regions.
An earlier patch to ada-lang.c:do_full_match introduced a subtle
change to the semantics. The previous code did:
- if (strncmp (sym_name, search_name, search_name_len) == 0
- && is_name_suffix (sym_name + search_name_len))
- return true;
-
- if (startswith (sym_name, "_ada_")
whereas the new code unconditionally skips a leading "_ada_".
The difference occurs if the lookup name itself starts with "_ada_".
In this case, the symbol won't match.
Normally this doesn't seem to be a problem. However, it caused a
regression on one particular (internal) test case on one particular
platform.
This patch changes the code to handle this case. I don't know how to
write a reliable test case for this, so no test is included.
2021-01-07 Tom Tromey <tromey@adacore.com>
* ada-lang.c (do_full_match): Conditionally skip "_ada_" prefix.
A recent upstream patch of mine caused a regression in aggregate
assignment. The bug was that add_component_interval didn't properly
update the array contents in one resize case.
I found furthermore that there was no test case that would provoke
this failure. This patch fixes the bug and introduces a test.
gdb/ChangeLog
2021-01-07 Tom Tromey <tromey@adacore.com>
* ada-lang.c (add_component_interval): Start loop using vector's
updated size.
gdb/testsuite/ChangeLog
2021-01-07 Tom Tromey <tromey@adacore.com>
* gdb.ada/assign_arr.exp: Add 'others' test.
Testing showed that gdb was not correctly handling some fixed-point
binary operations correctly.
Addition and subtraction worked by casting the result to the type of
left hand operand. So, "fixed+int" had a different type -- and
different value -- from "int+fixed".
Furthermore, for multiplication and division, it does not make sense
to first cast both sides to the fixed-point type. For example, this
can prevent "f * 1" from yielding "f", if 1 is not in the domain of
"f". Instead, this patch changes gdb to use the value. (This is
somewhat different from Ada semantics, as those can yield a "universal
fixed point".)
This includes a new test case. It is only run in "minimal" mode, as
the old-style fixed point works differently, and is obsolete, so I
have no plans to change it.
gdb/ChangeLog
2021-01-06 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD, BINOP_SUB>:
Do not cast result.
* valarith.c (fixed_point_binop): Handle multiplication
and division specially.
* valops.c (value_to_gdb_mpq): New function.
(value_cast_to_fixed_point): Use it.
gdb/testsuite/ChangeLog
2021-01-06 Tom Tromey <tromey@adacore.com>
* gdb.ada/fixed_points/pck.ads (Delta4): New constant.
(FP4_Type): New type.
(FP4_Var): New variable.
* gdb.ada/fixed_points/fixed_points.adb: Update.
* gdb.ada/fixed_points.exp: Add tests for binary operators.
tui_win_info::refresh_window simply calls wrefresh, which internally
does a doupdate.
This redraws the source background window without the source pad.
Then prefresh of the source pad draws the actual source code on top,
which flickers.
By changing this to wnoutrefresh, the actual drawing on the screen is
only done once in the following prefresh, without flickering.
gdb/ChangeLog:
2021-01-05 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-winsource.c (tui_source_window_base::refresh_window):
Call wnoutrefresh instead of tui_win_info::refresh_window.
There a 2 spaces between the numbers and source code, but only one of
them was redrawn.
So if you increase the source window height, the second space keeps the
character of the border rectangle.
With this both spaces are redrawn, so the border rectangle character is
overwritten.
gdb/ChangeLog:
2021-01-05 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-source.c (tui_source_window::show_line_number):
Redraw second space after line number.
The smaxrow and smaxcol parameters of prefresh are the bottom right corner
of the text area inclusive, not exclusive.
And if the source window grows bigger in height, the pad has to grow as
well.
gdb/ChangeLog:
2021-01-05 Hannes Domani <ssbssa@yahoo.de>
PR tui/26927
* tui/tui-winsource.c (tui_source_window_base::refresh_window):
Fix source pad size in prefresh.
(tui_source_window_base::show_source_content): Grow source pad
if necessary.
While working on PR26935 I noticed that when running test-case
gdb.base/morestack.exp with target board unix/-m32/-fPIE/-pie and ld linker,
I get this linetable fragment for morestack.S using readelf -wL:
...
CU: ../../../../libgcc/config/i386/morestack.S:
Line number Starting address View Stmt
109 0xc9c x
...
838 0xe03 x
- 0xe04
636 0 x
637 0x3 x
- 0x4
...
but with "maint info line-table" I get:
...
INDEX LINE ADDRESS IS-STMT
0 END 0x00000004 Y
1 109 0x00000c9c Y
...
110 838 0x00000e03 Y
111 END 0x00000e04 Y
...
So, apparently the entries with addresses 0x0 and 0x3 are filtered out
because the addresses are out of range, but the same doesn't happen with the
end-of-seq terminator.
Fix this by filtering out end-of-seq terminators that do not actually
terminate anything.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-01-04 Tom de Vries <tdevries@suse.de>
* buildsym.c (buildsym_compunit::record_line): Filter out end-of-seq
terminators that do not terminate anything.
gdb/testsuite/ChangeLog:
2021-01-04 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: New file.
I spent a lot of time reading infrun debug logs recently, and I think
they could be made much more readable by being indented, to clearly see
what operation is done as part of what other operation. In the current
format, there are no visual cues to tell where things start and end,
it's just a big flat list. It's also difficult to understand what
caused a given operation (e.g. a call to resume_1) to be done.
To help with this, I propose to add the new scoped_debug_start_end
structure, along with a bunch of macros to make it convenient to use.
The idea of scoped_debug_start_end is simply to print a start and end
message at construction and destruction. It also increments/decrements
a depth counter in order to make debug statements printed during this
range use some indentation. Some care is taken to handle the fact that
debug can be turned on or off in the middle of such a range. For
example, a "set debug foo 1" command in a breakpoint command, or a
superior GDB manually changing the debug_foo variable.
Two macros are added in gdbsupport/common-debug.h, which are helpers to
define module-specific macros:
- scoped_debug_start_end: takes a message that is printed both at
construction / destruction, with "start: " and "end: " prefixes.
- scoped_debug_enter_exit: prints hard-coded "enter" and "exit"
messages, to denote the entry and exit of a function.
I added some examples in the infrun module to give an idea of how it can
be used and what the result looks like. The macros are in capital
letters (INFRUN_SCOPED_DEBUG_START_END and
INFRUN_SCOPED_DEBUG_ENTER_EXIT) to mimic the existing SCOPE_EXIT, but
that can be changed if you prefer something else.
Here's an excerpt of the debug
statements printed when doing "continue", where a displaced step is
started:
[infrun] proceed: enter
[infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
[infrun] global_thread_step_over_chain_enqueue: enqueueing thread Thread 0x7ffff75a5640 (LWP 2289301) in global step over chain
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 1
[infrun] start_step_over: resuming [Thread 0x7ffff75a5640 (LWP 2289301)] for step-over
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [Thread 0x7ffff75a5640 (LWP 2289301)] at 0x5555555551bd
[displaced] displaced_step_prepare_throw: displaced-stepping Thread 0x7ffff75a5640 (LWP 2289301) now
[displaced] prepare: selected buffer at 0x5555555550c2
[displaced] prepare: saved 0x5555555550c2: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] amd64_displaced_step_copy_insn: copy 0x5555555551bd->0x5555555550c2: c7 45 fc 00 00 00 00 eb 13 8b 05 d4 2e 00 00 83
[displaced] displaced_step_prepare_throw: prepared successfully thread=Thread 0x7ffff75a5640 (LWP 2289301), original_pc=0x5555555551bd, displaced_pc=0x5555555550c2
[displaced] resume_1: run 0x5555555550c2: c7 45 fc 00
[infrun] infrun_async: enable=1
[infrun] prepare_to_wait: prepare_to_wait
[infrun] start_step_over: [Thread 0x7ffff75a5640 (LWP 2289301)] was resumed.
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: resuming Thread 0x7ffff7da7740 (LWP 2289296)
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7da7740 (LWP 2289296)] at 0x7ffff7f7d9b7
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: resuming Thread 0x7ffff7da6640 (LWP 2289300)
[infrun] resume_1: thread Thread 0x7ffff7da6640 (LWP 2289300) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: [Thread 0x7ffff75a5640 (LWP 2289301)] resumed
[infrun] proceed: resuming Thread 0x7ffff6da4640 (LWP 2289302)
[infrun] resume_1: thread Thread 0x7ffff6da4640 (LWP 2289302) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: exit
We can easily see where the call to `proceed` starts and end. We can
also see why there are a bunch of resume_1 calls, it's because we are
resuming threads, emulating all-stop on top of a non-stop target.
We also see that debug statements nest well with other modules that have
been migrated to use the "new" debug statement helpers (because they all
use debug_prefixed_vprintf in the end. I think this is desirable, for
example we could see the debug statements about reading the DWARF info
of a library nested under the debug statements about loading that
library.
Of course, modules that haven't been migrated to use the "new" helpers
will still print without indentations. This will be one good reason to
migrate them.
I think the runtime cost (when debug statements are disabled) of this is
reasonable, given the improvement in readability. There is the cost of
the conditionals (like standard debug statements), one more condition
(if (m_must_decrement_print_depth)) and the cost of constructing a stack
object, which means copying a fews pointers.
Adding the print in fetch_inferior_event breaks some tests that use "set
debug infrun", because it prints a debug statement after the prompt. I
adapted these tests to cope with it, by using the "-prompt" switch of
gdb_test_multiple to as if this debug statement is part of the expected
prompt. It's unfortunate that we have to do this, but I think the debug
print is useful, and I don't want a few tests to get in the way of
adding good debug output.
gdbsupport/ChangeLog:
* common-debug.h (debug_print_depth): New.
(struct scoped_debug_start_end): New.
(scoped_debug_start_end): New.
(scoped_debug_enter_exit): New.
* common-debug.cc (debug_prefixed_vprintf): Print indentation.
gdb/ChangeLog:
* debug.c (debug_print_depth): New.
* infrun.h (INFRUN_SCOPED_DEBUG_START_END): New.
(INFRUN_SCOPED_DEBUG_ENTER_EXIT): New.
* infrun.c (start_step_over): Use
INFRUN_SCOPED_DEBUG_ENTER_EXIT.
(proceed): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT and
INFRUN_SCOPED_DEBUG_START_END.
(fetch_inferior_event): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT.
gdbserver/ChangeLog:
* debug.cc (debug_print_depth): New.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Expect infrun debug print after
prompt.
* gdb.threads/ia64-sigill.exp: Likewise.
* gdb.threads/watchthreads-reorder.exp: Likewise.
Change-Id: I7c3805e6487807aa63a1bae318876a0c69dce949
