Re: [RFC] Prints the frame id when target stops

[Denis PILAT <denis.pilat@st.com>]

Jim Blandy wrote:
> Frederic RISS <frederic.riss@st.com> writes:
>   
>>> I suspect you can only do this in stepi, really - step/next can end up
>>> in strange places...
>>>       
>> ... and end up in a frame with the same frame id? Seems unlikely, but
>> then GDB isn't the place where you'd want to trade accuracy for a very
>> small speedup.
>>     
>
> Yeah --- I'd be very concerned about GDB performance optimizations
> that would cause GDB to not notice, say, corruptions of the stack by
> buffer overruns.
>
> If it's common for memory reads to be so expensive, you should buy a
> better JTAG unit^W^W^W^W^W^W^W I'd rather we work on minimizing memory
> accesses by unwinders than make assumptions which may not hold in
> buggy programs.
>
> Could you enable 'debug remote' while it's doing the unwinding, and
> figure out what it's actually fetching?
>
>   
Our configuration does not use remote protocol, but our own protocol.
If we talk about enhancing memory access, yes we'll try to reduce the 
number of memory accesses done by our unwinders, Fred is working on that.
 
As there is no consensus to modify the -stack-list-frames to perform 
cache in a safe way, putting the frame_id (like discussed before) in the 
MI output allows the front end to make a compromise that isn't possible 
in GDB, and for some cases, the front end will be able to not get the 
stack list frame at all.

-- 
Denis