From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12624 invoked by alias); 31 Jan 2014 14:33:40 -0000 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 Received: (qmail 12615 invoked by uid 89); 31 Jan 2014 14:33:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BL_SPAMCOP_NET,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout28.012.net.il Received: from mtaout28.012.net.il (HELO mtaout28.012.net.il) (80.179.55.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Jan 2014 14:33:37 +0000 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N0900H00S0R0S00@mtaout28.012.net.il> for gdb-patches@sourceware.org; Fri, 31 Jan 2014 16:35:00 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0900B59SIBCW80@mtaout28.012.net.il>; Fri, 31 Jan 2014 16:35:00 +0200 (IST) Date: Fri, 31 Jan 2014 14:33:00 -0000 From: Eli Zaretskii Subject: Re: [Windows/RFA/commit] Deprecate windows-specific dll-symbols command and aliases In-reply-to: <20140131122203.GC4101@adacore.com> To: Joel Brobecker Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83y51w5igt.fsf@gnu.org> References: <1391161706-340-1-git-send-email-brobecker@adacore.com> <834n4k75iu.fsf@gnu.org> <20140131113924.GB4101@adacore.com> <83zjmc5q2i.fsf@gnu.org> <20140131122203.GC4101@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg01086.txt.bz2 > Date: Fri, 31 Jan 2014 16:22:03 +0400 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > | Note that before the debugged program has started execution, no DLLs > | will have been loaded. The easiest way around this problem is simply to > | start the program --- either by setting a breakpoint or letting the > | program run once to completion. It is also possible to force > | @value{GDBN} to load a particular DLL before starting the executable --- > | see the shared library information in @ref{Files}, or the > | @code{dll-symbols} command in @ref{Cygwin Native}. Currently, > | explicitly loading symbols from a DLL with no debugging information will > | cause the symbol names to be duplicated in @value{GDBN}'s lookup table, > | which may adversely affect symbol lookup performance. > > I think that suggesting the loading of the DLL before getting it > actually mapped is a little iffy and that it's much better, IMO, > to ask the user to just run the program the same way we do it > on all other platforms. Doesn't "sharedlibrary" have the same effect as dll-symbols in this scenario? > You can emulate that behavior using the "symbol-file" command, but I > don't think this was the intention of that command and that we > should validate it here. Intention aside, the important question, I think, is whether we really want to discourage such uses of "symbol-file", and if so, why. > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -16919,19 +16919,6 @@ evaluation yields the address of the file's shared object file header. > For this command to work, you must have used @code{symbol-file} or > @code{exec-file} commands in advance. > > -@kindex add-shared-symbol-files > -@kindex assf > -@item add-shared-symbol-files @var{library-file} > -@itemx assf @var{library-file} > -The @code{add-shared-symbol-files} command can currently be used only > -in the Cygwin build of @value{GDBN} on MS-Windows OS, where it is an > -alias for the @code{dll-symbols} command (@pxref{Cygwin Native}). > -@value{GDBN} automatically looks for shared libraries, however if > -@value{GDBN} does not find yours, you can invoke > -@code{add-shared-symbol-files}. It takes one argument: the shared > -library's file name. @code{assf} is a shorthand alias for > -@code{add-shared-symbol-files}. > - > @kindex section > @item section @var{section} @var{addr} > The @code{section} command changes the base address of the named > @@ -19899,11 +19886,6 @@ selector for 32-bit programs and @code{$gs} for 64-bit programs). > @item info dll > This is a Cygwin-specific alias of @code{info shared}. > > -@kindex dll-symbols > -@item dll-symbols > -This command loads symbols from a dll similarly to > -add-sym command but without the need to specify a base address. > - > @kindex set cygwin-exceptions > @cindex debugging the Cygwin DLL > @cindex Cygwin DLL, debugging > @@ -19998,13 +19980,7 @@ describes working with such symbols, known internally to @value{GDBN} as > Note that before the debugged program has started execution, no DLLs > will have been loaded. The easiest way around this problem is simply to > start the program --- either by setting a breakpoint or letting the > -program run once to completion. It is also possible to force > -@value{GDBN} to load a particular DLL before starting the executable --- > -see the shared library information in @ref{Files}, or the > -@code{dll-symbols} command in @ref{Cygwin Native}. Currently, > -explicitly loading symbols from a DLL with no debugging information will > -cause the symbol names to be duplicated in @value{GDBN}'s lookup table, > -which may adversely affect symbol lookup performance. > +program run once to completion. I'm OK with this, provided that we really don't want users to know about this use of "symbol-file". Also, I'd like to hear at least from Chris and/or Corinna, as I don't think I ever used dll-symbols myself. Thanks.