This is the mail archive of the gdb-patches@sourceware.org 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] Prints the frame id when target stops


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


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