This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB 7.5: Problems with the auto-load safe-path feature
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 18 Aug 2012 15:21:28 +0200
- Subject: Re: GDB 7.5: Problems with the auto-load safe-path feature
- References: <83d32ogz3g.fsf@gnu.org>
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)
{