From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18679 invoked by alias); 16 Aug 2002 13:50:10 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18670 invoked from network); 16 Aug 2002 13:50:09 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 16 Aug 2002 13:50:09 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3BC513C03; Fri, 16 Aug 2002 09:50:07 -0400 (EDT) Message-ID: <3D5D030F.4050409@ges.redhat.com> Date: Fri, 16 Aug 2002 06:50:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos O'Donell Cc: gdb@sources.redhat.com Subject: Re: Issue an internal warning on first deprecated function call References: <3D5C248D.4030003@ges.redhat.com> <1020815223303.ZM7495@localhost.localdomain> <20020816133012.GC11845@systemhalted> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00182.txt.bz2 > A variation on the above idea is to scan a newly created gdbarch >> struct to see if any deprecated functions are being used. If so, >> print only one message per session. (I.e, instead of seeing N >> messages from N deprecated function, you'd only see one message for >> the whole lot.) The nuisance factor could be cut back even further if >> we arrange for .gdbinit setting which can be used to disable such >> messages. > > > I like the 'once per session' idea. > Can we make the that message a rather largish banner? My intent is for it to use ``internal-warning'' which means it will look something like this: (gdb) maint internal-error /home/scratch/GDB/src/gdb/maint.c:121: gdb-internal-error: internal maintenance An internal GDB error was detected. This may make further debugging unreliable. Quit this debugging session? (y or n) n Create a core file containing the current state of GDB? (y or n) n (gdb) s/error/warning/ Since the user is going to need to interact with this, they will get very annoyed with it pretty quick. This is why I'm also proposing another command for gaging it :-) I think ``internal-warning'' is correct since there is a very very good chance that the deprecated interface will have been [unintentionally] broken by the introduction of the new mechanisms. Andrew