On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
...
Fix this by using with_test_prefix.
Tested on s390x-linux.
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-disassembler-options.exp: \
show disassembler-options esa
...
First, reproduce this on x86_64-linux with --enable-targets=all, by replacing
the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices
"set architecture" "s390"'.
Fix the DUPLICATE by using with_test_prefix.
Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start.
Tested on x86_64-linux.
this testcase wasn't correctly testing everything, it passed, even
though sections from an excluded file were included. Fixing this
reveals a problem in the new section selector. This fixes that as
well.
walk_wild_file, hence walk_wild_section and walk_wild_section_handler
aren't called with the prefix tree. Hence initialization of the latter
and all potential special cases for it aren't used anymore. That also
removes the need to handler_data[] and some associated helper functions.
So, remove all of that.
Now that we have a list of potentially matching sections per wild
statement we can actually pre-fill that one by going once over all input
sections and match their names against a prefix-tree that points to the
potentially matching wild statements.
So instead of looking at all sections names for each glob for each wild
statement we now look at the sections only once and then only check
against those globs that have a possibility of a match at all (usually
only one or two).
This pushes the whole section selection off the profiles.
The check_relocs callback (and others) might have created new
section behind our back and some of them (e.g. on powerpc the
"linker stubs" .got) need to come in front of all others, despite
being created late (a symptom would be "TOC opt*" failing on powerpc).
This resets all section matches before updating for newly created
sections (i.e. completely rebuilds the matches).
and remember the results. Before this the order of section matching
is basically:
foreach script-wild-stmt S
foreach pattern P of S
foreach inputfile I
foreach section S of I
match S against P
if match: do action for S
And this process is done three or four times: for each top-level call to
walk_wild() or wild(), that is: check_input_sections, lang_gc_sections,
lang_find_relro_sections and of course map_input_to_output_sections.
So we iterate over all sections of all files many many times (for each
glob). Reality is a bit more complicated (some special glob types don't
need the full iteration over all sections, only over all files), but
that's the gist of it.
For future work this shuffles the whole ordering a bit by lazily doing
the matching process and memoizing results, trading a little memory for
a 75% speedup of the overall section selection process.
This lazy resolution introduces a problem with sections added late
that's corrected in the next patch.
While looking into Ada tasking a little, I noticed that no bounds
checking is done on accesses to the Ada task state names arrays. This
isn't a problem currently, but if the runtime ever added numbers -- or
if there was some kind of runtime corruption -- it could cause a gdb
crash.
This patch adds range checking. It also adds a missing _() call when
printing from the 'task_states' array.
This renames the fields of cli_interp_base::saved_output_files, as
requested by Simon. I tried to choose names that more obviously
reflect what the field is used for. I also added a couple of
comments.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Currently, on x86_64, a little endian target, I get:
...
$ gdb -q -batch -ex "maint print architecture" | grep " = floatformat"
gdbarch_dump: bfloat16_format = floatformat_bfloat16_big
gdbarch_dump: double_format = floatformat_ieee_double_big
gdbarch_dump: float_format = floatformat_ieee_single_big
gdbarch_dump: half_format = floatformat_ieee_half_big
gdbarch_dump: long_double_format = floatformat_i387_ext
...
which suggests big endian.
This is due to this bit of code in pformat:
...
/* Just print out one of them - this is only for diagnostics. */
return format[0]->name;
...
Fix this by using gdbarch_byte_order to pick the appropriate index, such that
we have the more accurate:
...
gdbarch_dump: bfloat16_format = floatformat_bfloat16_little
gdbarch_dump: half_format = floatformat_ieee_half_little
gdbarch_dump: float_format = floatformat_ieee_single_little
gdbarch_dump: double_format = floatformat_ieee_double_little
gdbarch_dump: long_double_format = floatformat_i387_ext
...
Tested on x86_64-linux.
In "x86/Intel: restrict suffix derivation" I think I screwed up
slightly, bringing a piece of code out of sync with its comment, and
resulting in a suffix potentially being derived when one isn't needed.
At the very least a comment in process_operands() is stale. Beyond that
there are effectively two options:
1) It is possible that FADDP and FMULP were mistakenly not marked as
being in need of dealing with the compiler anomaly, and hence the
respective templates weren't removed at the time when they should
have been.
2) It is also possible that there are indeed uses known beyond compiler
generated output for these two commutative opcodes, and hence the
templates need to stay.
To be on the safe side assume 2: Update the comment and fold the
templates into their "normal" ones (utilizing D), adjusting consuming
code accordingly.
For FMULP also add a comment paralleling a similar one FADDP has.
There are just 4 templates using it, which can be easily identified by
other means, as D is set only on a very limited number of FPU templates.
Also move the respective conditional out of the code path taken by all
"reverse match" insns (it probably should have been this way already
before, to avoid the one conditional in the common case).
With this the templates which had FloatR dropped no longer differ from
their AT&T syntax + mnemonic counterparts - the only difference is now
which of the two would be recognized. For this, however, we don't need
two templates - we can simply arrange the condition for setting
Opcode_FloatR accordingly.
Before touching the templates, let's ensure we actually cover things:
For one FSUB{,R} and FDIV{,R} would better be tested with operands in
both possible orders. And then -mmnemonic=intel wasn't tested at all.
This script was recently changed as follow:
| commit e619dddb3a
| Date: Tue Nov 15 15:07:13 2022 -0800
| Subject: src-release.sh: Add libsframe
|
| Add libsframe to the list of top level directories that will be included
| in a release.
Since then, the gdb source tarball has been failing with the error
below during the "make configure-host configure-target" phase:
| make[3]: *** No rule to make target '../libsframe/libsframe.la',
| needed by 'libbfd.la'. Stop.
| make[3]: Leaving directory '/tmp/gdb-public/bfd'
This patch fixes the issue by adding libsframe to the list of
GDB_SUPPORT_DIRS, similar to what was done for BINUTILS.
ChangeLog:
* src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed optimized out vla
p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: \
printed size of optimized out vla
...
The problem happens as follows.
In order to find the size of the optimized out vla, gdb needs to evaluate:
...
<155> DW_AT_upper_bound : 13 byte block: f3 1 53 23 1 8 20 24 8 20 26 31 1c \
(DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1;
DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1;
DW_OP_minus)
...
When trying to evaluate DW_OP_GNU_entry_value, it looks for a call site
matching the pc, but doesn't find it:
...
$ gdb -q -batch outputs/gdb.base/vla-optimized-out/vla-optimized-out-o1 \
-ex "break f1" -ex run -ex "set debug entry-values 1" -ex "print sizeof (a)"
Breakpoint 1 at 0x1000067c: file vla-optimized-out.c, line 34.
Breakpoint 1, f1 (i=5) at vla-optimized-out.c:34
34 }
DW_OP_entry_value resolving cannot find DW_TAG_call_site 0x100006b0 in main
$1 = <optimized out>
....
The call site lookup fails because the call site label .LVL4:
...
bl f1 # 11 *call_value_nonlocal_aixdi [length = 8]
nop
.LVL4:
...
is not placed directly after the bl insn. This is gcc PR target/107909.
However, after manually fixing the .s file we have instead:
...
Cannot find matching parameter at DW_TAG_call_site 0x10000690 at main
$1 = <optimized out>
...
due to the fact that the call site has no call site parameters.
The call site does have a reference to the corresponding function f1, with
parameter i, for which we find location list entries:
...
0037 1000067c 10000680 (DW_OP_reg3 (r3))
004a 10000680 10000690 (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3));
DW_OP_stack_value)
...
and we could use the fact that the current pc is in the 1000067c-10000680
range, and that that the range starts at the start of the function, to deduce
that DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)) == DW_OP_reg3 (r3).
But that's a non-trivial enhancement, filed as enhancement PR symtab/29836.
Fix this by allowing <optimized out> for target powerpc and the gcc compiler.
Reviewed-By: Carl Love <cel@us.ibm.com>
Tested-By: Carl Love <cel@us.ibm.com>
PR testsuite/29813
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29813
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
gdb_unload crashed GDB, leaving no trace in the test results. Change it
to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I
think it is good practice anyway.
Make it return the result of gdb_test_multiple directly, change
gdb.python/py-objfile.exp accordingly.
Change gdb.base/endian.exp as well to avoid duplicate test names.
Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
since gdb_unload does it already now.
Change-Id: I59a1e4947691330797e6ce23277942547c437a48
Approved-By: Tom de Vries <tdevries@suse.de>
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
... the testsuite only outputs PASSes, and an ERROR, resulting from an
uncaught exception. This is a bit sneaky, because ERRORs are not
reported in the test summary. In certain circumstances, it can be easy
to miss.
Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes. But
this is only if it manages to send the command, and it's that command
that crashes GDB. Here, the ERROR is due to the fact that GDB had
already crashed by the time we entered gdb_test_multiple and tried to
send a command. GDB was crashed by the previous "file" command, sent by
gdb_unload. Because gdb_unload uses bare expect, it didn't record a
test failure when crashing GDB (this will be addressed separately).
In this patch, I propose to make gdb_test_multiple call unresolved
directly and return -1 send_gdb fails. This way, if GDB is already
crashed by the time we enter gdb_test_multiple, it will leave a trace in
the test results in the form of an UNRESOLVED. It will also spare us
the not-so-useful-in-my-opinion TCL backtrace.
Before, it looks like:
ERROR: Couldn't send python print(objfile.filename) to GDB.
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
And after:
Couldn't send python print(objfile.filename) to GDB.
UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded
Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba
Approved-By: Tom de Vries <tdevries@suse.de>
Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields
of a structure returned from the xtensa_get_config_v<x> function call.
Define that structure and fill it with default parameter values
specified in the include/xtensa-config.h.
Define reusable function xtensa_load_config that tries to load
configuration and return an address of an exported object from it.
Define functions xtensa_get_config_v{1,2} that use xtensa_load_config
to get structures xtensa_config_v{1,2}, either dynamically configured
or the default.
bfd/
* Makefile.am (BFD32_BACKENDS, BFD32_BACKENDS_CFILES): Append
xtensa-dynconfig.c.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac (xtensa_elf32_be_vec, xtensa_elf32_le_vec): Add
xtensa-dynconfig.lo to the tb.
* elf32-xtensa.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XSHAL_ABI, XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove
definitions.
* xtensa-dynconfig.c: New file.
* xtensa-isa.c (xtensa-dynconfig.h): New #include.
(xtensa_get_modules): New function.
(xtensa_isa_init): Call xtensa_get_modules instead of taking
address of global xtensa_modules.
gas/
* config/tc-xtensa.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0, XTENSA_MARCH_EARLIEST):
Remove definitions.
* config/tc-xtensa.h (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
* config/xtensa-relax.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XCHAL_HAVE_WIDE_BRANCHES): Remove definition.
include/
* xtensa-dynconfig.h: New file.
ld/
* emultempl/xtensaelf.em (xtensa-config.h): Replace #include
with xtensa-dynconfig.h.
(XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove definitions.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the testsuite
library files (in boards/, config/, and lib/). Previous commits have
removed all uses of the 'then' keyword from the test script files,
this commit just cleans up the library files.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the remaining
gdb.*/*.exp scripts. Previous commits have done the bulk of this
removal, this commit just handles the remaining directories that each
contain a low number of instances.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.multi/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.fortran/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.disasm/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.reverse/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.trace/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.threads/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.python/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.cp/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.arch/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.base/
test script directory.
There should be no changes in what is tested after this commit.
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.ada/
test script directory.
There should be no changes in what is tested after this commit.
The gdb.fortran/nested-funcs.exp test script has DOS line endings. I
can see no reason why this script needs DOS line endings.
Convert to UNIX line endings.
There should be no change in what is tested after this commit.
When using the "set logging" commands, cli_interp_base::set_logging
will send gdb_stdlog output (among others) to the tee it makes for
gdb_stdout. However, this has the side effect of also causing logging
to use the pager. This is PR gdb/29787.
This patch fixes the problem by keeping stderr and stdlog separate
from stdout, preserving the rule that only gdb_stdout should page.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29787
Right now, tee_file owns the second stream it writes to. This is done
for the convenience of the users. In a subsequent patch, this will no
longer be convenient, so this patch moves the responsibility for
ownership to the users of tee_file.
CLI redirect uses a global variable, 'saved_output'. However, globals
are generally bad, and there is no need for this one -- it can be a
member of cli_interp_base. This patch makes this change.
Older gcc versions (here 4.9.2) can't handle auto for a lambda parameter:
../../gdb/windows-nat.c: In member function 'void windows_nat_target::delete_thread(ptid_t, DWORD, bool)':
../../gdb/windows-nat.c:629:12: error: use of 'auto' in lambda parameter declaration only available with -std=c++1y or -std=gnu++1y [-Werror]
[=] (auto &th)
^
For i686 the CreateThread entry point function needs the WINAPI (stdcall)
calling convention:
../../gdb/windows-nat.c: In constructor 'windows_nat_target::windows_nat_target()':
../../gdb/windows-nat.c:450:56: error: invalid user-defined conversion from 'windows_nat_target::windows_nat_target()::<lambda(LPVOID)>' to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'} [-fpermissive]
450 | HANDLE bg_thread = CreateThread (nullptr, 64 * 1024, fn, this, 0, nullptr);
| ^~
../../gdb/windows-nat.c:444:13: note: candidate is: 'constexpr windows_nat_target::windows_nat_target()::<lambda(LPVOID)>::operator DWORD (*)(LPVOID)() const' (near match)
444 | auto fn = [] (LPVOID self) -> DWORD
| ^
../../gdb/windows-nat.c:444:13: note: no known conversion from 'DWORD (*)(LPVOID)' {aka 'long unsigned int (*)(void*)'} to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'}
Since it's not possible to change the calling convention of a lambda, I've
moved it to a separate function.
In disasm.h we define a set of types that are used by the various
disassembler classes to hold callback functions before passing the
callbacks into libopcodes.
Because libopcodes is C code, and on some (many?) targets, C code is
compiled without exception support, it is important that GDB not try
to throw an exception over libopcode code.
In the previous commit all the existing callbacks were marked as
noexcept, however, this doesn't protect us from a future change to GDB
either adding a new callback that is not noexcept, or removing the
noexcept keyword from an existing callback.
In this commit I mark all the callback types as noexcept. This means
that GDB's disassembler classes will no longer compile if we try to
pass a callback that is not marked as noexcept.
At least, that's the idea. Unfortunately, it's not that easy.
Before C++17, the noexcept keyword on a function typedef would be
ignored, thus:
using func_type = void (*) (void) noexcept;
void
a_func ()
{
throw 123;
}
void
some_func (func_type f)
{
f ();
}
int
main ()
{
some_func (a_func);
return 0;
}
Will compile just fine for C++11 and C++14 with GCC. Clang on the
other hand complains that 'noexcept' should not appear on function
types, but then does appear to correctly complain that passing a_func
is a mismatch in the set of exceptions that could be thrown.
Switching to C++17 and both GCC and Clang correctly point out that
passing a_func is an invalid conversion relating to the noexcept
keyword. Changing a_func to:
void
a_func () noexcept
{ /* Nothing. */ }
And for C++17 both GCC and Clang compile this just fine.
My conclusion then is that adding the noexcept keyword to the function
types is pointless while GDB is not compiled as C++17, and silencing
the warnings would require us to jump through a bunch of hoops.
And so, in this commit, I define a macro LIBOPCODE_CALLBACK_NOEXCEPT,
this macro expands to noexcept when compiling for C++17, but otherwise
expands to nothing. I then add this macro to the function types.
I've compiled GDB as the default C++11 and also forced the compile to
C++17. When compiling as C++17 I spotted a few additional places
where callbacks needed to be marked noexcept (these fixes were merged
into the previous commit, but this confirmed to be that the macro is
working as expected).
While working on another patch, Simon pointed out that GDB could be
improved by marking the functions passed to the disassembler as
noexcept.
https://sourceware.org/pipermail/gdb-patches/2022-October/193084.html
The reason this is important is the on some hosts, libopcodes, being C
code, will not be compiled with support for handling exceptions. As
such, an attempt to throw an exception over libopcodes code will cause
GDB to terminate.
See bug gdb/29712 for an example of when this happened.
In this commit all the functions that are passed to the disassembler,
and which might be used as callbacks by libopcodes are marked
noexcept.
Ideally, I would have liked to change these typedefs:
using read_memory_ftype = decltype (disassemble_info::read_memory_func);
using memory_error_ftype = decltype (disassemble_info::memory_error_func);
using print_address_ftype = decltype (disassemble_info::print_address_func);
using fprintf_ftype = decltype (disassemble_info::fprintf_func);
using fprintf_styled_ftype = decltype (disassemble_info::fprintf_styled_func);
which are declared in disasm.h, as including the noexcept keyword.
However, when I tried this, I ran into this warning/error:
In file included from ../../src/gdb/disasm.c:25:
../../src/gdb/disasm.h: In constructor ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’:
../../src/gdb/disasm.h:116:3: error: mangled name for ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type]
116 | gdb_printing_disassembler (struct gdbarch *gdbarch,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
So I've left that change out. This does mean that if somebody adds a
new use of the disassembler classes in the future, and forgets to mark
the callbacks as noexcept, this will compile fine. We'll just have to
manually check for that during review.
Bug gdb/29712 identifies a problem with the Python disassembler API.
In some cases GDB will try to throw an exception through the
libopcodes disassembler code, however, not all targets include
exception unwind information when compiling C code, for targets that
don't include this information GDB will terminate when trying to pass
the exception through libopcodes.
To explain what GDB is trying to do, consider the following trivial
use of the Python disassembler API:
class ExampleDisassembler(gdb.disassembler.Disassembler):
class MyInfo(gdb.disassembler.DisassembleInfo):
def __init__(self, info):
super().__init__(info)
def read_memory(self, length, offset):
return super().read_memory(length, offset)
def __init__(self):
super().__init__("ExampleDisassembler")
def __call__(self, info):
info = self.MyInfo(info)
return gdb.disassembler.builtin_disassemble(info)
This disassembler doesn't add any value, it defers back to GDB to do
all the actual work, but it serves to allow us to discuss the problem.
The problem occurs when a Python exception is raised by the
MyInfo.read_memory method. The MyInfo.read_memory method is called
from the C++ function gdbpy_disassembler::read_memory_func. The C++
stack at the point this function is called looks like this:
#0 gdbpy_disassembler::read_memory_func (memaddr=4198805, buff=0x7fff9ab9d2a8 "\220ӹ\232\377\177", len=1, info=0x7fff9ab9d558) at ../../src/gdb/python/py-disasm.c:510
#1 0x000000000104ba06 in fetch_data (info=0x7fff9ab9d558, addr=0x7fff9ab9d2a9 "ӹ\232\377\177") at ../../src/opcodes/i386-dis.c:305
#2 0x000000000104badb in ckprefix (ins=0x7fff9ab9d100) at ../../src/opcodes/i386-dis.c:8571
#3 0x000000000104e28e in print_insn (pc=4198805, info=0x7fff9ab9d558, intel_syntax=-1) at ../../src/opcodes/i386-dis.c:9548
#4 0x000000000104f4d4 in print_insn_i386 (pc=4198805, info=0x7fff9ab9d558) at ../../src/opcodes/i386-dis.c:9949
#5 0x00000000004fa7ea in default_print_insn (memaddr=4198805, info=0x7fff9ab9d558) at ../../src/gdb/arch-utils.c:1033
#6 0x000000000094fe5e in i386_print_insn (pc=4198805, info=0x7fff9ab9d558) at ../../src/gdb/i386-tdep.c:4072
#7 0x0000000000503d49 in gdbarch_print_insn (gdbarch=0x5335560, vma=4198805, info=0x7fff9ab9d558) at ../../src/gdb/gdbarch.c:3351
#8 0x0000000000bcc8c6 in disasmpy_builtin_disassemble (self=0x7f2ab07f54d0, args=0x7f2ab0789790, kw=0x0) at ../../src/gdb/python/py-disasm.c:324
### ... snip lots of frames as we pass through Python itself ...
#22 0x0000000000bcd860 in gdbpy_print_insn (gdbarch=0x5335560, memaddr=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/python/py-disasm.c:783
#23 0x00000000008995a5 in ext_lang_print_insn (gdbarch=0x5335560, address=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/extension.c:939
#24 0x0000000000741aaa in gdb_print_insn_1 (gdbarch=0x5335560, vma=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/disasm.c:1078
#25 0x0000000000741bab in gdb_disassembler::print_insn (this=0x7fff9ab9e3c0, memaddr=0x401195, branch_delay_insns=0x0) at ../../src/gdb/disasm.c:1101
So gdbpy_disassembler::read_memory_func is called from the libopcodes
disassembler to read memory, this C++ function then calls into user
supplied Python code to do the work.
If the user supplied Python code raises an gdb.MemoryError exception
indicating the memory read failed, this is fine. The C++ code
converts this exception back into a return value that libopcodes can
understand, and returns to libopcodes.
However, if the user supplied Python code raises some other exception,
what we want is for this exception to propagate through GDB and appear
as if raised by the call to gdb.disassembler.builtin_disassemble. To
achieve this, when gdbpy_disassembler::read_memory_func spots an
unknown Python exception, we must pass the information about this
exception from frame #0 to frame #8 in the above backtrace. Frame #8
is the C++ implementation of gdb.disassembler.builtin_disassemble, and
so it is this function that we want to re-raise the unknown Python
exception, so the user can, if they want, catch the exception in their
code.
The previous mechanism by which the exception was passed was to pack
the details of the Python exception into a C++ exception, then throw
the exception from frame #0, and catch the exception in frame #8,
unpack the details of the Python exception, and re-raise it.
However, this relies on the exception passing through frames #1 to #7,
some of which are in libopcodes, which is C code, and so, might not be
compiled with exception support.
This commit proposes an alternative solution that does not rely on
throwing a C++ exception.
When we spot an unhandled Python exception in frame #0, we will store
the details of this exception within the gdbpy_disassembler object
currently in use. Then we return to libopcodes a value indicating
that the memory_read failed.
libopcodes will now continue to disassemble as though that memory read
failed (with one special case described below), then, when we
eventually return to disasmpy_builtin_disassemble we check to see if
there is an exception stored in the gdbpy_disassembler object. If
there is then this exception can immediately be installed, and then we
return back to Python, when the user will be able to catch the
exception.
There is one extra change in gdbpy_disassembler::read_memory_func.
After the first call that results in an exception being stored on the
gdbpy_disassembler object, any future calls to the ::read_memory_func
function will immediately return as if the read failed. This avoids
any additional calls into user supplied Python code.
My thinking here is that should the first call fail with some unknown
error, GDB should not keep trying with any additional calls. This
maintains the illusion that the exception raised from
MyInfo.read_memory is immediately raised by
gdb.disassembler.builtin_disassemble. I have no tests for this change
though - to trigger this issue would rely on a libopcodes disassembler
that will try to read further memory even after the first failed
read. I'm not aware of any such disassembler that currently does
this, but that doesn't mean such a disassembler couldn't exist in the
future.
With this change in place the gdb.python/py-disasm.exp test should now
pass on AArch64.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29712
Approved-By: Simon Marchi <simon.marchi@efficios.com>
