This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI -var-create frame-addr specification
- From: Daniel Jacobowitz <drow at false dot org>
- To: Christophe LYON <christophe dot lyon at st dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 4 May 2006 10:56:07 -0400
- Subject: Re: MI -var-create frame-addr specification
- References: <44522A81.9090208@st.com>
On Fri, Apr 28, 2006 at 04:45:21PM +0200, Christophe LYON wrote:
> Hi all,
>
> Currently, the test gdb.mi/mi-var-display.exp fails with our compiler on
> "create variable a2 in different scope".
>
> I am not very familiar with MI, and I don't understand well how the
> "frame-addr" parameter works?
> Shouldn't a "frame" be represented by a PC,FP pair, instead of only FP?
>
> Indeed, our ABI allows not to allocate space on the stack when entering
> a function if it does not need any space. In the testcase, the incr_a()
> function is very small, and does not require reserving space on the stack.
>
> Thus, $fp has the same value in incr_a() and in do_special_tests(), so
> it's not sufficient to determine the scope of "a" when issuing
> "-var-create a2 $fp a".
>
> Is this a limitation of MI? Am I missing something?
We were just discussing this last week or so in another thread...
Roughly speaking, the entire use of frame addresses in MI needs to be
destroyed. A "frame identifier" should be completely opaque to the MI
client - something that it just receives from GDB, saves, and then
passes back to GDB when it needs to identify a particular frame. IMO,
they should be treated as strings rather than numbers by the client.
Of course, this requires implementation, and no one has yet
volunteered. But that's the Right Solution, I think.
--
Daniel Jacobowitz
CodeSourcery