Re: deprecated_print_frame_info_listing_hook

[phi gcc <phi dot gcc at gmail dot com>]

Hi Tom,

Sorry for the reply delay, I was on vacations.

I use my own gdb hack, basically I use an HPTERM as terminal. HPTERM
has a very anciant feature called "memory lock". In a nuttshell, it
allow to display things on the top end of the display, drow a line at
a given line number (starting form top) locking the top of the
display, then all subsequent output are flowing in the lower part of
the terminal.

This feature was extensivly used by old debuggers like XDB, or
DEBUG/1000 ( a 16 bit machine).

I made a hack in GDB to do the same on HPTERM, so I have my own kind
of TUI. When GDB gets the control, I can figure out what src line we
stoped on, my pretty printer evaluate if the line we are stoped on is
displayed already, just placing the '>' marker on the line, if
completly new source must be displayed (or scrolled) I redisplay the
source, and indeed set the memory lock on the display.

This mean that when target is run, it can use all the output flow with
out destroying the top source display.

The actual TUI with ncurse can't even come close to this in term of
perf and fluidity of display. On slow line the memorylock is a big
saver, and it is still a very light wait protocol, I would say it is a
green protocol :)

Now one could say we don't have HPTERM on linux, well I got my own
hybrid xterm, one that reconise the vt100 escape sequence and identify
itself as vt100 for common work on linux vt100, but as more escape
sequence, like an additional identify that reply it is an hybrid vt100
+ hpterm, then accept the hpterm sequence, and then I implemented the
memory lock.

Another way to get an HPTERM is to work on HPUX systems :)

My GDB hack via identify escape sequance can figure out if it run on
pure HPTERM, hybrid VT100+HPTERM, or pure vt100, in the later it
reject the run and say go use the std GDB .

So basically I port my hacks to GDB each time a new GDB is needed with
a given linux version, i.e as long as *trace() are compatible I work
with the current hack 'old' gdb, when incompatibilites occurs it is
time forward port my hacks, and most of the time it is smooth...

Until C++ come into the dance, I fear I will have to keep an old GDB
fork from there, and adpat to new linux as it come.

And indeed, I depend on deprecated_print_frame_info_listing_hook() not
that much though because when it disapear, I can simply hook my code
in the right place instead of using GDB infrastructure to register
functions.

That was my question, will it be removed ? the answer can be 'wait and see'  :)


Cheers,
Phi