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

[Joel Brobecker <brobecker at adacore dot com>]

> > Thanks! I was planning on removing the command from gdb.texinfo
> > when it is actually deleted. But I can certainly do it now too!
> > If no one else comments on it, I'll go with your suggestion of
> > removing it now.
> 
> I think we shouldn't advertise deprecated features.

Sure.

Upon grep'ing the manual, I found the following paragraph which
promotes a rather peculiar use of the command:

| 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. 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.

With that in mind, and since I was almost done with the change,
if finished it with the assumption that this was going to be
an acceptable loss of functionality, I still went ahead with
the doco update. If people feel that this is not acceptable, then
my patch should be dropped, and I think the documentation should
be clarified about the dll-symbols command intended usage and
limitations (whoever opposed the removal can do it!?! ;-)).

gdb/ChangeLog:

        * windows-nat.c (_initialize_windows_nat): Deprecate the
        "dll-symbols" command.  Turn the "add-shared-symbol-files"
        and "assf" aliases into commands, and deprecate them as well.
        * NEWS: Add entry explaining that "dll-symbols" and its two
        aliases are now deprecated.

gdb/doc/ChangeLog:

        * gdb.texinfo (Files): Remove documentation of commands
        "add-shared-symbol-files" and "assf".
        (Cygwin Native): Remove documentation of the "dll-symbols"
        command.
        (Non-debug DLL Symbols): Remove reference to "dll-symbols"
        as a way to force the loading of symbols from a DLL.

-- 
Joel

>From b21076d3544ac896573a4a51fa2950acca07c949 Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Fri, 31 Jan 2014 04:22:53 -0500
Subject: [PATCH] Deprecate windows-specific dll-symbols command and aliases

The "dll-symbols" command, specific to native Windows platforms,
gives the impression that the symbols were not loaded, first
because it completes silently, and second because the "info shared"
output does not get updated after the command completes:

    (gdb) dll-symbols C:\WINDOWS\syswow64\rpcrt4.dll
    (gdb) info shared
    From        To          Syms Read   Shared Object Library
    [...]
    0x77e51000  0x77ee2554  No          C:\WINDOWS\system32\rpcrt4.dll

(we exected the "Syms Read" column to read "Yes").

As far as I can tell, the symbols actually do get loaded, but completely
independently from the solib framework, which explains the silent
loading and the fact that the "Syms Read" column does not get updated.
See windows-nat.c::safe_symbol_file_add_stub, which calls symbol_file_add
instead of calling solib_add.

But, aside from the fact that the "Syms Read" status does not get
updated, I also noticed that it does not take into account the DLL's
actual load address when loading its symbols. As a result, I believe
that we get it wrong if the DLL does not get loaded at the prefered
address.

Rather than trying to fix this command, there does not seem to be
a reason other than historical for having Windows-specific commands
which essentially re-implements the "sharedlibrary" command. The
command interface is slightly different (the latter takes a regexp
rather than a plain filename), but it should be just as easy to use
the "sharedlibrary" command, or its "share" alias, as usisng the
"dll-symbols" command. For instance:

    (gdb) share rpcrt4.dll
    Reading symbols from C:\WINDOWS\system32\rpcrt4.dll...(no debugging symbols found)...done.
    Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
    (gdb) info shared
    From        To          Syms Read   Shared Object Library
    [...]
    0x77e51000  0x77ee2554  Yes (*)     C:\WINDOWS\system32\rpcrt4.dll

This patch therefore deprecates the "dll-symbols" command, as well
as its two aliases "add-shared-symbol-files" and "assf", with a view
of deleting them as soon as the 7.8 branch gets cut.

gdb/ChangeLog:

	* windows-nat.c (_initialize_windows_nat): Deprecate the
	"dll-symbols" command.  Turn the "add-shared-symbol-files"
	and "assf" aliases into commands, and deprecate them as well.
	* NEWS: Add entry explaining that "dll-symbols" and its two
	aliases are now deprecated.

gdb/doc/ChangeLog:

        * gdb.texinfo (Files): Remove documentation of commands
        "add-shared-symbol-files" and "assf".
        (Cygwin Native): Remove documentation of the "dll-symbols"
        command.
        (Non-debug DLL Symbols): Remove reference to "dll-symbols"
        as a way to force the loading of symbols from a DLL.
---
 gdb/NEWS            |  4 ++++
 gdb/doc/gdb.texinfo | 26 +-------------------------
 gdb/windows-nat.c   | 13 +++++++++----
 3 files changed, 14 insertions(+), 29 deletions(-)

diff --git a/gdb/NEWS b/gdb/NEWS
index 5062e02..14af602 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -51,6 +51,10 @@ qXfer:btrace:read's annex
   The qXfer:btrace:read packet supports a new annex 'delta' to read
   branch trace incrementally.
 
+* The "dll-symbols" command, and its two aliases ("add-shared-symbol-files"
+  and "assf"), have been deprecated.  Use the "sharedlibrary" command, or
+  its alias "share", instead.
+
 *** Changes in GDB 7.7
 
 * Improved support for process record-replay and reverse debugging on
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index af14286..4f84318 100644
--- 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.
 
 @subsubsection DLL Name Prefixes
 
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 5bcb7b7..68a567b 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -2666,12 +2666,17 @@ _initialize_windows_nat (void)
   c = add_com ("dll-symbols", class_files, dll_symbol_command,
 	       _("Load dll library symbols from FILE."));
   set_cmd_completer (c, filename_completer);
+  deprecate_cmd (c, "sharedlibrary");
 
-  add_com_alias ("sharedlibrary", "dll-symbols", class_alias, 1);
-
-  add_com_alias ("add-shared-symbol-files", "dll-symbols", class_alias, 1);
+  c = add_com ("add-shared-symbol-files", class_files, dll_symbol_command,
+	       _("Load dll library symbols from FILE."));
+  set_cmd_completer (c, filename_completer);
+  deprecate_cmd (c, "sharedlibrary");
 
-  add_com_alias ("assf", "dll-symbols", class_alias, 1);
+  c = add_com ("assf", class_files, dll_symbol_command,
+	       _("Load dll library symbols from FILE."));
+  set_cmd_completer (c, filename_completer);
+  deprecate_cmd (c, "sharedlibrary");
 
 #ifdef __CYGWIN__
   add_setshow_boolean_cmd ("shell", class_support, &useshell, _("\
-- 
1.8.3.2