Problem with DEPRECATED_FP_REGNUM def for i386

[Nicholas Mc Guire <root at hofr dot at>]

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