From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14418 invoked by alias); 16 Apr 2010 21:25:58 -0000 Received: (qmail 14402 invoked by uid 22791); 16 Apr 2010 21:25:57 -0000 X-SWARE-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_05,SPF_SOFTFAIL,TW_CP X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Apr 2010 21:25:52 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L0Z00D00NBHXD00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Sat, 17 Apr 2010 00:25:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.69.249]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L0Z00B5DNHOMK70@a-mtaout20.012.net.il>; Sat, 17 Apr 2010 00:25:01 +0300 (IDT) Date: Fri, 16 Apr 2010 21:25:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] [1/2] auto-loading scripts from .debug_gdb_scripts section In-reply-to: To: Doug Evans Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83bpdjccpc.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <20100416070540.4205E84396@ruffy.mtv.corp.google.com> <83tyrbwxex.fsf@gnu.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00521.txt.bz2 > Date: Fri, 16 Apr 2010 11:06:44 -0700 > From: Doug Evans > Cc: gdb-patches@sourceware.org > > > The existing Python Auto-loading section is not too long, so how about > > simply adding the description of this new feature to that section?  I > > think ripping it out of "Python API" is not a good idea. > > To me the Auto-loading section is not really part of the API. Well, yes, but this feature is currently specific to Python, so why move it out of the Python chapter? > >> +If this file does not exist, and if the parameter > >> +@code{debug-file-directory} is set (@pxref{Separate Debug Files}), > >> +then @value{GDBN} will use for its each separated directory component > >> +@code{component} the file named @file{@code{component}/@var{real-name}}, where > >> +@var{real-name} is the object file's real name, as described above. > > > > I know you just copied this from the original text, but this is > > confusingly complicated.  How about this rewording: > > > >  If this file does not exist, and if the parameter > >  @code{debug-file-directory} is set (@pxref{Separate Debug Files}), > >  then @value{GDBN} will look for the file in that directory and in > >  all of its parents. > > "all of its parents"? > I *think* that comment is referring to the fact that > "debug-file-directory" contains a colon-separated list of directories > to try Right you are. So If this file does not exist, and if the parameter @code{debug-file-directory} is set (@pxref{Separate Debug Files}), then @value{GDBN} will look for the file in all of the directories mentioned in the value of @code{debug-file-directory}. > bad option name of course A terrible name. > >> +  if (!input && debug_file_directory) > >> +    { > >> +      /* Also try the same file in the separate debug info directory.  */ > >> +      debugfile = xmalloc (strlen (filename) > >> +                        + strlen (debug_file_directory) + 1); > >> +      strcpy (debugfile, debug_file_directory); > >> +      /* FILENAME is absolute, so we don't need a "/" here.  */ > >> +      strcat (debugfile, filename); > > > > What will that last strcat do if FILENAME has a drive letter? > > > >> +      strcpy (debugfile, gdb_datadir); > >> +      strcat (debugfile, "/auto-load"); > >> +      /* FILENAME is absolute, so we don't need a "/" here.  */ > >> +      strcat (debugfile, filename); > > > > Ditto. > > This is cut-n-pasted from the existing code to auto-load -gdb.py > scripts. I don't know if filename can have a drive letter here. Yes, it can. It depends how the files were called out in the compilation command line. I think we should strip the drive letter and the colon before concatenating the rest with the leading directory.