| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix a mis-placed "fi".
|
|
|
|
I noticed a few spots in symmisc.c that could use a 'const'.
|
|
gprofng/ChangeLog
2024-09-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR 32207
* src/collctrl.cc (preprocess_names): Fix the size in strndup.
|
|
|
|
* ecoff.c (ecoff_link_hash_newfunc): Don't call memset if ret is
NULL.
|
|
The commits:
e8e10743f7b Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments.
bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map
place .note.gnu.build-id before text sections when --rosegment is used.
Ignore .note.gnu.build-id when placing orphaned notes if --rosegment and
-z separate-code are used together to avoid putting any note sections
between .note.gnu.build-id and text sections in the same PT_LOAD segment.
PR ld/32191
* ldlang.c (lang_insert_orphan): Ignore .note.gnu.build-id when
placing orphaned notes.
* testsuite/ld-elf/pr23658-1a.d: Pass --no-rosegment to ld.
* testsuite/ld-elf/pr23658-1c.d: Likewise.
* testsuite/ld-elf/pr23658-1e.d: New file.
* testsuite/ld-elf/pr23658-1f.d: Likewise.
* testsuite/ld-i386/i386.exp: Run PR ld/32191 test.
* testsuite/ld-i386/pr32191.d: New file.
* testsuite/ld-x86-64/lam-u48.rd: Updated.
* testsuite/ld-x86-64/lam-u57.rd: Likewise.
* testsuite/ld-x86-64/pr32191-x32.d: New file.
* testsuite/ld-x86-64/pr32191.d: Likewise.
* testsuite/ld-x86-64/pr32191.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/32191 tests.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Once again to reduce redundancy.
|
|
Yet again to reduce redundancy.
|
|
Once more to reduce redundancy.
|
|
Further reduce redundancy, in preparation of the addition of
counterparts for AVX10.2.
|
|
Reduce redundancy, in preparation of the addition of further counterparts
for AVX10.2. Provide the "ne" parameter needed there right away, even if
unused for now.
|
|
For a long time Fedora GDB has carried an out of tree patch which
checks for memory leaks in gdb.Inferior.read_memory(). At one point
in the distant past GDB did have a memory leak in this code, but this
was first fixed in commit:
commit 655e820cf9a039ee55325d9e1f8423796d592b4b
Date: Wed Mar 28 17:38:07 2012 +0000
* python/py-inferior.c (infpy_read_memory): Remove cleanups and
explicitly free 'buffer' on exit paths. Decref 'membuf_object'
before returning.
And the code has changed a lot since then, but the leak is still
fixed. Unfortunately, this commit didn't have any associated tests.
The original Fedora test wasn't really suitable for upstream, it was
reading /proc/PID/... to figure out if there was a leak or not.
However, we already have gdb.python/py-inferior-leak.exp in upstream
GDB, which makes use of the Python tracemalloc module to check for
memory leaks in a corner of the Python API, so I figured it wouldn't
hurt to rewrite the test in the same style.
And so here is a test for a bug which was closed 12 years ago. This
detects if the gdb.Inferior.read_memory() call leaks any memory.
I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last
line which currently looks like this:
return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ());
and instead doing:
return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ());
The use of "release" here will mean we no longer decrement the
reference count on membuf_obj before returning from the function. As
a consequence the membuf_obj will not be garbage collected. With this
hack in place the new test will fail.
The Python script in the new test is mostly a copy&paste from
py-inferior-leak.py with the core changed to do a memory read instead
of inferior creation. I did consider rewriting both tests into a
single file, maybe, py-memory-leak.py, which would make it easier to
add additional similar tests in the future. For now I've held off
doing that, but if this gets merged then I _might_ revisit this idea.
If folk feel that this new test should only be accepted if I do this
rewrite then let me know and I can get that done.
On copyright date ranges: The .exp and .py scripts are new enough for
this commit that I've dated them 2024. The .c source script is lifted
directly from the old Fedora patch, so I've retained the original 2014
start date for that file only.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Using hard byte code is not a good idea in dump file. Add a label
for intel syntax test check to avoid that.
gas/ChangeLog:
* testsuite/gas/i386/avx10_2-rounding-intel.d: Use label for
test split.
* testsuite/gas/i386/avx10_2-rounding.s: Add label to avoid
hard coding in dump file.
|
|
|
|
Some configurations (eg. i386-bsd, i386-msdos) broke with the addition
of the TLS relocation checking. The "x86_elf_abi undeclared" error
has been fixed, but "gotrel defined but not used" remains. Fix that.
Also invert the preprocessor test around lex_got to make it positive
logic and remove the LEX_AT condition which is no longer necessary.
(The only x86 config files defining LEX_AT also define TE_PE.)
|
|
libtool defaults to filtering flags passed at link-time.
This brings the filtering in GCC's 'fork' of libtool into sync with
upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e.
In particular, this now allows some harmless diagnostic flags (especially
useful for things like -Werror=odr), more optimization flags, and some
Clang-specific options.
GCC's -flto documentation mentions:
> To use the link-time optimizer, -flto and optimization options should be
> specified at compile time and during the final link. It is recommended
> that you compile all the files participating in the same link with the
> same options and also specify those options at link time.
This allows compliance with that.
* ltmain.sh (func_mode_link): Allow various flags through filter.
|
|
With gdb 15.1, python sys.exit no longer makes gdb exit:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
Python Exception <class 'SystemExit'>: 2
Error occurred in Python: 2
$1 = 123
0
...
This is a change in behaviour since commit a207f6b3a38 ("Rewrite "python"
command exception handling"), first available in gdb 15.1.
This patch reverts to the old behaviour by handling PyExc_SystemExit in
gdbpy_handle_exception, such what we have instead:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
2
...
Tested on x86_64-linux, with python 3.6 and 3.13.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31946
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946
|
|
Format with black.
Change-Id: I28e79e9da07ea29391ad1942047633960fa72ed2
|
|
GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel
listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019.
MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6)
and glibc (since v2.35). Let's now remove MPX support in GDB completely.
This includes the removal of:
- MPX functionality including register support
- deprecated mpx commands
- i386 and amd64 implementation of the hooks report_signal_info and
get_siginfo_type
- tests
- and pretty printer.
We keep MPX register numbers to not break compatibility with old gdbservers.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
|
|
Removing the pretty printer (bound_registers.py) in the next commit
leads to failures due to a missing import of 'gdb.printing':
"AttributeError: module 'gdb' has no attribute 'printing'".
Add this import to each file requiring it, as it's not imported by the
pretty-printer anymore.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Previous code included the full $srcdir pathnames in the individual
subtest PASS/FAIL names, which makes it difficult to compute
comparisons or regressions between test runs on different machines.
This version switches to the basename only, which are common.
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
|
|
Previous code included the full $srcdir pathnames in the individual
subtest PASS/FAIL names, which makes it difficult to compute
comparisons or regressions between test runs on different machines.
This version switches to the basename only, which are common.
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
|
|
This patch support Smrnmi extension[1],
The csrs address can be find in[2].
[1] https://github.com/riscv/riscv-isa-manual/commit/35eb3948bf0b87c83fab5a7238bd68b6211faf62
[2] https://github.com/riscv/riscv-isa-manual/blob/smrnmi-1.0/src/priv-csrs.adoc
bfd/ChangeLog:
* elfxx-riscv.c: New extension.
gas/ChangeLog:
* NEWS: Add Smrnmi extension support.
* config/tc-riscv.c (enum riscv_csr_class): New extension class.
(riscv_csr_address): Ditto.
* testsuite/gas/riscv/csr-version-1p10.d: New csrs.
* testsuite/gas/riscv/csr-version-1p10.l: Ditto.
* testsuite/gas/riscv/csr-version-1p11.d: Ditto.
* testsuite/gas/riscv/csr-version-1p11.l: Ditto.
* testsuite/gas/riscv/csr-version-1p12.d: Ditto.
* testsuite/gas/riscv/csr-version-1p12.l: Ditto.
* testsuite/gas/riscv/csr.s: Ditto.
* testsuite/gas/riscv/march-help.l: New extension.
include/ChangeLog:
* opcode/riscv-opc.h (CSR_MNSCRATCH): New csr.
(CSR_MNEPC): Ditto.
(CSR_MNCAUSE): Ditto.
(CSR_MNSTATUS): Ditto.
(DECLARE_CSR): New csr declarations.
|
|
|
|
I noticed that two tests in gdb.ada/complete.exp are testing the same
thing: the completion of "p pck.inne". The second such test has this
comment:
# A fully qualified package name
I believe the intent here was to test "p pck.inner" (note the trailing
"r"). This patch makes this change.
|
|
gdb.server/server-run.exp
One thing GDB always does when the inferior stops is finding out where
it's stopped at, by way of querying the value of the program counter
register.
To save a packet round trip, the remote target can send the PC
value (often alongside other frequently consulted registers such as the
stack pointer) in the stop reply packet as an "expedited register".
Test that this is actually done for the targets where gdbserver is
supposed to.
Extend the "maintenance print remote-registers" command output with an
"Expedited" column which says "yes" if the register was seen by GDB in
the last stop reply packet it received, and is left blank otherwise.
Tested for regressions on aarch64-linux-gnu native-extended-remote.
The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and
x86_64-linux-gnu native-remote and native-extended-remote targets.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Looks like configure has been generated with a non-upstream autoconf,
re-generate it.
ld/ChangeLog:
* configure: Re-generate.
Change-Id: I6774381ad411a190fb93ff260234dd79d8791680
|
|
Remove some includes reported as unused by clangd.
Change-Id: If7c4729975bd90b9cc2c22bcf84d333bd0002a52
|
|
While reviewing "catch (...)" uses I came across:
...
for (auto &item : local)
{
try
{
item ();
}
catch (...)
{
/* Ignore exceptions in the callback. */
}
}
...
This means that when an item throws a gdb_exception_forced_quit,
the exception is ignored and following items are executed.
Fix this by handling gdb_exception_forced_quit explicity, and immediately
rethrowing it.
I wondered about ^C, and couldn't decide whether current behaviour is ok, so
I left this alone, but I made the issue explicit in the source code.
As for the "catch (...)", I think that it should let a non-gdb_exception
propagate, so I've narrowed it to "catch (const gdb_exception &)".
My rationale for this is as follows.
There seem to be a few ways that "catch (...)" is allowed in gdb:
- clean-up and rethrow (basically the SCOPE_EXIT pattern)
- catch and handle an exception from a call into an external c++ library
Since we're dealing with neither of those here, we remove the "catch (...)".
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The is patch adds a new ld build-id computation mode, "xx", using
xxhash in its 128-bit mode. The patch prereqs the xxhash-devel
headers being installed, and uses the "all-inlined" model, so no
run-time or link-time library dependence exists.
The xxhash mode performs well, saving roughly 20% of total userspace
run time from an ld job over a 800MB shared library relative to sha1.
128 bits of good hash should be collision-resistant to a number of
distinct binaries that numbers in the 2**32 - 2**64 range, even if not
"crypto" level hash. Confirmations of this are in progress.
ld/configury: add --with-xxhash mode, different from gdb case
because only using it in inline mode
ld/ldbuildid.c: add "xx" mode, #if WITH_XXHASH
ld/NEWS, ld.texi: mention new option
ld/lexsup.c: add enumeration of --build-id STYLES to --help
ld/testsuite/ld-elf/build-id.exp: add test case for 0xHEX case
and conditional for xx case;
also, simply tcl list syntax
https://inbox.sourceware.org/binutils/20240917201509.GB26396@redhat.com/
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
|
|
While reviewing "catch (...)" uses I came across:
...
try
{
fileio_error remote_errno;
m_remote->remote_hostio_close (m_fd, &remote_errno);
}
catch (...)
{
/* Swallow exception before it escapes the dtor. If
something goes wrong, likely the connection is gone,
and there's nothing else that can be done. */
}
...
This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't
know whether these can actually happen here, but if not it's better to
accommodate for the possibility anyway.
Fix this by handling gdb_exception_quit and gdb_exception_forced_quit
explicitly.
It could be that "catch (...)" should be replaced by
"catch (const gdb_exception &)" but that depends on what kind of exception
remote_hostio_close is expected to throw, and I don't know that, so I'm
leaving it as is.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This is similar to the previous events that we added, and adds support for
SMI, RSM, SIPI, INIT, VMENTRY, VMEXIT, SHUTDOWN, UINTR and UIRET.
Though since these are mainly mechanical and not really possible to test,
they are bundled in one commit.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
This is similar to the previous events that we added.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
Newer Intel CPUs support recording asynchronous events in the PT trace.
Libipt also recently added support for decoding these.
This patch adds support for interrupt events, based on the existing aux
infrastructure. GDB can now display such events during the record
instruction-history and function-call-history commands.
Subsequent patches will add the rest of the events currently supported.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
Event tracing allows GDB to show information about interesting asynchronous
events when tracing with Intel PT. Subsequent patches will add support for
displaying each type of event.
Enabling event-tracing unconditionally would result in rather noisy output, as
breakpoints themselves result in interrupt events. Which is why this patch adds
a set/show command to allow the user to enable/disable event-tracing before
starting a recording. The event-tracing setting has no effect on an already
active recording. The default setting is off. As event tracing will use the
auxiliary infrastructure added by ptwrite, the user can still disable printing
events, even when event-tracing was enabled, by using the /a switch for the
record instruction-history/function-call-history commands.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
So far we printed "disabled" for gaps, when we saw a ptev_enabled event that
doesn't have the resumed flag set. This is wrong, as the actual disabling
happens with ptev_disabled. So far this didn't matter, but once we have event
tracing, there can be events between a ptev_disabled and a ptev_enabled.
This patch is in preparation for that, and removes the disabled reason in
favour of a more accurate non-contiguous reason, and adjusts the string we
print accordingly.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
Remove duplicate code in pipe_command using SCOPE_EXIT.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Remove duplicate code in target_wait using SCOPE_EXIT.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Remove duplicate code in execute_fn_to_string using SCOPE_EXIT.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While reviewing "catch (...)" uses I came across:
...
scope_exit (EFP &&f)
try : m_exit_function ((!std::is_lvalue_reference<EFP>::value
&& std::is_nothrow_constructible<EF, EFP>::value)
? std::move (f)
: f)
{
}
catch (...)
{
/* "If the initialization of exit_function throws an exception,
calls f()." */
f ();
}
...
and while looking up the origin of the comment here [1] I saw right after:
...
throws: Nothing, unless the initialization of exit_function throws
...
I think that means that the exception should be rethrown, so fix this by doing
so.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r5.pdf
|
|
In gnu_source_highlight_test we have:
...
try
{
res = try_source_highlight (styled_prog, language_c, fullname);
}
catch (...)
{
saw_exception = true;
}
...
This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't
know whether these can actually happen here, but if not it's better to
accommodate for the possibility anyway.
Fix this by handling gdb_exception explicitly, and rethrowing
gdb_exception_quit and gdb_exception_forced_quit.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With the same trigger patch adding "set horizontal-scroll-mode on" to INPUTRC
as used in commit 250f1bbaf33 ("[gdb/testsuite] Fix gdb.tui/wrap-line.exp with
wrapping disabled"), we can easily reproduce a failure in
gdb.tui/wrap-line.exp mentioned in PR testsuite/31201:
...
(gdb) 78901234567890123456789012345678901234567890123456789012345678901234567^M<890123456789012345678901234567890123456789012345678 ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H9WFAIL: gdb.base/wrap-line.exp: term=ansi: width-hard-coded: wrap (timeout)
...
The test-case expects wrapping, but that's disabled by horizontal-scroll-mode.
Add a new line to "maint info screen", that describes the current readline
wrapping mode, and use it in the test-case to handle the different cases.
The reported values for the wrapping mode are as follows.
Unsupported because of running in batch mode:
...
$ gdb -q -batch -ex "maint info screen"
Readline wrapping mode: unsupported (gdb batch mode).
...
Unsupported because the terminal is not capable to move the cursor up:
...
$ TERM=dumb gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: unsupported (terminal is not Cursor Up capable).
...
Disabled by horizontal-scroll-mode:
...
$ grep horizontal-scroll-mode ~/.inputrc
set horizontal-scroll-mode on
$ gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: disabled (horizontal-scroll-mode).
...
Wrap done by readline because terminal is not auto wrap capable:
...
$ TERM=ansi gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: readline (terminal is not auto wrap capable, last column reserved).
...
Wrap done by terminal autowrap:
...
$ TERM=xterm gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: terminal (terminal is auto wrap capable).
...
Tested on x86_64-linux.
Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
|
|
In valpy_assign_core we have:
...
catch (const gdb_exception &except)
{
gdbpy_convert_exception (except);
return false;
}
...
Use instead:
...
catch (const gdb_exception &except)
{
return gdbpy_handle_gdb_exception (false, except);
}
...
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Result of:
...
$ search="GDB_PY_SET_HANDLE_EXCEPTION ("
$ replace="return gdbpy_handle_gdb_exception (-1, "
$ sed -i \
"s/$search/$replace/" \
gdb/python/*.c
...
Also remove the now unused GDB_PY_SET_HANDLE_EXCEPTION.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Result of:
...
$ search="GDB_PY_HANDLE_EXCEPTION ("
$ replace="return gdbpy_handle_gdb_exception (nullptr, "
$ sed -i \
"s/$search/$replace/" \
gdb/python/*.c
...
Also remove the now unused GDB_PY_HANDLE_EXCEPTION.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I've recently committed two patches:
- commit 2f8cd40c37a ("[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often")
- commit fbf8e4c35c2 ("[gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often")
which use the macros GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
more often, with the goal of making things more consistent.
Having done that, I wondered if a better approach could be possible.
Consider GDB_PY_HANDLE_EXCEPTION:
...
/* Use this in a 'catch' block to convert the exception to a Python
exception and return nullptr. */
#define GDB_PY_HANDLE_EXCEPTION(Exception) \
do { \
gdbpy_convert_exception (Exception); \
return nullptr; \
} while (0)
...
The macro nicely codifies how python handles exceptions:
- setting an error condition using some PyErr_Set* variant, and
- returning a value implying that something went wrong
presumably with the goal that using the macro will mean not accidentally:
- forgetting to return on error, or
- returning the wrong value on error.
The problems are that:
- the macro hides control flow, specifically the return statement, and
- the macro hides the return value.
For example, when reading somewhere:
...
catch (const gdb_exception &except)
{
GDB_PY_HANDLE_EXCEPTION (except);
}
...
in order to understand what this does, you have to know that the macro
returns, and that it returns nullptr.
Add a template gdbpy_handle_gdb_exception:
...
template<typename T>
[[nodiscard]] T
gdbpy_handle_gdb_exception (T val, const gdb_exception &e)
{
gdbpy_convert_exception (e);
return val;
}
...
which can be used instead:
...
catch (const gdb_exception &except)
{
return gdbpy_handle_gdb_exception (nullptr, except);
}
...
[ Initially I tried this:
...
template<auto val>
[[nodiscard]] auto
gdbpy_handle_gdb_exception (const gdb_exception &e)
{
gdbpy_convert_exception (e);
return val;
}
...
with which the usage is slightly better looking:
...
catch (const gdb_exception &except)
{
return gdbpy_handle_gdb_exception<nullptr> (except);
}
...
but I ran into trouble with older gcc compilers. ]
While still a single statement, we now have it clear:
- that the statement returns,
- what value the statement returns.
[ FWIW, this could also be handled by say:
...
- GDB_PY_HANDLE_EXCEPTION (except);
+ GDB_PY_HANDLE_EXCEPTION_AND_RETURN_VAL (except, nullptr);
...
but I still didn't find the fact that it returns easy to spot.
Alternatively, this is the simplest form we could use:
...
return gdbpy_convert_exception (e), nullptr;
...
but the pairing would not necessarily survive a copy/paste/edit cycle. ]
Also note how making the value explicit makes it easier to check for
consistency:
...
catch (const gdb_exception &except)
{
return gdbpy_handle_gdb_exception (-1, except);
}
if (PyErr_Occurred ())
return -1;
...
given that we do use the explicit constants almost everywhere else.
Compared to using GDB_PY_HANDLE_EXCEPTION, there is the burden now to specify
the return value, but I assume that this will be generally copy-pasted and
therefore present no problem.
Also, there's no longer a guarantee that there's an immediate return, but I
assume that nodiscard making sure that the return value is not silently
ignored is sufficient mitigation.
For now, re-implement GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
in terms of gdbpy_handle_gdb_exception.
Follow-up patches will eliminate the macros.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While looking at PR symtab/31478 (a problem in the cooked indexer with invalid
dwarf) it occurred to me that I could trigger a similar problem using:
...
Compilation Unit @ offset 0xb2:
Length: 0x1f (32-bit)
Version: 4
Abbrev Offset: 0x6c
Pointer Size: 8
<0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
<be> DW_AT_language : 2 (non-ANSI C)
<1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
<c0> DW_AT_low_pc : 0x4004a7
<c8> DW_AT_high_pc : 0x4004b2
<d0> DW_AT_specification: <0xd5>
<1><d4>: Abbrev Number: 0
Compilation Unit @ offset 0xd5:
Length: 0x7 (32-bit)
Version: 4
Abbrev Offset: 0x7f
Pointer Size: 8
...
and indeed I get:
...
$ gdb -q -batch outputs/gdb.dwarf2/dw2-inter-cu-error-2/dw2-inter-cu-error-2
Fatal signal: Segmentation fault
...
The problem is that we're calling prepare_one_comp_unit with cu == nullptr and
comp_unit_die == nullptr here in cooked_indexer::ensure_cu_exists:
...
cutu_reader new_reader (per_cu, per_objfile, nullptr, nullptr, false,
m_index_storage->get_abbrev_cache ());
prepare_one_comp_unit (new_reader.cu, new_reader.comp_unit_die,
language_minimal);
...
Fix this by bailing out for various types of dummy CUs:
...
if (new_reader.dummy_p || new_reader.comp_unit_die == nullptr
|| !new_reader.comp_unit_die->has_children)
return nullptr;
...
Also make sure in scan_attributes that this triggers a dwarf error:
...
$ gdb -q -batch dw2-inter-cu-error-2
DWARF Error: cannot follow reference to DIE at 0xd5 \
[in module dw2-inter-cu-error-2]
...
With target board readnow, the test-case triggers an assertion failure in
follow_die_offset, so fix this by throwing the same dwarf error.
While we're at it, make the other check for dummy CUs in
cooked_indexer::ensure_cu_exists more robust by adding an intermediate test
for comp_unit_die:
...
- if (result->dummy_p || !result->comp_unit_die->has_children)
+ if (result->dummy_p || result->comp_unit_die == nullptr
+ || !result->comp_unit_die->has_children)
return nullptr;
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When issuing a command "maint expand-symtabs", maintenance_expand_symtabs is
called with regexp == nullptr, and calls expand_symtabs_matching like so:
...
objfile->expand_symtabs_matching
([&] (const char *filename, bool basenames)
{
/* KISS: Only apply the regexp to the complete file name. */
return (!basenames
&& (regexp == NULL || re_exec (filename)));
},
...
To expand all symtabs gdb usually uses expand_all_symtabs (used for -readnow),
but here we try to handle it in the filename_matcher argument.
Make this more similar to how gdb usually works by using expand_all_symtabs.
A previous version of the patch instead used a nullptr filename_matcher for
the regexp == nullptr case. That approach regressed test-cases
gdb.dwarf2/dwz-unused-pu.exp and gdb.dwarf2/dw2-dummy.exp.
Tested on x86_64-linux.
|
