This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [RFC/RFA] gdb.cp/classes.exp: Don't try to print local variableout of scope



BTW, I think the NORMAL_FRAME check is wrong too:

    {
      int i;
      stuff (i);
->  }

get signal

Er, hold on. The intent of address-in-block is:


/* An address (not necessarily alligned to an instruction boundary)
   that falls within THIS frame's code block.

   When a function call is the last statement in a block, the return
   address for the call may land at the start of the next block.
   Similarly, if a no-return function call is the last statement in
   the function, the return address may end up pointing beyond the
   function, and possibly at the start of the next function.

   These methods make an allowance for this.  For call frames, this
   function returns the frame's PC-1 which "should" be an address in
   the frame's block.  */

and:

  /* If THIS frame is not inner most (i.e., NEXT isn't the sentinel),
     and NEXT is `normal' (i.e., not a sigtramp, dummy, ....) THIS
     frame's PC ends up pointing at the instruction fallowing the
     "call".  Adjust that PC value so that it falls on the call
     instruction (which, hopefully, falls within THIS frame's code
     block.  So far it's proved to be a very good approximation.  See
     get_frame_type for why ->type can't be used.  */

It's not possible to construct my senario:

daniel:
>> If that's right, it sounds like we should be using the address-in-block
hack to figure out what local variables are in scope for the top
frame.  But that runs the risk of, for instance, moving us back into a
preceeding function.


Er, that sounds like a theoretical address-in-block bug? The value returned should be floored by (as in can't be less than) the function start. Can you think of an edge case that makes this real?

The only way to get a PC pointing at the first instruction of a function is for that function to have been interrupted just as that first instruction was about to be executed -- thats the very case where the existing address_in_block correctly leaves the PC as is.


In the example in question:

>
>     {
>       int i;
>       stuff (i);
> ->  }

the existing code correctly puts the PC at the instruction about to destroy the prologue.

Use the sigtramp saved PC unmodified, and it leaves you in the right
function - but that doesn't mean it leaves you in the right block!

Maybe something like (considering recent discussion about
get_frame_func):

/* Return an address of that falls within the frame's code block. */

CORE_ADDR
get_frame_address_in_block (struct frame_info *this_frame)
{ /* A draft address. */
CORE_ADDR pc = get_frame_pc (this_frame);
CORE_ADDR func = get_frame_func (this_frame);


  if (pc != func)
    pc--;

  return pc;
}

Note that this doesn't work for functions with discontiguous address
ranges, which GCC will soon be generating; but neither does anything
else in GDB, so we can tackle that with a fixme :)

Andrew




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