Re: [Windows/RFA/commit] Deprecate windows-specific dll-symbols command and aliases

[Eli Zaretskii <eliz@gnu.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.