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

Andrew Cagney
2004-03-10T01:51:11Z

> 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