| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Usually with test-case gdb.python/py-progspace-events.exp I get:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 4116] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M
28 { /* Nothing. */ }^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
step^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabf4f850>^M
do_parent_stuff () at py-progspace-events.c:41^M
41 ++global_var;^M
(gdb) PASS: gdb.python/py-progspace-events.exp: step
...
But occasionally I run into the following FAIL:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
(gdb) FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout)
...
This is caused by a race between the handling of an event, and the
"inferior 1" command.
In the passing case, the event is handled first. During which prune_inferiors
is called, but it can't remove inferior 2, because it's still the current one.
In the failing case, the "inferior 1" command is handled first. Then during
handling of the event, prune_inferiors is called, and it can remove inferior 2
because it's no longer the current one.
This looks like a test-case issue to me, but ISTM that we can do better: by
calling prune_inferiors asap, at the end of the "inferior 1" command, we
stabilize the moment when the inferior is removed:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
...
This also allows us to simplify the test-case by removing the step command,
which is no longer required to trigger the pruning of the inferior.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR gdb/31440
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440
|
|
The relatively new "globals" scope code in DAP has a fairly obvious
bug -- the fetch_one_child method should return a tuple with two
elements, but instead just returns the variable's value.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada
print pck.fp1_var^M
$1 = 0.3125^M
(gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var
...
The problem is that the thumb prologue analyzer overshoot, setting the
breakpoint for main after line 49:
...
46 int
47 main (void)
48 {
49 pck__fp1_var++;
...
and consequently we see the value of pck.fp1_var after line 49 instead of
before line 49. This is PR tdep/31981.
Work around this by removing line 49 and all similar subsequent lines, which
turn out to be dead code.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on arm-linux.
|
|
On arm-linux I run into:
...
(gdb) p *kernel_user_helper_version^M
Cannot access memory at address 0xffff0ffc^M
(gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version
...
What the test-case is trying to do, is to access a special address in the arm
linux kernel [1] using ptrace, which doesn't seem to work.
This is with kernel version 6.1.55. Perhaps this used to work, but the kernel
was modified to be more strict with respect to access to this special address.
Fix this by making the inferior access that special address instead.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/32070
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070
[1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
|
|
My previous patch
commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD)
Author: Felix Willgerodt <felix.willgerodt@intel.com>
Date: Mon Feb 25 15:30:29 2019 +0100
python: Add clear() to gdb.Record.
exposed a clear function for btrace data in python and added some tests
for it. That caused a regression (PR 32086) when recording with bts.
This is reproducible even without my patch, when adding
"maintenance btrace clear" to the test.
When comparing the instructions that get recorded in both cases, the traces
are almost identical, just that the first 3 instructions are missing.
Before clear:
(gdb) record instruction-history 1,100
1 0x0000555555555163 <main+12>: movl $0x0,-0x4(%rbp)
2 0x000055555555516a <main+19>: movl $0x0,-0x8(%rbp)
3 0x0000555555555171 <main+26>: jmp 0x555555555184 <main+45>
4 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
5 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
6 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
7 0x0000555555555176 <main+31>: mov %eax,%edi
...
After clear:
(gdb) record instruction-history 1,100
1 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
2 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
3 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
4 0x0000555555555176 <main+31>: mov %eax,%edi
...
The GDB manual describes this behaviour already:
maint btrace clear
Discard the branch trace data. The data will be fetched anew and
the branch trace will be recomputed when needed.
This implicitly truncates the branch trace to a single branch trace
buffer. When updating branch trace incrementally, the branch trace
available to GDB may be bigger than a single branch trace buffer.
The test with BTS is updating the recorded trace incrementally. After the
clear, the buffer of raw trace data available is not enough to recompute the
whole trace as it was before the clear(), and the first 3 instructions are
missing.
As increasing the buffer size for BTS didn't help, I propose to fix the test
by moving the testing of clear to the end of the test.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086
|
|
While working on something else, I noticed that this is relatively
common:
scoped_restore_current_language save;
set_language (something);
This patch adds a second constructor to
scoped_restore_current_language to simplify this idiom.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
I think it would be useful for gdb's DAP logs to come with the version
and configuration information. This might make debugging some bug
reports a little simpler.
|
|
A DAP user noticed that breakpoints set by address were never updated
to show their location after the DAP launch request. It turns out
that gdb does not emit the breakpoint-modified event when this sort of
breakpoint is updated.
This patch changes gdb to notify the breakpoint-modified observer when
a breakpoint location's symbol changes. This in turn causes the DAP
event to be emitted.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
While working on earlier patches, I noticed that the DAP C++ exception
test had some strange results in the log. Digging into this, I found
that while the Ada catchpoints emit a "bkptno" field in the MI result,
the C++ ones do not -- but the DAP code was relying on this.
This patch fixes the problem by changing which field is examined, and
then updates the tests to verify this.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Currently, when a DAP client uses setInstructionBreakpoints, the
resulting breakpoints are created as "verified", even though there is
no symbol file and thus the breakpoint can't possibly have a source
location.
This patch changes the DAP code to assume that all breakpoints are
unverified before launch.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This adds a new exec_mi_and_log function that wraps gdb.execute_mi and
logs the command. This can be handy when debugging DAP.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
I noticed that initialize_block_iterator has a default value for one
of its arguments, but this is not needed as this function has a single
caller that always passes all arguments. This patch removes the
default. Tested by rebuilding.
|
|
Call the ptwrite filter function whenever a ptwrite event is decoded.
The returned string is written to the aux_data string table and a
corresponding auxiliary instruction is appended to the function segment.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
By default GDB will be printing the hex payload of the ptwrite package as
auxiliary information. To customize this, the user can register a ptwrite
filter function in python, that takes the payload and the PC as arguments and
returns a string which will be printed instead. Registering the filter
function is done using a factory pattern to make per-thread filtering easier.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
Enable ptwrite in the PT config, if it is supported by the kernel.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
This enables gdb and gdbserver to communicate about ptwrite support. If
ptwrite support would be enabled unconditionally, GDBs with older libipt
versions would break.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This function allows to clear the trace data from python, forcing to
re-decode the trace for successive commands.
This will be used in future ptwrite patches, to trigger re-decoding when
the ptwrite filter changes.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
Auxiliary instructions are no real instructions and get their own object
class, similar to gaps. gdb.Record.instruction_history is now possibly a
list of gdb.RecordInstruction, gdb.RecordGap or gdb.RecordAuxiliary
objects.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Print the auxiliary data when stepping. Don't allow to goto an auxiliary
instruction.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
is encountered in the function-call-history. Printing is
active by default, it can be silenced with the /a modifier.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
is encountered in the instruction-history. Printing is active by default,
it can be silenced with the /a modifier.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Auxiliary instructions are pseudo instructions pointing to auxiliary data.
This auxiliary data can be printed in all commands displaying (record
function-call-history, record instruction-history) or stepping through
(stepi etc.) the execution history, which will be introduced in the next
commits.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
While reviewing this commit:
commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528
Date: Tue Aug 6 19:34:18 2024 +0200
Mark unavailable bytes of limited-length arrays when allocating contents
I spotted that there was some code in value::record_latest relating to
limited-length arrays which appeared redundant. The code was added
with the first introduction on limited-length arrays in commit:
commit a0c07915778486a950952139d27c01d4285b02b4
Date: Fri Feb 10 23:49:19 2023 +0000
GDB: Introduce limited array lengths while printing values
The code in question is in value::record_latest. When the value being
recorded is lazy we need to fetch its value before adding it to the
history list. The code I spotted checks to see if the value is lazy,
if we currently have array limiting in effect, and if we do sets
m_limited_length to max_value_size before finally calling fetch_lazy.
The first thing fetch_lazy does is call allocate_contents to setup the
value's buffer, and in allocate_contents we perform the same set of
checks: if the value is an array, and array length limiting is in
effect then only allocate max_value_size buffer for the contents.
In ::allocate_contents the `if` condition check is spread out between
::allocate_contents and ::set_limited_array_length, but I'm certain
it's checking the same condition.
As such the checks and m_limited_length adjustment in ::record_latest
is redundant and can be removed.
Out of curiosity I went back to the original a0c07915778486a commit
and removed the same block of code from record_latest_value (as
value::record_latest was called back then) and non of the tests added
by commit a0c07915778486a failed. I think this block of code was
never needed.
Anyway, I removed the unnecessary code and retested and there are no
regressions.
There should be no user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
This is a very small patch to straighten out dot-space-space in these
comments in the gdbarch generated files:
- /* Skip verify of short_bit, invalid_p == 0 */
+ /* Skip verify of short_bit, invalid_p == 0. */
There is no functional change after this commit.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This patch simplifies typename_concat, changing the return type and
removing the obstack allocation code. The latter is possible because
the only caller using this mode uses the name when creating a new
type, and 'new_type' copies the string to the appropriate obstack
anyway. It also changes typename_concat to use 'concat'. This change
lets us remove a mildly fragile macro as well.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
There are a couple of ways that readline wrapping can be disabled:
- using "set horizontal-scroll-mode on" in INPUTRC,
- using a TERM setting like TERM=dumb, and
- building gdb with stub-termcap.
Using a trigger patch in default_gdb_init that adds
"set horizontal-scroll-mode on" to INPUTRC:
...
- setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"]
+ setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"]
...
we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in
PR testsuite/31201 (which was reported for the stub-termcap case):
...
WARNING: timeout in accept_gdb_output
Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1):
0 Quit
1 <89012345678901234567890123456789W
2
...
23
FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap
...
Fix this by accepting the horizontal-scroll-mode style output. We do
this only when in CLI mode though, when in TUI wrapping works as before
because it doesn't rely on readline.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
|
|
amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards
incompatible changes. Adjust the amd-dbgapi target code accordingly.
Given that the AMD GPU port in upstream GDB today is of limited use
(it's still missing important pieces), we don't really care about
supporting amd-dbgapi versions other than the latest stable one, so no
effort is made to keep compatibility with versions 6.1.2 and older.
The changes are:
- AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to
AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists
but is deprecated), use the latter.
- In the callbacks structure, the get_os_pid callback was replaced with
client_process_get_info, which is more general and extensible.
Convert our get_os_pid to a new, equivalent, client_process_get_info
callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE
query, but just return "not available".
- The xfer_global_memory callback was added to the callbacks structure,
add that new callback.
- Update configure.ac to check for amd-dbgapi >= 0.75.0.
Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981
Approved-By: Lancelot Six <lancelot.six@amd.com>
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
Make the current inferior reference bubble up one level. I think this
makes it clearer what gdbarch_update_p, which is update the passed
inferior's architecture (although the function name could probably be
better).
When gdbarch_find_by_info, it is possible for the new architecture's
init callback to be called. I have not audited all of them (there are
just too many), it's possible that some of them do care about the
current inferior, for some reason (for instance, if one of them makes a
target call). If so, they should be changed too.
Change-Id: I89f012188d7fdca395a830f4b013743565f26847
|
|
Make the current inferior reference bubble up one level.
Change-Id: I441f954877749dc5a861ab03e881b529dafc2efd
|
|
When reading this test (in the context of PR 31331), I had trouble
understanding the tests, because of the abbreviated names. I would
prefer if the names were a bit more explicit, like this.
Change-Id: I85669b238a9d5dacf673a7bbfc1ca18f80d2b2cf
|
|
I think that `using` is easier to read than `typedef`, and it's the
modern C++ thing anyway.
Change-Id: Iccb62dc3869cddfb6a684ef3023dcd5b799f3ab2
|
|
QNX Neutrino support was removed here [1], but I forgot to mention in in
NEWS.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=36fb20fa93484b104d91e42e38930ee8629192ab
Change-Id: I8db7957acdd0be3c1e0b751c7c245870c4cd7101
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
Make the current program space reference bubble up one level. Use a
program space from the context whenever that makes sense.
Change-Id: Id3b0bf4490178d71a9aecdbf404b9287c22b30f5
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Make the current_program_space reference bubble up one level.
Change-Id: Ic349dc96b7d375ad7c66022d84657136f0de8c87
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Make the current_program_space references bubble up one level. In this
case, I think it makes sense to use m_objfile's program space.
Change-Id: Ibecb89b5e8a0363328240f1675d0fb95ff99c99a
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
>From what I can see, lookup_minimal_symbol doesn't have any dependencies
on the global current state other than the single reference to
current_program_space. Add a program_space parameter and make that
current_program_space reference bubble up one level.
Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Now that lookup_minimal_symbol has default values for sfile and objf,
calling lookup_bound_minimal_symbol is identical to calling
lookup_minimal_symbol without sfile and objf. Remove
lookup_bound_minimal_symbol, replace call sites with
lookup_minimal_symbol.
Change-Id: I0a420fb56de1de8bee8a7303228c9e4546e3577b
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Most calls to lookup_minimal_symbol don't pass a value for sfile and
objf. Make these parameters optional (have a default value of
nullptr). And since passing a value to `objf` is much more common than
passing a value to `sfile`, swap the order so `objf` comes first, to
avoid having to pass a nullptr value to `sfile` when wanting to pass a
value to `objf`.
Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This is a simple find / replace from "struct bound_minimal_symbol" to
"bound_minimal_symbol", to make things shorter and more consisten
througout. In some cases, move variable declarations where first used.
Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Now that the nto port is removed, this is unused.
Change-Id: I86565310cdbcde17a837eb10585cdd153f4f03d8
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Remove the support for the QNX Neutrino OS (tdep and native bits). This
has been unmaintained for years, and we don't have a way to see if it
works (or even builds, for the native parts). Without somebody actively
maintaining it, this is just a burden for developers, especially that
this port does a few weird unique things that require reasoning about
when doing big change.
Support for GDBserver was removed in 2020, commit 613f149a90d6
("gdbserver: remove support for Neutrino").
Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Following this suggestion:
https://inbox.sourceware.org/gdb-patches/2a0520ec-ccfe-4fc3-b051-7b8c60294de5@efficios.com/T/#md537792a1871addf153f3e406224f9baf025414a
Change-Id: I30988c46505f130ca16155891958f92621cada97
Approved-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This adds a missing allow_tui_tests guard.
When tui is not enabled this test case does
typically fail:
FAIL: gdb.base/new-ui.exp: do_test_invalid_args: new-ui with tui
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
The 'list' command prints around the 'main' function if the current
source location is not set. The prologue of 'main' is skipped and the
first real line of 'main' is offset by 'lines_to_print - 1'. This is
incorrect, the location should be defaulted to main's prologue without
applying offsets (similar to 'list main'). Printing around the selected
line is then done in 'list_around_line'.
The patch also fixes an issue if the list command is used before the
program is started. For example, with the following code:
26 static void attribute ((used)) ambiguous_fun (void) {}
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
37
38 int
39 main (void)
40 {
41 return 0;
42 }
GDB offsets the relevant line by 'lines_to_print - 1' and then by another
'lines_to_print / 2' and prints:
(gdb) list
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
With this patch, GDB correctly prints:
37
38 int
39 main (void)
40 {
41 return 0;
42 }
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Inspired by the trigger patch I used here [1], I tried this in
gdbpy_print_insn:
...
/* Call into the registered disassembler to (possibly) perform the
disassembly. */
+ set_quit_flag ();
PyObject *insn_disas_obj = (PyObject *) disasm_info;
gdbpy_ref<> result (PyObject_CallFunctionObjArgs (hook.get (),
insn_disas_obj,
...
and with test-case gdb.python/py-disasm-exec.exp ran into:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x00000000004101ac <+0>: Python Exception <class 'KeyboardInterrupt'>: ^M
^M
unknown disassembler error (error = -1)^M
(gdb)
...
This is incorrect, the KeyboardInterrupt should propagate and interrupt the
command.
Fix this by using gdbpy_print_stack_or_quit instead of gdbpy_print_stack in
gdbpy_print_insn, giving us instead:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x00000000004101ac <+0>: ^M
Quit^M
(gdb)
...
Tested on aarch64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-July/210798.html
|
|
In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while
disassembling.
I managed to reproduce this on aarch64-linux in a Leap 15.5 container using
this trigger patch:
...
gdb_disassembler_memory_reader::dis_asm_read_memory
(bfd_vma memaddr, gdb_byte *myaddr, unsigned int len,
struct disassemble_info *info) noexcept
{
+ set_quit_flag ();
return target_read_code (memaddr, myaddr, len);
}
...
and a simple gdb command line calling the disassemble command:
...
$ gdb -q -batch a.out -ex "disassemble main"
...
The following scenario leads to the fatal error:
- the disassemble command is executed,
- set_quit_flag is called in
gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a
user pressed ^C,
- target_read_code calls QUIT, which throws a
gdb_exception_quit,
- the exception propagation mechanism reaches c code in libopcodes and a fatal
error triggers because the c code is not compiled with -fexception.
Fix this by:
- wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in
catch_exceptions (which consequently needs moving to a header file), and
- reraising the caught exception in default_print_insn using QUIT.
Tested on aarch64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025
|
|
Using 'output' to print arrays larger than max-value-size, with only
repeating elements, can cause gdb to crash:
```
$ cat a.c:
char a[1000000];
int main()
{
return a[0];
}
$ gdb -q a
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
Using 'print' works, because value::record_latest sets the unavailable
bytes of the value when it's added to the value history.
But 'outout' doesn't do that, so the printing tries to access more bytes
than are available.
The original problem in PR32015 was about using 'print' of a dynamic
array in a D program.
Here the crash happens because for 'print' the value was a struct with
length/ptr fields, which is converted in d-valprint.c into an array.
So value::record_latest didn't have a chance to mark the unavailable
bytes in this case.
To make sure the unavailable bytes always match the contents, this fixes
it by marking the unavailable bytes immediately after the contents are
allocated.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
For clarity and symmetry with `gdbarch-gen.h`. I wouldn't mind
if all generated files had the `-gen` suffix.
Change-Id: Icb70194fb0e3e2fa9d1c6f0d9331be09b805b428
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Consider the following test-case:
...
$ cat -n test.c
1 int var;
2
3 int
4 foo (void)
5 {
6 var = 1;
7 #include "test.h"
8 }
9
10 int
11 main ()
12 {
13 return foo ();
14 }
$ cat -n test.h
1 return 1;
$ gcc test.c -g
...
When stepping through the test-case, gdb doesn't make it explicit that line 1
is not in test.c:
...
Temporary breakpoint 1, main () at test.c:13
13 return foo ();
(gdb) step
foo () at test.c:6
6 var = 1;
(gdb) n
1 return 1;
(gdb)
8 }
(gdb)
...
which makes it easy to misinterpret the output.
This is with the default "print frame-info" == auto, with documented
behaviour [1]:
...
stepi will switch between source-line and source-and-location depending on the
program counter.
...
What is actually implemented is that source-line is used unless stepping into
or out of a function.
The problem can be worked around by using
"set print frame-info source-and-location", but that's a bit verbose.
Instead, change the behaviour of "print frame-info" == auto to also use
source-and-location when stepping into another file, which gets us:
...
(gdb) n
foo () at test.h:1
1 return 1;
...
Tested on x86_64-linux.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
PR gdb/32011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo
|
|
Now that all known uses of VLAs within GDB are removed, remove the
`-Wno-vla-cxx-extension` (which was used to silence clang warnings) and
add `-Wvla`, such that any use of a VLA will trigger a warning.
Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
