deprecated_print_frame_info_listing_hook

deprecated_print_frame_info_listing_hook

[phi gcc]

Hi All,

This is my first post in this ML, if it is not the right place let me
know and I will register another list.

I have my own hack on gdb since ages, that I port to each new broken
gdb, I mean each time GDB become incompatible with my updated linux, I
get the latest GDB and incorporate my few hacks in there. (this may
happen when [pt]trace change its API)

Today I got from ubuntu LTS 14.04, and my old GDB (6.4) don't work
anymore. That's ok I get the latest GDB for that ubuntu 14.04 and it
sounds like it is gdb-7.7, I port my hack in there and kaboom, my hack
don't port because I heavily depend on
print_frame_info_listing_hook() to be called upon GDB interaction.

I discover that this print_frame_info_listing_hook() is deprecated (thanx).

My question is, what is the replacement for that, what is the right
place to stick a callback to my function when we hit a BP and enter
GDB loop?

Thanx in advance
Cheers,
Phi

Re: deprecated_print_frame_info_listing_hook

[phi gcc]

Hi All,
Forget my prev mail, I figured I forgot to setup
deprecated_print_frame_info_listing_hook that is still there.

That raise another question, will it disapear one day ?

Cheers,
Phi



On Sun, Jul 20, 2014 at 10:46 AM, phi gcc <phi.gcc@gmail.com> wrote:
> Hi All,
>
> This is my first post in this ML, if it is not the right place let me
> know and I will register another list.
>
> I have my own hack on gdb since ages, that I port to each new broken
> gdb, I mean each time GDB become incompatible with my updated linux, I
> get the latest GDB and incorporate my few hacks in there. (this may
> happen when [pt]trace change its API)
>
> Today I got from ubuntu LTS 14.04, and my old GDB (6.4) don't work
> anymore. That's ok I get the latest GDB for that ubuntu 14.04 and it
> sounds like it is gdb-7.7, I port my hack in there and kaboom, my hack
> don't port because I heavily depend on
> print_frame_info_listing_hook() to be called upon GDB interaction.
>
> I discover that this print_frame_info_listing_hook() is deprecated (thanx).
>
> My question is, what is the replacement for that, what is the right
> place to stick a callback to my function when we hit a BP and enter
> GDB loop?
>
> Thanx in advance
> Cheers,
> Phi

Re: deprecated_print_frame_info_listing_hook

[Tom Tromey]

>>>>> "Phi" == phi gcc <phi.gcc@gmail.com> writes:

Phi> Forget my prev mail, I figured I forgot to setup
Phi> deprecated_print_frame_info_listing_hook that is still there.

You never said what your hack is.
That makes it hard to give advice.

Phi> That raise another question, will it disapear one day ?

Probably.

Tom

Re: deprecated_print_frame_info_listing_hook

[phi gcc]

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