From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11316 invoked by alias); 17 Feb 2004 20:02:08 -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 11298 invoked from network); 17 Feb 2004 20:02:06 -0000 Received: from unknown (HELO lakemtao01.cox.net) (68.1.17.244) by sources.redhat.com with SMTP; 17 Feb 2004 20:02:06 -0000 Received: from white ([68.9.64.121]) by lakemtao01.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040217200206.ZLRE13731.lakemtao01.cox.net@white> for ; Tue, 17 Feb 2004 15:02:06 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1AtBPx-0001dD-00 for ; Tue, 17 Feb 2004 15:02:05 -0500 Date: Tue, 17 Feb 2004 20:02:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: Re: [MI] -file-list-exec-source-files Message-ID: <20040217200205.GC5982@white> Mail-Followup-To: gdb@sources.redhat.com References: <20040216034525.GA3437@white> <20040216034930.GA29864@nevyn.them.org> <20040216153329.GA3978@white> <20040216154628.GA996@nevyn.them.org> <20040216160835.GB3978@white> <40325BC5.4090403@gnu.org> <20040217191005.GA5982@white> <20040217191238.GA30895@nevyn.them.org> <20040217193001.GB5982@white> <40326FEB.8050409@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40326FEB.8050409@gnu.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-02/txt/msg00205.txt.bz2 On Tue, Feb 17, 2004 at 02:47:55PM -0500, Andrew Cagney wrote: > >On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote: > > > >>On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote: > > > >>> I have one last question that didn't get answered, could the psymtab be > >>> modified to contain the dirname? > > > >> > >>Probably, but the dirname -> fullname conversion may be expensive - it > >>involves a lot of stat() calls. > > > > As a first cut, don't worry about performance (or more correctly > scaleability). Just correctness (especially of the symtab interface). Ok. > > >2. -file-list-exec-fetch-fullname [filename] > > > > This will be a new MI command. > > > > This will return a fullname given a filename. > > If the symtab is read in, it calls source.c:symtab_to_filename. > > If the symtab is not read in, it reads it in and calls the above > > function. > > > > This function is necessary because all of the other MI commands still > > output just the filename and not the fullname. For example, breakpoints, > > stack, ... Yes, I guess it's a bug. However, these commands have never returned the fullname. Here you are making a big change to the way GDB deals with front ends. You are saying that GDB should only let the front end know about fullnames, and know nothing about filenames. I consider this desirable as a front end writer, since the fullname is the only valid unique key to a front end. It would be nice if I could do this in 2 phase's. First add this function, for backwards compatibility, and then, change all the existing commands to return fullnames. Although, leaving this function around, doesn't hurt anything. > >3. -file-list-exec-source-files [force_fullnames] > > > > This will implement an existing unimplemented MI command. > > > > By default, this will return > > 1. filename for each psymtab, with no fullname > > 2. filename/fullname for each symtab > > > > If the option "force_fullnames" is passed, it will have GDB convert all > > of the psymtabs to symtabs, thus printing out the filename/fullname for > > all symtabs. The overhead of doing this is probably high, and > > undesirable by default. > > > > If the front end wants to be more efficient, it could show the user the > > "filenames" and then do the "fullname" lookup just on that file. Thus, > > only reading in one symtab. > > This specification is too heavily dependent on GDB's current underlying > implementation - symtab and psymtab are internal details and do not > belong in this interface specification. I was just showing how this interface is affected by GDB's implementation of psymtab/symtab. The user will have no idea of these 2 concepts. Anyways, if I can get the dirname into psymtab, this will no longer be an issue. The user will always get the filename/fullname combo. With that said, do you like the implementation? Thanks, Bob Rossi