61e2dde2db
This patch came about because I wanted to write a frame unwinder that
would corrupt the backtrace in a particular way. In order to achieve
what I wanted I ended up trying to write an unwinder like this:
class FrameId(object):
.... snip class definition ....
class TestUnwinder(Unwinder):
def __init__(self):
Unwinder.__init__(self, "some name")
def __call__(self, pending_frame):
pc_desc = pending_frame.architecture().registers().find("pc")
pc = pending_frame.read_register(pc_desc)
sp_desc = pending_frame.architecture().registers().find("sp")
sp = pending_frame.read_register(sp_desc)
# ... snip code to decide if this unwinder applies or not.
fid = FrameId(pc, sp)
unwinder = pending_frame.create_unwind_info(fid)
unwinder.add_saved_register(pc_desc, pc)
unwinder.add_saved_register(sp_desc, sp)
return unwinder
The important things here are the two calls:
unwinder.add_saved_register(pc_desc, pc)
unwinder.add_saved_register(sp_desc, sp)
On x86-64 these would fail with an assertion error:
gdb/regcache.c:168: internal-error: int register_size(gdbarch*, int): Assertion `regnum >= 0 && regnum < gdbarch_num_cooked_regs (gdbarch)' failed.
What happens is that in unwind_infopy_add_saved_register (py-unwind.c)
we call register_size, as register_size should only be called on
cooked (real or pseudo) registers, and 'pc' and 'sp' are implemented
as user registers (at least on x86-64), we trigger the assertion.
A simple fix would be to check in unwind_infopy_add_saved_register if
the register number we are handling is a cooked register or not, if
not we can throw a 'Bad register' error back to the Python code.
However, I think we can do better.
Consider that at the CLI we can do this:
(gdb) set $pc=0x1234
This works because GDB first evaluates '$pc' to get a register value,
then evaluates '0x1234' to create a value encapsulating the
immediate. The contents of the immediate value are then copied back
to the location of the register value representing '$pc'.
The value location for a user-register will (usually) be the location
of the real register that was accessed, so on x86-64 we'd expect this
to be $rip.
So, in this patch I propose that in the unwinder code, when
add_saved_register is called, if it is passed a
user-register (i.e. non-cooked) then we first fetch the register,
extract the real register number from the value's location, and use
that new register number when handling the add_saved_register call.
If either the value location that we get for the user-register is not
a cooked register then we can throw a 'Bad register' error back to the
Python code, but in most cases this will not happen.
gdb/ChangeLog:
* python/py-unwind.c (unwind_infopy_add_saved_register): Handle
saving user registers.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind-user-regs.c: New file.
* gdb.python/py-unwind-user-regs.exp: New file.
* gdb.python/py-unwind-user-regs.py: New file.
37 lines
963 B
C
37 lines
963 B
C
/* This test program is part of GDB, the GNU debugger.
|
|
|
|
Copyright 2021 Free Software Foundation, Inc.
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License as published by
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
(at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
volatile int global_var;
|
|
|
|
void __attribute__ ((noinline))
|
|
foo (void)
|
|
{
|
|
++global_var; /* Break here. */
|
|
}
|
|
|
|
void __attribute__ ((noinline))
|
|
bar (void)
|
|
{
|
|
foo ();
|
|
}
|
|
|
|
int
|
|
main (void)
|
|
{
|
|
bar ();
|
|
return 0;
|
|
}
|