From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49783 invoked by alias); 15 Aug 2018 08:09:42 -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 49768 invoked by uid 89); 15 Aug 2018 08:09:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay.fit.cvut.cz Received: from relay.fit.cvut.cz (HELO relay.fit.cvut.cz) (147.32.232.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Aug 2018 08:09:38 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [147.32.232.238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id w7F89XIA011217 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 15 Aug 2018 10:09:35 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Received: from sao (5ac693bc.bb.sky.com [90.198.147.188] (may be forged)) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id w7F89VKw035208 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 15 Aug 2018 10:09:32 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: <9076c35bc9e738f86edd401c6570955faf9565af.camel@fit.cvut.cz> Subject: Re: Script autoloading From: Jan Vrany To: Tom Tromey Cc: "gdb@sourceware.org" Date: Wed, 15 Aug 2018 08:09:00 -0000 In-Reply-To: <87pnysapi8.fsf@tromey.com> References: <533925d3833ef42651918d147ccde1b6a953375b.camel@fit.cvut.cz> <87pnysapi8.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00030.txt.bz2 On Wed, 2018-08-08 at 08:42 -0600, Tom Tromey wrote: > > > > > > "Jan" == Jan Vrany writes: > > Jan> However, I struggle to make this working also on Windows, where the > Jan> library is named "librun.dll", not "librun.so'. > > Jan> I thought I'd use .debug_gdb_scripts section as described in > Jan> GDB manual, but this does not work very good since $cdir is > Jan> not searched in that case. > > Jan> Any idea how to make it working on both, Linux and Windows with > Jan> no additional setup (other than autoload-safe path)? What's is the > Jan> rationale for excluding $cdir from source directories when searching > Jan> for scipts? > > I don't know why $cdir isn't searched, other than what the manual says: > > If the entry specifies a file, GDB will look for the file first in the > current directory and then along the source search path (*note > Specifying Source Directories: Source Path.), except that '$cdir' is not > searched, since the compilation directory is not relevant to scripts. > > This doesn't really explain it to me, though, since the compilation > directory is used to find sources. I was thinking exactly that when I read it. > > Why can't you just rename the file at install time, depending on what > the library is called? It seems like your build system is already doing > that for the library itself. The build system does not rename the library itself, on Linux (*BSD) the compilation produces librun.so, on windows librun.dll. I can indeed rename it during build, but this is bit awkward for development (for deployment it's just fine). The problem is that if on Windows I rename it, I'd have two different files (librun.so-gdb.py and librun.dll-gdb.py) with same contents (this is not a problem). When developing debugging scripts, I'd have to edit the latter (librun.dll-gdb.py) and then *not to forget* to copy changes back and commit. Moreover, this copied librun.dll-gdb.py would either always show up in "git status" as a new file or - if I add it to .gitignore, - won't show up at all which would make it more likely that I'd forgot to copy changes back an commit. As you see, it's doable for sure but rather inconvenient. Adding $cdir would solve this problem. The documentation also says: For object files using .exe suffix GDB tries to load first the scripts normally according to its .exe filename. But if no scripts are found GDB also tries script filenames matching the object file without its .exe suffix. This .exe stripping is case insensitive and it is attempted on any platform. This makes the script filenames compatible between Unix and MS-Windows hosts. Maybe we can have similar automagic for .so / .dll / .dylib extensions. I'm ready to write a patch and submit it, unless there's a reason for current behavior. Jan > > Tom