Re: Which MI behavior is correct ?

[Maxim Grigoriev <maxim@tensilica.com>]

Hi Nick and Daniel,

You're right. It's an Xtensa-specific difference in the MI behavior.

I built native GNU Linux-X86 gdb from the top of the FSF tree, and it's
consistent with anything else but GNU Xtensa gdb.

I have to fix Xtensa gdb. When I implemented frame ID Xtensa functions
I followed an advice from GDB expert(s) and choose

    - physical Return Address of the current frame and
    - Stack Pointer of the previous frame

to identify frames.

So there is probably nothing wrong about this choice. It's supposed
to work for MI variable objects as well. Let's see what did I miss.

Thanks much for your valuable inputs on this issue,

-- Maxim

Nick Roberts wrote:
>  >  > Aren't the variables associated with a particular frame ID? I thought
>  >  > we'd decided that it was the right thing to take them out of scope.
>  > 
>  > This seems to be an answer to my question. The behavior has changed
>  > probably since somewhere around 6.3. Now, variable objects are associated
>  > with the frame, not with the function. As you can see in gdb 6.3 case
>  > ( NATIVE.log ), variables "var1" and "var2" were successfully reused,
>  > when new frame was allocated after hitting the breakpoint second time.
>  > In 6.5+ (XTENSA.log), we have to recreate variable objects every time
>  > we have a new frame because the old variables are out of scope.
>
> As I said last time, I get the gdb 6.3 behaviour with FSF GDB 6.5.  In fact
> I can't see how GDB can take the variables out of scope when the stack
> address and code address are the same.
>
>  > Correct ?
>  > 
>  > How about efficiency ? What if we have to create hundreds of variable
>  > objects at every breakpoint hit ?
>  > 
>  > We kept staying with GNU gdb 5.2.1 for too long. So it looks like
>  > we might have missed this important change, which is already in the
>  > past for the majority of GNU gdb users.
>
> I still think you're barking up the wrong tree.  Can't you test a stock
> GDB 6.5 somewhere to see which behaviour you get?  If it has changed can
> you identify when it did from the ChangeLog?
>
>