[ This is based on "[gdb/symtab] Add parent_map::dump" [1]. ]
When building the cooked index, gdb builds up a parent map.
This map is currently only visible at user level through the effect of using
it, but it's useful to be able to inspect it as well.
Add dumping of this parent map for "set debug dwarf-read 2".
As example, take test-case gdb.dwarf2/enum-type-c++.exp with target board
debug-types.
The parent map looks like:
...
$ gdb -q -batch \
-iex "maint set worker-threads 0" \
-iex "set debug dwarf-read 2" \
outputs/gdb.dwarf2/enum-type-c++/enum-type-c++
...
[dwarf-read] print_stats: Final m_all_parents_map:
map start:
0x0000000000000000 0x0
0x0000000000000037 0x20f27d30 (0x36: ec)
0x0000000000000051 0x0
0x000000000000008b 0x20f27dc0 (0x8a: A)
0x00000000000000a6 0x0
...
There's no parent entry at address 0xd6, which is part of what causes this:
...
(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
...
With the series containing the proposed fix applied [2], we get instead:
...
[dwarf-read] print_stats: Final m_all_parents_map:
map start:
0x0000000000000000 0x0
0x0000000000000026 0x7e0bdc0 (0x25: ns)
0x0000000000000036 0x0
0x0000000000000037 0x7e0bdf0 (0x36: ns::ec)
0x0000000000000051 0x0
0x000000000000007f 0x7e0be80 (0x7e: ns)
0x000000000000008a 0x0
0x000000000000008b 0x7e0beb0 (0x8a: ns::A)
0x00000000000000a6 0x0
0x00000000000000cc 0x7e0bf10 (0xcb: ns)
0x00000000000000d4 0x7e0bf40 (0xd3: ns::A)
0x00000000000000dc 0x7e0bf10 (0xcb: ns)
0x00000000000000dd 0x7e0bf40 (0xd3: ns::A)
0x00000000000000f6 0x0
...
and find at 0xd6 parent ns::A.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2023-October/202883.html
[2] https://sourceware.org/pipermail/gdb-patches/2024-September/211958.html
With listings enabled, gas keeps a small cache of source lines. They
are stored in buffers of size LISTING_RHS_WIDTH, ie. 100. Given
listing-rhs-width larger than 100 it is of course possible to overflow
the buffer. Fix that by allocating as needed. We could allocate all
buffers on the first call to print_source using listing_rhs_width, but
I chose not to do that in case some future assembly directive allows
changes to listing_rhs_width similarly to the way paper_width can
change during assembly.
Make the current program space references bubble up.
In collect_symtabs_from_filename, remove the calls to
set_current_program_space and just pass the relevant pspaces.
This appears safe to do, because nothing in the `collector` callback
cares about the current pspace.
Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb
Reviewed-by: Keith Seitz <keiths@redhat.com>
Commits 8015b1b0c1 ("x86-64: Never make R_X86_64_GOT64 section
relative"), d774bf9b36 ("x86: Add tls check in gas"), and
1b714c14e4 ("x86: Turn PLT32 to PC32 only for PC-relative
relocations") all should have adjusted the Solaris counterpart of the
reloc64 test as well.
Odd data padding has a $d label inserted at its beginning. When a $x...
label is removed instead, a replacement is inserted after the padding.
The same, however, needs to also happen when there's no $x to replace.
.insn or data emitted inside text sections can lead to positions not
being at insn granularity. In such situations using alignment
directives should reliably enforce the requested alignment.
Specifically requests to align back to insn granularity may not be
ignored (where, as a subcase thereof, the ordering of ".option norvc"
and e.g. ".p2align 2" should not matter; so far the alignment directive
needs to come first to have any effect). Similarly ahead of emitting
NOPs alignment first needs to be forced back to insn granularity.
The new testcases actually point out a corner case issue in the
disassembler as well, which is being corrected at the same time: We
don't want to print "0x" without any subsequent digits.
gprofng/ChangeLog
2024-09-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR 32207
* src/collctrl.cc (preprocess_names): Fix the size in strndup.
The commits:
e8e10743f7 Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments.
bf6d7087de 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>
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 a207f6b3a3 ("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
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>
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.
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
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>
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>
