Add --got-contents option to readelf, inspired by the -G option on Solaris,
to display contents of GOT sections:
$ readelf --got-contents libfoo.so
Global Offset Table '.got' contains 1 entry:
Index: Address Reloc Sym. Name + Addend/Value
0: 000000200340 R_X86_64_GLOB_DAT foo + 0
Global Offset Table '.got.plt' contains 4 entries:
Index: Address Reloc Sym. Name + Addend/Value
0: 000000200348 200220
1: 000000200350 0
2: 000000200358 0
3: 000000200360 R_X86_64_JUMP_SLO bar + 0
When --got-content options are used:
1. Allocate an array, all_relocations, to hold all relocations.
2. Update dump_relr_relocations and dump_relocations to scan relocations
and cache them in all_relocations. Don't display relocations if not
requested.
3. Add process_got_section_contents to display contents of GOT sections
by matching the GOT entry offset against the cached relocations.
4. Update process_mips_specific to only display the GOT related contents
for --got-contents.
binutils/
* NEWS: Mention "readelf --got-contents".
* readelf.c (do_got_section_contents): New.
(elf_relocation): Likewise.
(all_relocations_root): Likewise.
(all_relocations): Likewise.
(all_relocations_count): Likewise.
(update_all_relocations): Likewise.
(dump_relr_relocations): Add a bool argument to indicate if
relocations should be displayed. Populate all_relocations if
do_got_section_contents is true.
(dump_relocations): Likewise.
(long_option_values): Add OPTION_GOT_CONTENTS.
(options): Add --got-contents.
(usage): Show --got-contents.
(parse_args): Support --got-contents.
(display_relocations): Add a bool argument, dump_reloc, to
indicate if relocations should be displayed. Call
update_all_relocations. Pass dump_reloc to dump_relr_relocations
and dump_relocations.
(process_relocs): Check do_got_section_contents. Handle
do_got_section_contents for dynamic relocations.
(process_section_contents): Pass true to display_relocations.
(process_mips_specific): Add a bool argument, dump_got, to
indicate if only the GOT related contents should be displayed.
Display all MIPS specific information if dump_got is false.
(elf_relocation_cmp): New.
(display_elf_relocation_at): Likewise.
(process_got_section_contents): Likewise.
(process_object): Call process_got_section_contents.
* doc/binutils.texi: Document --got-contents.
ld/
* testsuite/ld-i386/binutils.exp: New file.
* testsuite/ld-i386/got-1.s: Likewise.
* testsuite/ld-i386/libgot-1a.rd: Likewise.
* testsuite/ld-i386/libgot-1b.rd: Likewise.
* testsuite/ld-i386/libgot-1c.rd: Likewise.
* testsuite/ld-i386/libgot-1d.rd: Likewise.
* testsuite/ld-x86-64/binutils.exp: Likewise.
* testsuite/ld-x86-64/got-1.s: Likewise.
* testsuite/ld-x86-64/libgot-1a-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1a.rd: Likewise.
* testsuite/ld-x86-64/libgot-1b-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1b.rd: Likewise.
* testsuite/ld-x86-64/libgot-1c-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1c.rd: Likewise.
* testsuite/ld-x86-64/libgot-1d-x32.rd: Likewise.
* testsuite/ld-x86-64/libgot-1d.rd: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
The opcode D6 has been officially reserved as a single-byte permanent
undefined (#UD) opcode in 64-bit mode with the mnemonic UDB. This is
already the behavior of all known 64-bit implementations; this is thus
merely an official statement of forward compatibility and the
assignment of a mnemonic.
This will be documented in the next version of the Intel Software
Developer's Manual; in the meantime I DO speak officially for Intel on
this issue.
The x86 Advisory Council has ratified this decision, and so it is
expected to be honored across vendors, but I obviously cannot make any
official statement on any other vendor's behalf.
I am covered by the Intel-FSF copyright assignment for binutils.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
I think it's uninteresting to step into gdb::ref_ptr::get, so add a skip
entry for it. I am adding just one to get the party started, but there
are certainly more like this that we could skip.
Change-Id: Ib074535c96a62137de63bbe58ff168a1e913688f
Approved-By: Tom Tromey <tom@tromey.com>
I don't know if this is true on all platforms, but from what I can see
on Linux, the dump commands don't output anything. Use
gdb_test_no_output, which should be a bit more robust than checking for
some specific error patterns.
Change-Id: Idc82298c4752ba7808659dfea2f8324c8a97052d
Approved-By: Tom Tromey <tom@tromey.com>
The manual claims that the -list-features and -list-target-features MI
commands return their result in a field named "result". The field is
actually named "features", and always has been since the introduction of
these commands in 084344d and c6ebd6c. See mi_cmd_list_features and
mi_cmd_list_target_features in gdb/mi/mi-main.c.
Approved-By: Tom Tromey <tom@tromey.com>
Even though the core_find proc will log a warning, it's better to log
"untested" and then terminate the test. This will help to avoid
silently skipped tests, when running the testsuite. Most of the tests
already do that. This patch adds the missing ones.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
"pre-commit autoupdate" pointed out that a newer version of flake8 has
been released. This patch applies the update. No code changes were
needed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In this commit:
commit dbd05b9edc
Date: Wed Aug 20 10:45:09 2025 +0100
gdb/python: check return value of PyObject_New in all cases
I missed a call to PyObject_New in python/py-disasm.c, which this
commit addresses.
Unlike the previous commit, the call to PyObject_New in py-disasm.c is
contained within the scoped_disasm_info_object class, which makes it
harder to check for NULL and return.
So in this commit I've rewritten the scoped_disasm_info_object class,
moving the call to PyObject_New out into gdbpy_print_insn, which is
the only place that scoped_disasm_info_object was being used.
As scoped_disasm_info_object is no longer responsible for creating the
underlying Python object, I figured that I might as well move the
initialisation of that object out of scoped_disasm_info_object too.
With that done, the scoped_disasm_info_object now has just one task,
invalidating the existing disasm_info_object at the end of the scope.
So I renamed scoped_disasm_info_object to
scoped_invalidate_disasm_info, which reflects its only task.
I made a couple of other small adjustments that were requested during
review, these are both in the same code area: updating
disasm_info_fill to take an object reference rather than a pointer,
and removing the local variable insn_disas_obj from gdbpy_print_insn,
and inline its value at the one place it was used.
There should be no user visible changes after this commit. Except for
the PyObject_New call, which now has proper error checking. But in
the working case, nothing should have changed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
While looking at test-case gdb.tui/tui-missing-src.exp I noticed that
gdb_compile is used to compile multiple sources:
...
if { [gdb_compile "${srcfiles}" "${binfile}" \
executable {debug additional_flags=-O0}] != "" } {
...
meaning there are no separate compile and link steps, as is required for
fission [1].
Fix this by using build_executable instead.
Tested on aarch64-linux.
[1] https://gcc.gnu.org/wiki/DebugFission
During testing of bare-metal applications on QEMU for RISC-V, it was discovered
that the instructions wfi, sfence.vma, sret, and mret were not supported. This
patch introduces support for these instructions. Additionally, it wraps
fetch_instruction function in a try-catch block to gracefully handle errors
that may occur when attempting to read invalid address.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
The Linaro CI reported a regression in test-case
gdb.dwarf2/macro-source-path-clang14-dw4.exp due to recent commit 81e5a23c7b
("[gdb/testsuite] Fix require dwarf2_support check in some test-cases").
The problem is that the "require dwarf2_support" in its new location doesn't
work because proc dwarf2_support is not defined.
I didn't notice this because I tested all gdb.dwarf2 test-cases together, and
a different test-case had already imported the proc.
Fix this by moving load_lib dwarf.exp earlier.
Tested on x86_64-linux.
1. Update dump_relr_relocations to take relr_size, relr_entsize and
relr_offset, instead of a pointer to Elf_Internal_Shdr, as function
arguments.
2. Update process_relocs to call dump_relr_relocations if relocation
type is reltype_relr.
binutils/
PR binutils/33328
* readelf.c (dump_relr_relocations): Replace a pointer to
Elf_Internal_Shdr argument with relr_size, relr_entsize and
relr_offset.
(display_relocations): Update the dump_relr_relocations call.
(process_relocs): Call dump_relr_relocations if relocation type
is reltype_relr.
ld/
PR binutils/33328
* testsuite/ld-i386/dt-relr-1c.d: New file.
* testsuite/ld-i386/dt-relr-1d.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1c-x32.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1c.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1d-x32.d: Likewise.
* testsuite/ld-x86-64/dt-relr-1d.d: Likewise.
* testsuite/ld-i386/i386.exp: Run PR binutils/33328 tests.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Similar to a previous patch, if the gdb executable is in fact a libtool
wrapper, we need to get the path to the real executable to load it in
the top-level gdb.
With this change, the test runs on Cygwin, although I do see two
failures:
FAIL: gdb.gdb/index-file.exp: debug_names files are identical
FAIL: gdb.gdb/index-file.exp: debug_str files are identical
Change-Id: Ie06d1ece67e61530e5b664e65b5ef0edccaf6afa
Reviewed-By: Keith Seitz <keiths@redhat.com>
When running gdb.gdb/selftest.exp on Cygwin, the test eventually times
out on this command:
(gdb) PASS: gdb.gdb/selftest.exp: printed version as pointer
continue
Continuing.
[New Thread 4804.0x1728]
[New Thread 4804.0x2f24]
[New Thread 4804.0x934]
[New Thread 4804.0x23a8]
[New Thread 4804.0x2cf4]
[New Thread 4804.0x1408]
[New Thread 4804.0x2c90]
[New Thread 4804.0xc58]
[New Thread 4804.0x1d40]
[New Thread 4804.0x1824]
GNU gdb (GDB) 17.0.50.20250530-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) [New Thread 4804.0x2c64]
[New Thread 4804.0x23c4]
[New Thread 4804.0x2814]
[Thread 4804.0x1200 exited with code 0]
[Thread 4804.0x293c exited with code 0]
[Thread 4804.0x2c9c exited with code 0]
FAIL: gdb.gdb/selftest.exp: xgdb is at prompt (timeout)
The problem is the new thread notification, and the fact that the test
expects the prompt to be the last thing in the buffer. To avoid the
thread events interfering with the test, disable them, they are not
useful here.
With this patch, gdb.gdb/selftest.exp mostly runs fine on Cygwin, the
only remaining problem appears to be:
(gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process
signal SIGINT
Continuing with signal SIGINT.
PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process, top GDB message
FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process, bottom GDB message (timeout)
Change-Id: I0b1df0503c1961c042c8de559b4d223c5d3cb95c
Reviewed-By: Keith Seitz <keiths@redhat.com>
When building GDB on Cygwin, gdb/gdb.exe is a libtool wrapper (which
happens to be a PE executable). The real executable is at
gdb/.libs/gdb.exe. The "does gdb have debug info test" that
_selftest_setup does is bogus, because it loads the libtool wrapper
(which doesn't have debug info), doesn't see any debug info, and thus
the test is skipped.
The "correct" way to deal with libtool wrappers is to run the shell
command you want to run under `libtool --mode=execute`. That will
replace any path resembling to a libtool wrapper with the real
executable path. But it will also add to the environment the library
paths necessary for this executable to find the libraries it needs.
Therefore, modify the `do_self_tests` proc to:
- run the top-level GDB commands under `libtool --mode=execute`
- pass the path to the inferior GDB on the command-line of the
top-level, so that it gets replaced with the real executable's path
However, the "file" command was previously used to detect the presence
of debug info in the GDB executable. It's not easy to implement this
check when loading the executable directly on the command line. So, add
a separate proc, _selftest_check_executable_debug_info, that spawns a
temporary GDB and does the debug info check through the file command.
This proc uses libtool to obtain the path to the real executable.
When building, we use the bundled libtool.m4 at the top of the tree.
This means that the libtool system package, and therefore the libtool
binary, might not be available. Check for the presence of the libtool
binary first, and only do the conversion if it is found. If it is not
found, the test should still work on platforms that don't require the
conversion.
With this commit, the test runs on Cygwin, even though there are
failures later.
Change-Id: Ie7b712cdc84671a5a017655a7e41687ff23f906c
Reviewed-By: Keith Seitz <keiths@redhat.com>
In the ROCm-GDB testing process, we hit a problem that is a combination
of these 3 factors:
1. In the downstream ROCm-GDB packages, the gdb executable is built with
a relative RUNPATH:
0x000000000000001d (RUNPATH) Library runpath: [${ORIGIN}/../lib]
This is done so that the installation is relocatable (the whole ROCm
directory can be copied around) and things still work. For instance,
the rocgdb executable needs to be able to find the libraries it
needs, such as `librocm-dbgapi.so.0`. The relative runpath allows
that.
2. For testing, we run the testsuite against the gdb executable
installed from one of those packages. It is possible to ./configure
the testsuite directory on its own, and then do:
$ make check RUNTESTFLAGS="GDB=/opt/rocm/bin/rocgdb"
3. The selftests (such as gdb.gdb/selftest.exp) copy the GDB under test
to the standard output directory, before trying to debug it.
The problem is that the gdb executable under test that has been copied
can't find the libraries it needs.
With this patch, I propose that we don't copy the gdb executable, but
debug it in place instead. The comment removed in this patch says "in
case this OS doesn't like to edit its own text space", and has been
there since forever in some form. But it's not clear if there is a host
OS (where we intend to run this test) that needs this nowadays. I would
bet that there isn't. If there is in fact a GDB host OS (where we
intend to run this test) that needs it, we can reinstate the copying,
but as an opt-in operation.
Another situation where this change helps is on Windows, where
gdb/gdb.exe is a libtool wrapper (the real executable is at
gdb/.libs/gdb.exe). Copying gdb/gdb.exe doesn't accomplish anything
useful. The next patch does further changes to account for the libtool
wrapper case.
I tested on Linux and Cygwin, more testing would be welcome.
Change-Id: Id4148517d4fc4ecdd49f099c12003e3d16c6a93d
Reviewed-By: Keith Seitz <keiths@redhat.com>
The function to stop at is always main. Remove the parameter and
hard-code main in _selftest_setup.
Change-Id: Ibbbf598203b1658305eb6bc631d029652c10edac
Reviewed-By: Keith Seitz <keiths@redhat.com>
Rename some procs in lib/selftest-support.exp that are only used
internally, to make it a bit clearer that they are just internal
helpers.
Change-Id: Icd399ac42698209fbc8e798bf43a7d8464aa848c
Reviewed-By: Keith Seitz <keiths@redhat.com>
pre-commit pointed out that gdbarch_components.py had a minor
formatting issue, according to the official version of 'black'. This
patch corrects the oversight.
This binutils test fails with -fsanitize. NOSANITIZE_CFLAGS isn't
available in the binutils testsuite, and importing it over from ld
requires a huge amount of tcl code to be moved. So I chose to simply
add -fno-sanitize=all if -fsanitize= is seem in CFLAGS.
* testsuite/binutils-all/objcopy.exp
(objcopy_test_without_global_symbol): Add -fno-sanitize=all to
flags if -fsanitize= is found in CFLAGS_FOR_TARGET. Tidy use
of objfile.
* testsuite/binutils-all/tek2.obj: Change to a 3 byte data file
that triggers tekhex error fixed by commit bf0f85df12.
* testsuite/binutils-all/ar.exp: Adjust to suit.
* testsuite/binutils-all/objcopy.exp (objcopy_tek2bin): New proc.
This bogus error comes up when trying something like
objcopy -O binary .../binutils/testsuite/binutils-all/tek2.obj xxx
This is an annoying message, as HJ said in
https://sourceware.org/pipermail/binutils/2002-August/021354.html
and removed it for some cases, eg. I can make it go away by specifying
-I tekhex. The message is also untrue, as objcopy does in fact know
the format of the input file.
I think the message should be limited to ELF input files that are
being handled by the elf64-little, elf64-big, elf32-little or
elf32-big targets, due to libbfd being compiled with limited target
support. I'm also changing the message a litle.
* objcopy.c (copy_object): Change "Unable to recognise format"
message to "Unable to recognise architecture" and only report
this error for ELF objects lacking their proper target support.
* testsuite/binutils-all/x86-64/x86-64.exp: Update to suit.
After commit 5e83077d55 we no longer choose a "plugin" target in
objcopy so ibfd->target_defaults can again be used to test whether the
user supplied a target.
PR 33230
* objcopy.c (copy_file): Revert change adding a target_defaulted
variable and passing down to..
(copy_archive, copy_object): ..here. Remove target_defaulted
parameter. Use ibfd->target_defaulted.
There is a bug in expect, see:
https://sourceforge.net/p/expect/patches/26/
which causes empty substring matches from a regexp to instead return
the complete input buffer. To reproduce this bug, try this command:
expect -c 'spawn sh -c "echo -n -e \"abc\""; \
expect -re "(a?)(a)(bc)"; \
puts "\n"; \
for { set i 1 } { $i < 4 } { incr i } { \
puts -nonewline "($i): \""; \
puts -nonewline $expect_out($i,string); \
puts "\"" \
}'
For a working expect the output looks like:
spawn sh -c echo -n -e "abc"
abc
(1): ""
(2): "a"
(3): "bc"
But for a broken expect the output looks like:
spawn sh -c echo -n -e "abc"
abc
(1): "abc"
(2): "a"
(3): "bc"
Notice that (1) is now returning the complete input buffer rather than
the empty string, this is wrong.
This is not the first time this bug has impacted GDB's testsuite,
this commit seems to be working around the same problem:
commit e579b53735
Date: Sat Aug 16 20:32:37 2025 +0200
[gdb/testsuite] Fix TUI tests on freebsd
I recently pushed this commit:
commit 3825c972a6
Date: Wed Jun 18 15:02:29 2025 +0100
gdb: allow gdb.Color to work correctly with pagination
Which added gdb.python/py-color-pagination.exp. Bug PR gdb/33321 was
then created as the test was failing on some hosts. Turns out, this
is same expect bug.
The fix presented here is the same as for e579b53735, avoid
using optional regexp substrings at the start of a regexp, and instead
use two separate regexp patterns. With this change in place, the test
now passes on all hosts.
There's no change in what is being tested after this commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33321
Approved-By: Tom de Vries <tdevries@suse.de>
On msys2-ucrt64, with test-case gdb.server/non-existing-program.exp I get:
...
(gdb) quit^M
gdb_caching_proc allow_xml_test caused gdb_exit to be called
gdb_caching_proc allow_xml_test marked as called
gdb_caching_proc get_mount_point_map marked as called
builtin_spawn gdbserver stdio non-existing-program^M
Error creating process "non-existing-program " (error 2): \
The system cannot find the file specified.^M^M
Exiting^M^M
FAIL: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
This happens because this regexp fails to match:
...
# This is what we get on Windows.
-re "Error creating process\r\n\r\nExiting\r\n" {
...
Fix this by updating the regexp.
Tested on x86_64-w64-mingw32 (msys2-ucrt64).
Say we disable startup-with-shell, we get:
...
(gdb) run `echo 8`^M
Starting program: a2-run `echo 8`^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
usage: factorial <number>^M
[Inferior 1 (process 10787) exited with code 01]^M
(gdb) FAIL: gdb.base/a2-run.exp: run "a2-run" with shell (timeout)
...
Fix this by only doing this test if startup-with-shell is supported.
This fixes the test-case on msys2-ucrt64, where startup-with-shell is not
supported.
Likewise in other test-cases.
Tested on x86_64-linux.
I ran test-case gdb.python/py-color-pagination.exp with make-check-all.sh and
noticed failures when using remote host.
So I grepped to find all test-cases using with_ansi_styling_terminal and ran
them with host/target board local-remote-host-native.
Fix the failing test-cases using require {!is_remote host}.
Tested on x86_64-linux.
Update gdbpy_create_ptid_object (python/py-infthread.c) to return a
gdbpy_ref<> rather than a 'PyObject *'. This reduces the chances that
a caller will leak an object, though no such memory leaks are fixed in
this commit, this is just a code improvement patch.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In corelow.c, in the function rename_vmcore_idle_reg_sections, the
argument ABFD holds the core file bfd pointer. When this function is
called current_program_space->core_bfd() is passed as the argument
value.
Within this function, we sometimes use the function argument, and
sometimes access current_program_space->core_bfd() directly.
This is confusing, and unnecessary. Lets not do that.
I've renamed the argument to cbfd (for Core file BFD), and then
updated the function to make use of this argument throughout. This
reduces the number of accesses to global state, which is, I think, a
good thing.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit changes the signature of the gdbarch_core_info_proc method
so that it takes a 'struct bfd *' as an extra argument. This argument
is used to pass through the core file bfd pointer.
Now, in corelow.c, when calling gdbarch_core_info_proc, we can pass
through current_program_space->core_bfd() as the argument. Within the
implementations, (Linux and FreeBSD) we can use this argument rather
than having to access the core file through current_program_space.
This reduces the use of global state, which I think is a good thing.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The function linux_read_core_file_mappings is passed an argument CBFD,
which is the BFD for the core file. In
core_target::build_file_mappings, where the function is called, we
pass current_program_space->core_bfd() as the argument.
However, in linux_read_core_file_mappings, in some places we use the
CBFD argument, and in other places we directly use
current_program_space->core_bfd(). This is confusing, and
unnecessary. Lets not do that.
Standardise on just using CBFD. This removes some references to
global state in favour of passing the global state in as an argument,
I think this is a good thing.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Implement support for XOP instructions [1] in amd64_get_insn_details.
The encoding scheme is documented here [2]. Essentially it's a variant of the
VEX3 encoding scheme, with:
- 0x8f as the first byte instead of 0xc4, and
- an opcode map >= 8.
The changes are roughly the same as the XOP part of an earlier submission [3],
hence the tag.
The only real difference is that that patch proposed to implement xop_prefix_p
using:
...
return pfx[0] == 0x8f && (pfx[1] & 0x38);
...
which tries to resolve the conflict between the XOP prefix (starts with 0x8f)
and the POP instruction (opcode 0x8f) by detecting that it's not a POP
instruction.
Instead, use the way AMD has resolved this conflict in the specification, by
checking for opcode map >= 8:
...
gdb_byte m = pfx[1] & 0x1f;
return pfx[0] == 0x8f && m >= 8;
...
Tested on x86_64-linux.
Co-Authored-By: Jan Beulich <jbeulich@suse.com>
Reviewed-By: Klaus Gerlicher<klaus.gerlicher.@intel.com>
[1] https://en.wikipedia.org/wiki/XOP_instruction_set
[2] https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/43479.pdf
[3] https://sourceware.org/pipermail/gdb-patches/2019-February/155347.html
I noticed a possible memory leak in gdbpy_create_ptid_object, in
py-infthread.c. We create a Tuple, and hold the reference in a
'PyObject*' local.
If we then fail to create any of the tuple contents we perform an
early exit, returning nullptr, this will leak the Tuple object.
Currently, we create the Tuple as the first action in the function,
but we don't really need the tuple until the end of the function.
In this commit I have:
1. Moved creation of the Tuple until the end of the function, just
before we need it.
2. Stored the Tuple reference in a gdbpy_ref<>. This is not
strictly needed any more, but is (I think) good practice as
future changes to the function will not need to worry about
releasing the Tuple object.
3. Taken the opportunity to replace a NULL with nullptr in this
function.
4. Inlined the local variable declarations to the point of first
use.
There should be no user visible changes after this commit.
No tests as I have no idea how to make gdb_py_object_from_longest (and
friends) fail, and so trigger the memory leak. I suspect we'd never
actually see this leak in the real world, but it doesn't hurt to clean
these things up.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
(1) Description of Problem:
When debugging the following code, the execution result of
the backtrace command is incorrect.
$ cat test.S
.text
.globl fun1
.type fun1, @function
fun1:
or $r12,$r0,$r0
or $r4,$r12,$r0
jr $r1
.globl fun
.type fun, @function
fun:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
bl fun1
or $r12,$r4,$r0
or $r4,$r12,$r0
ld.d $r1,$r3,8
addi.d $r3,$r3,16
jr $r1
.globl main
.type main, @function
main:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
bl fun
nop
ld.d $r1,$r3,8
addi.d $r3,$r3,16
jr $r1
$ gcc test.S -o test
$ gdb test
...
(gdb) b fun1
Breakpoint 1 at 0x748
(gdb) r
Breakpoint 1, 0x0000555555554748 in fun1 ()
(gdb) bt
#0 0x0000555555554748 in fun1 ()
#1 0x0000555555554758 in fun ()
#2 0x0000555555554758 in fun ()
#3 0x0000555555554758 in fun ()
....
--Type <RET> for more, q to quit, c to continue without paging
(2) Root Cause Analysis:
The return address of fun() in r1(ra) is saved on the stack:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
The bl instruction in fun () will call the fun1 () and save
the value of pc+4 to r1(ra).
bl fun1
or $r12,$r4,$r0
Because registers such as fp and ra saved in the stack of the sub-function
are not recorded in current code. When trace back fun() to main(), the pc
of the previous frame to be read from ra register instead of the saved location
on the stack. At this time, the value of ra register in fun() is already the
address of the next instruction after the bl. So it is impossible to trace
back to the main().
(3) Solution:
Record the location of ra, fp, s0 to s8 on the stack to ensure the correct
execution of backtrace.
(4) Test:
$ gdb test
...
(gdb) b fun1
Breakpoint 1 at 0x748
(gdb) r
Breakpoint 1, 0x0000555555554748 in fun1 ()
(gdb) bt
#0 0x0000555555554748 in fun1 ()
#1 0x0000555555554758 in fun ()
#2 0x0000555555554778 in main ()
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
(1) Description of Problem:
When debugging the following code, the execution result of
nexti command is incorrect.
$ cat test.S
.text
.globl fun
.type fun, @function
fun:
or $r12,$r0,$r0
or $r4,$r12,$r0
jr $r1
.globl main
.type main, @function
main:
addi.d $r3,$r3,-16
st.d $r1,$r3,8
bl fun
or $r12,$r4,$r0
or $r4,$r12,$r0
ld.d $r1,$r3,8
addi.d $r3,$r3,16
jr $r1
$ gcc test.S -o test
$ gdb test
...
(gdb) set disassemble-next-line on
(gdb) start
...
Temporary breakpoint 1, 0x0000555555554754 in main ()
=> 0x0000555555554754 <main+8>: 57ffefff bl -20 # 0x555555554740 <fun>
(gdb) ni
0x0000555555554740 in fun ()
=> 0x0000555555554740 <fun+0>: 0015000c move $t0, $zero
(2) Root Cause Analysis:
In the internal execution flow of the ni command, a single-step will be
executed first. After that, it will enter process_event_stop_test (),
some conditions are judged in this function.
if ((get_stack_frame_id (frame)
!= ecs->event_thread->control.step_stack_frame_id)
&& get_frame_type (frame) != SIGTRAMP_FRAME
&& ((frame_unwind_caller_id (frame)
== ecs->event_thread->control.step_stack_frame_id)
&& ((ecs->event_thread->control.step_stack_frame_id
!= outer_frame_id)
|| (ecs->event_thread->control.step_start_function
!= find_pc_function (ecs->event_thread->stop_pc ())))))
{
...
if (ecs->event_thread->control.step_over_calls == STEP_OVER_ALL)
...
else
insert_step_resume_breakpoint_at_caller (frame);
}
Here, it will be judged whether a sub-function has been called based on
whether the frame id before the single step is not equal to the current
frame id and whether there is a calling relationship.
If a sub-function is called at this time and the current operation is nexti,
it will not stop immediately. Instead, insert_step_resume_breakpoint_at_caller()
will be called to complete the execution of the sub-function and then stop.
In above debugging examples, the executable program being debugged is compiled
from an asm source file that does not contain dwarf information. Therefore, the
frame id of the function is calculated by loongarch_frame_unwind rather than
dwarf2_frame_unwind. However, loongarch_scan_prologue() has not yet recorded
stack information in loongarch_frame_cache, this will cause problems in some
operations related to the frame id information.
(3) Solution:
Improve loongarch_scan_prologue() to record the stack information in
loongarch_frame_cache. And improve the loongarch_frame_unwind_stop_reason()
through the information recorded in loongarch_frame_cache.
(4) Test:
After this patch:
$ gdb test
(gdb) set disassemble-next-line on
(gdb) start
Temporary breakpoint 1, 0x0000555555554754 in main ()
=> 0x0000555555554754 <main+8>: 57ffefff bl -20 # 0x555555554740 <fun>
(gdb) ni
0x0000555555554758 in main ()
=> 0x0000555555554758 <main+12>: 0015008c move $t0, $a0
(gdb) ni
0x000055555555475c in main ()
=> 0x000055555555475c <main+16>: 00150184 move $a0, $t0
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
In the current code, loongarch_frame_unwind is a LoongArch prologue unwinder,
it contains the required member functions, but they do not calculate a valid
frame id through prologue of a function frame. Refactor these functions and
use loongarch_frame_cache to record the information of the function frame.
No functional change intended.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Add the definition of loongarch_frame_cache for loongarch_frame_unwind,
this is preparation for later patch on LoongArch.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
VEX and EVEX-encoded instructions generally require a ModR/M byte, with the
notable exception of vzeroall and vzeroupper (opcode 0x77), which do not
use ModR/M.
This change sets need_modrm = 1 for VEX instructions, and adds an exception
for instructions where *insn == 0x77, following Intel’s SDM.
EVEX has no exceptions and thus always sets need_modrm to 1.
Additionally, the legacy twobyte_has_modrm table cannot be used for VEX and
EVEX instructions, as these encodings have different requirements and
exceptions. The logic is now explicit for VEX/EVEX handling.
Add vpblendw to selftest amd64_insn_decode.
The Intel SDM says the following:
1. Intel® 64 and IA-32 Architectures Software Developer’s Manual
Section 2.2.1.2 — Instruction Prefixes
"The VEX prefix is a multi-byte prefix that replaces several legacy prefixes
and opcode bytes. The VEX prefix is not an opcode; it is a prefix that
modifies the instruction that follows."
Section 2.2.1.3 — Opcode Bytes
"The opcode byte(s) follow any instruction prefixes (including VEX). The
opcode specifies the operation to be performed."
Section 2.2.2 — Instruction Format
"If a VEX prefix is present, it is processed as a single prefix, and the
opcode bytes follow immediately after the VEX prefix."
Source: Intel® SDM Vol. 2A, Section 2.2.1.2 and 2.2.2 (See Vol. 2A,
PDF pages 2-4, 2-5, and 2-7)
2. ModRM Byte Requirement
Intel® SDM Vol. 2A, Table 2-2 — VEX Prefix Encoding
"Most VEX-encoded instructions require a ModRM byte, except for a few
instructions such as VZEROALL and VZEROUPPER."
Source: Intel® SDM Vol. 2A, Table 2-2 (See Vol. 2A, PDF page 2-13)
Approved-By: Tom de Vries <tdevries@suse.de>
On x86_64-freebsd, I ran into trouble with test-case
gdb.dwarf2/macro-source-path-clang14-dw4.exp (and similar), and I managed to
reproduce the problem on x86_64-linux by making dwarf2_support return 0.
The failure looks like:
...
UNSUPPORTED: $exp: require failed: dwarf2_support
UNRESOLVED: $exp: testcase aborted due to invalid command name: do_test
ERROR: tcl error sourcing $exp.
...
I fixed a similar problem in commit 3e488d8ccd ("[gdb/testsuite] Fix
gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh").
Fix this by moving "require dwarf2_support" from
gdb.dwarf2/macro-source-path.exp.tcl to the files including it.
Tested on x86_64-linux.
First we should check the flag alone, not the entire flags value
matching BSF_WEAK. And then using "else if()" is inappropriate here: A
weak symbol can very well also be absolute, and hence wouldn't want a
relocation emitted despite being defined.
x86 gas may produce .note.gnu.property by default. Hence the default
linker script would better also deal with that section, rather than
causing diagnostics when using --orphan-handling=. Replace all mis-
spellings that have accumulated.
To avoid needlessly relaxing expectations for two tests when run for
PPC 64-bit ELF targets, suppress the linker generating EH frame data
there.
While commit 9c0adb10c7 ("elf: Clear entsize when clearing
SEC_MERGE|SEC_STRINGS") addressed the particular issue reported in
PR ld/33291, it didn't go quite far enough to deal with related aspects
as well:
As indicated in other recent commits, the three properties can be
largely independent (ELF generally being the target here): Entry size
doesn't require either of merge/strings, and strings also doesn't
require merge. Commit 98e6d3f5bd ("gas/ELF: allow specifying entity
size for arbitrary sections") uncovered issues with ld's handling.
Zap entry size when it doesn't match between input sections. In that
case SEC_MERGE and SEC_STRINGS also need to be removed, as their
underlying granularity is lost. Then deal with SEC_MERGE and
SEC_STRINGS separately.
Otoh record entry size from the first input independent of SEC_MERGE.
