From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9699 invoked by alias); 31 Jul 2014 06:55:37 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 9677 invoked by uid 89); 31 Jul 2014 06:55:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f174.google.com Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com) (74.125.82.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 31 Jul 2014 06:55:35 +0000 Received: by mail-we0-f174.google.com with SMTP id x48so2295496wes.33 for ; Wed, 30 Jul 2014 23:55:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.6.134 with SMTP id b6mr14186108wja.64.1406789732029; Wed, 30 Jul 2014 23:55:32 -0700 (PDT) Received: by 10.216.245.137 with HTTP; Wed, 30 Jul 2014 23:55:31 -0700 (PDT) In-Reply-To: <87ppgyscy8.fsf@fleche.redhat.com> References: <87ppgyscy8.fsf@fleche.redhat.com> Date: Thu, 31 Jul 2014 06:55:00 -0000 Message-ID: Subject: Re: deprecated_print_frame_info_listing_hook From: phi gcc To: Tom Tromey Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00036.txt.bz2 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