| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Having a useful __repr__ method can make debugging Python code that
little bit easier. This commit adds __repr__ for gdb.PendingFrame and
gdb.UnwindInfo classes, along with some tests.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The gdb.Frame class has far more methods than gdb.PendingFrame. Given
that a PendingFrame hasn't yet been claimed by an unwinder, there is a
limit to which methods we can add to it, but many of the methods that
the Frame class has, the PendingFrame class could also support.
In this commit I've added those methods to PendingFrame that I believe
are safe.
In terms of implementation: if I was starting from scratch then I
would implement many of these (or most of these) as attributes rather
than methods. However, given both Frame and PendingFrame are just
different representation of a frame, I think there is value in keeping
the interface for the two classes the same. For this reason
everything here is a method -- that's what the Frame class does.
The new methods I've added are:
- gdb.PendingFrame.is_valid: Return True if the pending frame
object is valid.
- gdb.PendingFrame.name: Return the name for the frame's function,
or None.
- gdb.PendingFrame.pc: Return the $pc register value for this
frame.
- gdb.PendingFrame.language: Return a string containing the
language for this frame, or None.
- gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object
for the current location within the pending frame, or None.
- gdb.PendingFrame.block: Return a gdb.Block for the current
pending frame, or None.
- gdb.PendingFrame.function: Return a gdb.Symbol for the current
pending frame, or None.
In every case I've just copied the implementation over from gdb.Frame
and cleaned the code slightly e.g. NULL to nullptr. Additionally each
function required a small update to reflect the PendingFrame type, but
that's pretty minor.
There are tests for all the new methods.
For more extensive testing, I added the following code to the file
gdb/python/lib/command/unwinders.py:
from gdb.unwinder import Unwinder
class TestUnwinder(Unwinder):
def __init__(self):
super().__init__("XXX_TestUnwinder_XXX")
def __call__(self,pending_frame):
lang = pending_frame.language()
try:
block = pending_frame.block()
assert isinstance(block, gdb.Block)
except RuntimeError as rte:
assert str(rte) == "Cannot locate block for frame."
function = pending_frame.function()
arch = pending_frame.architecture()
assert arch is None or isinstance(arch, gdb.Architecture)
name = pending_frame.name()
assert name is None or isinstance(name, str)
valid = pending_frame.is_valid()
pc = pending_frame.pc()
sal = pending_frame.find_sal()
assert sal is None or isinstance(sal, gdb.Symtab_and_line)
return None
gdb.unwinder.register_unwinder(None, TestUnwinder())
This registers a global unwinder that calls each of the new
PendingFrame methods and checks the result is of an acceptable type.
The unwinder never claims any frames though, so shouldn't change how
GDB actually behaves.
I then ran the testsuite. There was only a single regression, a test
that uses 'disable unwinder' and expects a single unwinder to be
disabled -- the extra unwinder is now disabled too, which changes the
test output. So I'm reasonably confident that the new methods are not
going to crash GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit copies the pattern that is present in many other py-*.c
files: having a single macro to check that the Python object is still
valid.
This cleans up the code a little throughout the py-unwind.c file.
Some of the exception messages will change slightly with this commit,
though the type of the exceptions is still ValueError in all cases.
I started writing some tests for this change and immediately ran into
a problem: GDB would crash. It turns out that the PendingFrame
objects are not being marked as invalid!
In pyuw_sniffer where the pending frames are created, we make use of a
scoped_restore to invalidate the pending frame objects. However, this
only restores the pending_frame_object::frame_info field to its
previous value -- and it turns out we never actually give this field
an initial value, it's left undefined.
So, when the scoped_restore (called invalidate_frame) performs its
cleanup, it actually restores the frame_info field to an undefined
value. If this undefined value is not nullptr then any future
accesses to the PendingFrame object result in undefined behaviour and
most likely, a crash.
As part of this commit I now initialize the frame_info field, which
ensures all the new tests now pass.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Spotted a redundant nullptr check in python/py-frame.c in the function
frapy_block. This was introduced in commit 57126e4a45e3000e when we
expanded an earlier check in return early if the pointer in question
is nullptr.
There should be no user visible changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit makes a few related changes to the gdb.unwinder.Unwinder
class attributes:
1. The 'name' attribute is now a read-only attribute. This prevents
user code from changing the name after registering the unwinder. It
seems very unlikely that any user is actually trying to do this in
the wild, so I'm not very worried that this will upset anyone,
2. We now validate that the name is a string in the
Unwinder.__init__ method, and throw an error if this is not the
case. Hopefully nobody was doing this in the wild. This should
make it easier to ensure the 'info unwinder' command shows sane
output (how to display a non-string name for an unwinder?),
3. The 'enabled' attribute is now implemented with a getter and
setter. In the setter we ensure that the new value is a boolean,
but the real important change is that we call
'gdb.invalidate_cached_frames()'. This means that the backtrace
will be updated if a user manually disables an unwinder (rather than
calling the 'disable unwinder' command). It is not unreasonable to
think that a user might register multiple unwinders (relating to
some project) and have one command that disables/enables all the
related unwinders. This command might operate by poking the enabled
attribute of each unwinder object directly, after this commit, this
would now work correctly.
There's tests for all the changes, and lots of documentation updates
that both cover the new changes, but also further improve (I think)
the general documentation for GDB's Unwinder API.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
PR 30285
* elf.c (_bfd_elf_slurp_version_tables): Fail if no version definitions are allocated.
|
|
gprofng/ChangeLog
2023-03-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30089
* libcollector/libgprofng.ver: Add version symbols.
* libcollector/synctrace.c: Fix typo for pthread_mutex_lock.
|
|
It's wrong to have an alloc reloc section trying to use a non-alloc
symbol table.
* elf.c (assign_section_numbers <SHT_REL, SHT_RELA>): Correct
comment. Always set sh_link to .dynsym for alloc reloc
sections and to .symtab for non-alloc.
|
|
* opncls.c (bfd_get_alt_debug_link_info): Don't bother freeing
after bfd_malloc_and_get_section failure.
(get_build_id): Likewise.
(bfd_get_debug_link_info_1): Likewise. Free section contents
when crc not present.
* section.c (bfd_malloc_and_get_section): Document that the
buffer is NULL on error return.
|
|
* objcopy.c (delete_symbol_htabs): Also free symbols.
(write_debugging_info): Free strings and syms once written.
* wrstabs.c (write_stabs_in_sections_debugging_info): memset
entire info struct. Free hash tables before returning. Free
syms on error return.
|
|
* addr2line.c (process_file): Close bfd on error paths.
|
|
|
|
|
|
The non-preemptible SHN_ABS symbol with a pc-relative relocation should be
disallowed when generating shared object (pic and pie). Generally, the
following cases, which refer to pr25749, will cause a symbol be
non-preemptible,
* -pie, or -shared with -symbolic
* STV_HIDDEN, STV_INTERNAL, STV_PROTECTED
* Have dynamic symbol table, but without the symbol
* VER_NDX_LOCAL
However, PCREL_HI20/LO12 relocs are always bind locally when generating
shared object, so not only the non-preemptible absolute symbol need to
be disallowed, all absolute symbol references need but except that they
are defined in linker script. If we also disallow the absolute symbol
in linker script, then the glibc-linux toolchain build failed, so regard
them as pc-relative symbols, just like what x86 did.
Maybe we should add this check for all pc-relative relocations, rather
than just handle in R_RISCV_PCREL relocs. Ideally, since the value of
SHN_ABS symbol is a constant, only S - A relocations should be allowed
in the shared object, so only BFD_RELOC_8/16/32/64 are allowed, which
means R_RISCV_32/R_RISCV_64.
bfd/
PR 28789
* elfnn-riscv.c (riscv_elf_check_relocs): The absolute symbol cannot be
referneced with pc-relative relocation when generating shared object.
ld/
PR 28789
* ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* ld/testsuite/ld-riscv-elf/pcrel-reloc*: New testcases.
|
|
There are two improvements, which are all referenced to aarch64,
* R_RISCV_32 with non ABS symbol cannot be used under RV64 when making
shard objects.
* Don't need dynamic relocation for R_RISCV_32/64 under RV32/RV64 when
making shared objects, if the referenced symbol is local ABS symbol.
However, considering this link,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/341
Seems like we should makes all R_RISCV_32/64 relocs with ABS symbol
that don't need any dynamic relocations when making the shared objects.
But anyway, I just sync the current behavior as aarch64 ld, in case
there are any unexpected behaviors happen.
Passed the gcc/binutils regressions in riscv-gnu-toolchain.
bfd/
* elfnn-riscv.c (riscv_elf_check_relocs): Only allow R_RISCV_32 with ABS
symbol under RV64.
(riscv_elf_relocate_section): R_RISCV_32/64 with local ABS symbol under
RV32/RV64 doesn't need any dynamic relocation when making shared objects.
I just make the implementations similar to other targets, so that will be
more easy to mainatain.
ld/
* testsuite/ld-riscv-elf/data-reloc*: New testcases.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Added new data-reloc* testcases,
and need to make ifunc-seperate* testcases work for rv32.
* testsuite/ld-riscv-elf/ifunc-seperate-caller-nonplt.s: Likewise.
* testsuite/ld-riscv-elf/ifunc-seperate-caller-plt.s: Likewise.
|
|
These types of codes are different for each target, I am not sure what are the
best for RISC-V, so extract them out may be more easy to compare what's the
difference.
bfd/
* elfnn-riscv.c (RISCV_NEED_DYNAMIC_RELOC): New defined. Extracted
from riscv_elf_check_relocs, to see if dynamic reloc is needed for the
specific relocation.
(RISCV_GENERATE_DYNAMIC_RELOC): New defined. Extracted from
riscv_elf_relocate_section, to see if R_RISCV_32/64 need to generate
dynamic relocation.
(RISCV_COPY_INPUT_RELOC): New defined. Extracted from
riscv_elf_relocate_section, to see if R_RISCV_32/64 need to copy itslef
tp output file.
(RISCV_RESOLVED_LOCALLY): New defined. Extracted from
riscv_elf_relocate_section, to see if R_RISCV_GOT_HI20 can be resolved
locally.
|
|
The test case in this patch shows an unusual situation: an Ada array
has a dynamic bound, but the bound comes from a frame that's referred
to by the static link. This frame is correctly found when evaluating
the array variable itself, but is lost when evaluating the array's
bounds.
This patch fixes the problem by passing this frame through to
value_at_lazy in the DWARF expression evaluator.
|
|
This patch adds a 'frame' parameter to value_at_lazy and ensures that
it is passed down to the call to resolve_dynamic_type. This required
also adding a frame parameter to value_from_contents_and_address.
Nothing passes this parameter to value_at_lazy yet, so this patch
should have no visible effect.
|
|
This adds a frame parameter to resolve_dynamic_type and arranges for
it to be passed through the call tree and, in particular, to all calls
to dwarf2_evaluate_property.
Nothing passes this parameter yet, so this patch should have no
visible effect.
A 'const frame_info_ptr *' is used here to avoid including frame.h
from gdbtypes.h.
|
|
version_at_least is a less capable variant of version_compare, so this
patch removes it.
|
|
This rewrites version_compare to allow the input lists to have
different lengths, then rewrites rust_at_least to use version_compare.
|
|
This adds a 'rust_at_least' helper proc, for checking the version of
the Rust compiler in use. It then changes various tests to use this
with 'require'.
|
|
With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into:
...
compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb
prog.adb:16:11: warning: file name does not match unit name, should be "main.adb"
prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow)
gnatmake: "prog.adb" compilation error
FAIL: gdb.ada/verylong.exp: compilation prog.adb
...
AFAICT, support for Long_Long_Long_Integer was added in gcc 11.
Fix this by requiring gnatmake version 11 or higher in the test-case.
Tested on x86_64-linux.
|
|
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
|
|
The ERROR_NO_INFERIOR macro is already called at the beginning of the
function continue_command. Since target/inferior are not switched in-between,
the second call to it is redundant.
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
|
|
It was pointed out during review of another patch that the function
displaced_step_dump_bytes really isn't specific to displaced stepping,
and should really get a more generic name and move into gdbsupport/.
This commit does just that. The function is renamed to
bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}. The
function implementation doesn't really change. Much...
... I have updated the function to take an array view, which makes it
slightly easier to call in a couple of places where we already have a
gdb::bytes_vector. I've then added an inline wrapper to convert a raw
pointer and length into an array view, which is used in places where
we don't easily have a gdb::bytes_vector (or similar).
Updated all users of displaced_step_dump_bytes.
There should be no user visible changes after this commit.
Finally, I ended up having to add an include of gdb_assert.h into
array-view.h. When I include array-view.h into common-utils.h I ran
into build problems because array-view.h calls gdb_assert.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
While investigating a displaced stepping issue I wanted an easy way to
see what GDB thought the original instruction was, and what
instruction GDB replaced that with when performing the displaced step.
We do print out the address that is being stepped, so I can track down
the original instruction, I just need to go find the information
myself.
And we do print out the bytes of the new instruction, so I can figure
out what the replacement instruction was, but it's not really easy.
Also, the code that prints the bytes of the replacement instruction
only prints 4 bytes, which clearly isn't always going to be correct.
In this commit I remove the existing code that prints the bytes of the
replacement instruction, and add two new blocks of code to
displaced_step_prepare_throw. This new code prints the original
instruction, and the replacement instruction. In each case we print
both the bytes that make up the instruction and the completely
disassembled instruction.
Here's an example of what the output looks like on x86-64 (this is
with 'set debug displaced on'). The two interesting lines contain the
strings 'original insn' and 'replacement insn':
(gdb) step
[displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now
[displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 0x404018 <puts@got.plt>
[displaced] prepare: selected buffer at 0x401052
[displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] fixup_riprel: %rip-relative addressing used.
[displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036
[displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff
[displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052
[displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00 jmp *0x2fe2(%rcx)
[displaced] finish: restored 2892655.2892655.0 0x401052
[displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ...
[displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578
0x00007ffff7e402c0 in puts () from /lib64/libc.so.6
(gdb)
One final note. For many targets that support displaced stepping (in
fact all targets except ARM) the replacement instruction is always a
single instruction. But on ARM the replacement could actually be a
series of instructions.
The debug code tries to handle this by disassembling the entire
displaced stepping buffer. Obviously this might actually print more
than is necessary, but there's (currently) no easy way to know how
many instructions to disassemble; that knowledge is all locked in the
architecture specific code. Still I don't think it really hurts, if
someone is looking at this debug then hopefully they known what to
expect.
Obviously we can imagine schemes where the architecture specific
displaced stepping code could communicate back how many bytes its
replacement sequence was, and then our debug print code could use this
to limit the disassembly. But this seems like a lot of effort just to
save printing a few additional instructions in some debug output.
I'm not proposing to do anything about this issue for now.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Fix test-case gdb.guile/scm-symbol.exp for remote host by making a regexp less
strict.
Likewise in gdb.guile/scm-symtab.exp.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-parameter.exp for remote host by taking into
account that gdb_reinitialize_dir has no effect for remote host.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-objfile-script.exp using gdb_remote_download.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-objfile-script.exp using host_standard_output_file.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-cmd.exp using readline_is_used.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/guile.exp for remote host using gdb_remote_download.
Tested on x86_64-linux.
|
|
This function doesn't just initialise for compression, it actually
compresses. This patch sanity checks section size before allocating
buffers for the uncompressed contents.
* compress.c (bfd_init_section_compress_status): Sanity check
section size.
|
|
We have way too much duplicated code in bfd. Apply dd3a3d0af9f6 and
920581c57e08 to pdp11.c.
* pdp11.c (bfd_free_cached_info): Free line_buf. Return true
if tdata.aout_data is NULL.
|
|
run_host_cmd adds $gcc_B_opt and $ld_L_opt to the command line if it
detects the program being run is a compiler. Since the program being
run in lto.exp linking pr28138 is "sh", we need to add these by hand.
This isn't exactly as run_host_cmd does, as it lacks reordering of
any user -B option in $CC_FOR_TARGET, but it's better than ignoring
gcc_B_opt. This fixes a mips64 testsuite fail.
ld_compile adds CFLAGS_FOR_TARGET and other flags as well, so there
is no need for the ld_compile command line to include
CFLAGS_FOR_TARGET. Fixing this is just a tidy.
* testsuite/ld-plugin/lto.exp: Add gcc_B_opt, CFLAGS_FOR_TARGET
and $ld_L_opt to pr28138 link line.
* testsuite/lib/ld-lib.exp (run_ld_link_tests): Don't pass
unnecessary flags to ld_compile.
(run_ld_link_exec_tests, run_cc_link_tests): Likewise.
|
|
|
|
Per an earlier discussion, this patch renames the existing "raw" APIs
to use the word "unrelocated" instead.
|
|
This changes minimal symbols to use unrelocated_addr. I believe this
detected a latent bug in add_pe_forwarded_sym.
|
|
This changes psymbols themselves to use unrelocated_addr. This
transform is largely mechanical. I don't think it finds any bugs.
|
|
This changes partial symbol tables to use unrelocated_addr for the
text_high and text_low members. This revealed some latent bugs in
ctfread.c, which are fixed here.
|
|
This moves the definition of unrelocated_addr a bit earlier in
symtab.h, so that it can be used elsewhere in the file.
|
|
This changes gdb_bfd_lookup_symbol to use a function_view. This
simplifies the code a little bit.
|
|
Fix test-case gdb.btrace/multi-inferior.exp for remote host using
gdb_remote_download.
Tested on x86_64-linux.
|
|
Fix test-case gdb.btrace/gcore.exp for remote host using
host_standard_output.
Tested on x86_64-linux.
|
|
Fix test-case gdb.btrace/reconnect.exp for target board
remote-gdbserver-on-localhost using gdb_remote_download.
Tested on x86_64-linux.
|
|
PR mi/11335 points out that an MI varobj will not display the result
of a pretty-printer's "to_string" method. Instead, it always shows
"{...}".
This does not seem very useful, and there have been multiple
complaints about it over the years. This patch changes varobj to emit
this string when possible, and updates the test suite.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
|
|
When an allow_* proc returns false, it can be a bit difficult what check
failed exactly, if the procedure does multiple checks. To make
investigation easier, I propose to allow the "require" callbacks to be
able to return a list of two elements: the zero/non-zero value, and a
reason string.
Use the new feature in allow_hipcc_tests to demonstrate it (it's also
where I hit actually hit this inconvenience). On my computer (where GDB
is built with amd-dbgapi support but where I don't have a suitable GPU
target), I get:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found)
vs before:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests
Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Fix test-case gdb.server/server-kill-python.exp for remote host using
gdb_remote_download.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/sysroot.exp for remote host, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host/target, unless
remote host == remote target.
Tested on x86_64-linux.
|
