This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

tracepoint bytecode question


HI !

 after writing up tracepoints in a minimum version that actually kind of
 works (gdb-6.3) I noticed that there seems to be a lot of problems with 
 the actual bytecode generated. simple things like 

 collect $reg
 collect variable_name

 work ok, if it gets any more complicated the bytecode seems to be wrong

 i.e.

 collect x->y
 collect var1 + var2

 will produce wrong offsets and thus garbage traces, same thing if compiled
 with optimization... 

 so what I would like to know is how I can figure out what the bytecode
 should look like of if it is correct and its my interpreter that is scewing
 up - is there any more detailed document on the way bytecode gets calculated
 or am I down to "read the source" - calculating the X packet output on paper
 the addresses that are finally recorded seem to be wrong. scaning the path
 I found the following in the source - which may be someone could explain ?

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 the offset really always 0 ??
Also the register used here is SP_REGNUM (4 on i386) but it should be 5 ??

The code in question has not really changed in 6.4 - so this should hold
for the current gdb - I did not want to move on to a newer version without
this woring first.
 
thx !
hofrat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]