This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [Windows/RFA/commit] Deprecate windows-specific dll-symbols command and aliases
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 31 Jan 2014 16:33:38 +0200
- Subject: Re: [Windows/RFA/commit] Deprecate windows-specific dll-symbols command and aliases
- Authentication-results: sourceware.org; auth=none
- References: <1391161706-340-1-git-send-email-brobecker at adacore dot com> <834n4k75iu dot fsf at gnu dot org> <20140131113924 dot GB4101 at adacore dot com> <83zjmc5q2i dot fsf at gnu dot org> <20140131122203 dot GC4101 at adacore dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 31 Jan 2014 16:22:03 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 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.