Hi !
GDB Version : 6.3 and 6.5
Platform : Linux
Architecture: i386
Summary : DEPRECATED_FP_REGNUM defaults to -1
We have a problem with the frame pointer being set == stack pointer on
i386 in traceopint related functions - as they are not used outside of
tracepoints I guess nobody noticed this - code seems to be 2002
in gdb/arch_utils.c
void
legacy_virtual_frame_pointer (CORE_ADDR pc,
int *frame_regnum,
LONGEST *frame_offset)
{
/* FIXME: cagney/2002-09-13: This code is used when identifying the
frame pointer of the current PC. It is assuming that a single
register and an offset can determine this. I think it should
instead generate a byte code expression as that would work better
with things like Dwarf2's CFI. */
if (DEPRECATED_FP_REGNUM >= 0 && DEPRECATED_FP_REGNUM < NUM_REGS)
*frame_regnum = DEPRECATED_FP_REGNUM;
else if (SP_REGNUM >= 0 && SP_REGNUM < NUM_REGS)
*frame_regnum = SP_REGNUM;
else
/* Should this be an internal error? I guess so, it is reflecting
an architectural limitation in the current design. */
internal_error (__FILE__, __LINE__, _("No virtual frame pointer
available"));
*frame_offset = 0;
}
is defined - which returns frame_regnum = 4 (SP_REGNUM) in the
call to TARGET_VIRTUAL_FRAME_POINTER (i.e. in dwarf2loc.c ) where it
should regurn 5, but it seems that DEPRECATED_FP_REGNUM was never set
any where thus it yields -1 in the above code.
any suggestion how this can be fixed in the right way ? This would be
needed to get tracepoints working properly on i386 (work on PPC). If I
brute force set the register number to 5 with
ax_reg (ax, 5);
instead of
ax_reg (ax, frame_reg);
(in gdb/dwarf2loc.c -> dwarf2_tracepoint_var_ref) then tracepoints work ok
on i386 for me - so Im quite sure that the tracepoint implementeation is
ok. I just could not figure out where this would need to be initialized (
presumably to I386_EBP_REGNUM ?).
My second question would be regarding integration of tracepoints in
mainstream gdb - how could this be done ? We have now encapsulated it all
relatively clean in seperated files
New files for tracepoints:
gdb-6.5-tp/gdb/gdbserver/tp.c
gdb-6.5-tp/gdb/gdbserver/tp.h
gdb-6.5-tp/gdb/gdbserver/list.c
gdb-6.5-tp/gdb/gdbserver/list.h
patches to existing files:
gdb-6.5-tp/gdb/gdbserver/Makefile.in
gdb-6.5-tp/gdb/gdbserver/linux-i386-low.c
gdb-6.5-tp/gdb/gdbserver/linux-low.c
gdb-6.5-tp/gdb/gdbserver/linux-low.h
gdb-6.5-tp/gdb/gdbserver/remote-utils.c
gdb-6.5-tp/gdb/gdbserver/server.c
gdb-6.5-tp/gdb/gdbserver/server.h
bug fixes (atleast we think these are bugs ;)
gdb-6.5-tp/gdb/dwarf2loc.c
gdb-6.5-tp/gdb/tracepoint.c
complete patch:
tp-linux-gdb-6.3.patch (85kB)
tp-linux-gdb-6.5.patch (85kB)
documentaiton for the whole thing in Linux
tp.pdf
its fairly well documented (in source and as external document) and got
some testing (definitly not sufficient yet on i386, PPC405/440/970) -
this was done for a commercial customer who would release it under GPL V2.
Knonwn limitations:
tracepoints and breakpoints at the same line of code does not work , but
that is regarded a minor problem as it makes littel sense to have
tracepoints and breakpoints in use at the same time.
Currently one must explicidly collect $regs (that should not be hard to
fix just did not do it yet) - minor problem
tfind starts at the wrong index (increment of frame number at wrong
position in tp.c - not resolved yet) - minor problem
The only known problem is the above mentioned DEPRECATED_FP_REGNUM mess on
i386 no such problems on PPC...
thx!
hofrat
