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


On Tue, Mar 09, 2004 at 10:05:29PM -0500, Daniel Jacobowitz wrote:

Think about this for a moment.  I'm going to give addresses so that I
can be more precise.

0x10 <stuff>: ret		stuff(int) { }
0x20 <main>: push		main() {
0x21 <main+1>: push			{
0x22 <main+2>: move arg1, i			stuff(i)
0x23 <main+3>: call stuff			  "
0x24 <main+4>: pop			}
0x25 <main+5>: pop		}
0x26 <main+6>: ret		"

The inner scope is probably <main+2> to <main+3> inclusive.

It is "pc in [<main+2>,<main+4>]" -- only after executing the instuction at <main+4> is the inner most scope destroyed.



Suppose PC == 0x10. We backtrace. Look at main; saved PC is 0x24. We want an address in the block. We subtract 1. OK, saved addr-in-block is 0x23. 'i' is in scope.

In your example there isn't a need to substract one -- the return address <main+4> is still inside the correct block (it does no harm though).


Suppose PC == 0x24.  Shouldn't this be the same?  For the purposes of
looking at local variables, aren't we still in the the block?

PC=24 (that "<main+4>)" edge case) is also in the correct block.


Suppose PC was 0x24 and we got a signal. Ditto.

Suppose PC == 0x20 and we get a signal.  Obviously we don't want to
change the behavior of this.

Now consider this example:


>>> 10 0x10 <stuff>: ret		stuff(int) { }
>>> 11 0x20 <main>: push		main() {
>>> 12 0x21 <main+1>: push			{
>>> 13 0x22 <main+2>: move arg1, i			stuff(i)
>>> 14 0x23 <main+3>: call stuff			  "
>>> 15                  			}
>>> 16 0x25 <main+5>: pop  2; ret	}

Note how that closing brace @15 doesn't have code associated with it. Its possible to breakpoint @14 or @16 only. Consequently:

- the return address will be @16 and is _out_ of scope
hence "@16 - 1" is needed to find the correct block when doing a backtrace

- once returned from stuff(), the pc is clearly @16 which, to the user, will visibly reflect the departure from the inner scope

BTW, my proposed replacement is woefully inaccurate, which I should
have realized before posting.  I do not have a good solution to this
problem without actually turning back time :)

I'm wondering what the 3.4 wierdness MichaelC's refering to is.


Andrew



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