This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
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