Re: GDB 7.5: Problems with the auto-load safe-path feature

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

Hi Eli,

On Sat, 18 Aug 2012 14:32:19 +0200, Eli Zaretskii wrote:
> First, on MS-Windows the file gdb/gdb-gdb.gdb is not loaded, because
> GDB wants it to be named gdb.exe-gdb.gdb.  I think the .exe suffix
> should be ignored in this case, so I suggest the patch below.  OK to
> commit?

Should it be really host type macro?  Isn't it more a bug gdb/gdb-gdb.gdb is
created instead of gdb/gdb.exe-gdb.gdb?  Is something like this common for
other projects on MS-Windows? (If so how does it behave for UNIX-host
Windows-target cross-projects?)  Just asking if you are already aware of it.


> Next, I have trouble understanding how we are supposed to deal with
> this in, e.g., the Emacs distribution, which comes with a heavily
> customized .gdbinit file.  There seems to be no way of telling GDB
> that this .gdbinit is safe, except (a) through command-line arguments,
> or (b) by adding settings to global or user-private init files.

Yes, choose either (a) or (b).  I choose add-auto-load-safe-path in ~/.gdbinit
myself (for my gdb src directory), TIMTOWTDI.


> How can other projects allow seamless loading of their GDB init files, in
> a way that is compatible with previous GDB versions, and without requiring
> each user to hack their global/private GDB init files?

That's the goal of the safe-path feature, so that there is really no way how
a malicious extracted directory can hijack user's GDB.


> This new feature in GDB 7.5 looks like a nuisance in my (short)
> experience.

Yes, secure behavior is always a pain compared to insecure behavior.
(Such a general note: The whole insecure security companies industry has been
created for the insecure binaries execution common on MS-Windows.)


> Another problem is that the error message displayed when GDB rejects
> to auto-load a file, viz.:
> 
>    warning: File "D:\gnu\bzr\emacs\trunk\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> 
> leaves it to the user to find out where are those safe directories.

The 'auto-load safe-path' is the key there, I expected this will guide the
user to use '(help)? (set|show) auto-load safe-path' commands.  In practice
I have seen for many times it does not, I have no better idea for it.


> Is there an easy way of displaying $datadir and $debugdir?

This is offtopic, you should set safe-path, neither $datadir nor $debugdir.


> Trying the obvious, I get:
> 
>   (gdb) p $datadir
>   $1 = void
> 
> Is that a bug?

No.

> For $datadir, I can do this:
> 
>   (gdb) show data-directory
>   GDB's data directory is "d:\usr\share\gdb".
> 
> But for $debugdir, there's no "show debug-directory"; instead I need
> to do this:
> 
>   (gdb) show debug-file-directory
>   The directory where separate debug symbols are searched for is "d:\usr\lib\debug".

Both variables are well documented in the GDB Manual, you have reviewed it.


> and the description does not make me sure this is the right directory,
> since it does not mention anything about scripts.  At the very least,
> we should fix the description to mention the scripts.

Offtopic, see above.


> Finally, "apropos director" reveals another problem:
> 
>   (gdb) apropos director
>   [...]
>   info auto-load local-gdbinit -- Print whether current directory
>   [...]
>   set auto-load local-gdbinit -- Enable or disable auto-loading of
>   [...]
>   show auto-load local-gdbinit -- Show whether auto-loading
> 
> These truncated descriptions are caused by using ".gdbinit" in the
> first line of the doc string.  To fix this, we should either use "GDB
> init" instead of .gdbinit, or remove the code that stops on the first
> period or comma altogether.

OK, thanks for the report, I do not use 'apropos'.

The patch below will make this change, are you OK with it?

-info auto-load local-gdbinit -- Print whether current directory
+info auto-load local-gdbinit -- Print whether current directory .gdbinit file has been loaded
-set auto-load local-gdbinit -- Enable or disable auto-loading of 
+set auto-load local-gdbinit -- Enable or disable auto-loading of .gdbinit script in current directory
-set print inferior-events -- Set printing of inferior events (e
+set print inferior-events -- Set printing of inferior events (e.g.
-show auto-load local-gdbinit -- Show whether auto-loading 
+show auto-load local-gdbinit -- Show whether auto-loading .gdbinit script in current directory is enabled
-show print inferior-events -- Show printing of inferior events (e
+show print inferior-events -- Show printing of inferior events (e.g.


> --- gdb/auto-load.c~	2012-07-02 13:57:33.000000000 +0300
> +++ gdb/auto-load.c	2012-08-18 13:54:33.578125000 +0300
> @@ -708,6 +708,20 @@ auto_load_objfile_script (struct objfile
>  
>    realname = gdb_realpath (objfile->name);
>    len = strlen (realname);
> +#if defined (__MSDOS__) || defined(__MINGW32__)

There should be whitespace after second 'defined'.


BTW sorry for this note but 7.5 had a long pre-release time to catch these
issues you are reporting.


Thanks,
Jan


2012-08-18  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* cli/cli-decode.c (print_doc_line): Keep skipping '.' and ',' not
	followed by a whitespace.

diff --git a/gdb/cli/cli-decode.c b/gdb/cli/cli-decode.c
index 3c2e152..4752a82 100644
--- a/gdb/cli/cli-decode.c
+++ b/gdb/cli/cli-decode.c
@@ -1068,8 +1068,11 @@ print_doc_line (struct ui_file *stream, char *str)
       line_buffer = (char *) xmalloc (line_size);
     }
 
+  /* Keep printing '.' or ',' not followed by a whitespace for embedded strings
+     like '.gdbinit'.  */
   p = str;
-  while (*p && *p != '\n' && *p != '.' && *p != ',')
+  while (*p && *p != '\n'
+	 && ((*p != '.' && *p != ',') || (p[1] && !isspace (p[1]))))
     p++;
   if (p - str > line_size - 1)
     {