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

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

[Eli Zaretskii]

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

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?

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.  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?  (If
there is such a way, it should be prominently described in the GDB
manual.)

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.
Is there an easy way of displaying $datadir and $debugdir?  Trying the
obvious, I get:

  (gdb) p $datadir
  $1 = void

Is that a bug?  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".

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.

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.

Here's the patch I suggest for the first problem described above:

2012-08-18  Eli Zaretskii  <eliz@gnu.org>

	* auto-load.c (auto_load_objfile_script): If OBJFILE specifies a
	DOS/Windows-style .exe executable program, remove the .exe suffix
	when generating the script file name.

--- 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__)
+  /* For Windows/DOS .exe executables, strip the .exe suffix, so that
+     FOO-gdb.gdb could be used for FOO.exe.  */
+  {
+    const size_t lexe = sizeof (".exe") - 1;
+
+    if (len > lexe
+	&& strcasecmp (realname + len - lexe, ".exe") == 0)
+      {
+	len -= lexe;
+	realname[len] = '\0';
+      }
+  }
+#endif
   filename = xmalloc (len + strlen (language->suffix) + 1);
   memcpy (filename, realname, len);
   strcpy (filename + len, language->suffix);

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

[Jan Kratochvil]

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)
     {

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

[Eli Zaretskii]

> Date: Sat, 18 Aug 2012 15:21:28 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> > 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.

Until now, we had .gdbinit files, which worked on Unix and Windows
alike.  Isn't it true that we now encourage migration from .gdbinit to
FOO-gdb.gdb files?  If so, the issue gets introduced now that didn't
exist before.

But even if .gdbinit files are to stay, and FOO-gdb.gdb are in
addition to them, my point is still valid, IMO: this file might be
coming with the source distribution, not being generated at build
time.  In that case, omitting the .exe suffix will allow the file to
be used on any platform, not just on Unix.  I think this is better.

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

But that is not backward-compatible to older GDB versions, is it?
Here's what I get with GDB 7.4.1:

  D:\usr\eli/.gdbinit:1: Error in sourced command file:
  "on" or "off" expected.

This is with ~/.gdbinit which says just this:

  set auto-load safe-path /

That's why I asked about a backward-compatible way: it's not
inconceivable that someone would have several GDB versions on the same
machine.  And GDB auto-loaded files distributed with other projects
may wish to be compatible to several GDB versions.

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

I'd hope we could find a better balance between preventing malicious
attacks and punishing legitimate uses.  But I digress.

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

It did guide there.  But that didn't help, either:

  (gdb) show auto-load safe-path
  List of directories from which it is safe to auto-load files is $debugdir:$datadir/auto-load.

That's why I wanted to find out what is $debugdir, see below.

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

There's nothing wrong with the manual.  My problem was with
discoverability of these variables's values from within GDB.  When I
was presented with an opaque $debugdir, I wanted to know how close
that was to the source or build directory, thinking that perhaps this
is some misconfiguration issue, or maybe even (gasp!) a bug specific
to MS-Windows.

How about if we show the variable values explicitly in the warning
message, instead of using variables whose values cannot be easily
displayed?

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

??? How so?  The full doc string of "auto-load safe-path" still
doesn't mention scripts:

  (gdb) help set auto-load safe-path
  Set the list of directories from which it is safe to auto-load files.
  Various files loaded automatically for the 'set auto-load ...' options must
  be located in one of the directories listed by this option.  Warning will be
  printed and file will not be used otherwise.
  Setting this parameter to an empty list resets it to its default value.
  Setting this parameter to '/' (without the quotes) allows any file
  for the 'set auto-load ...' options.  Each directory can be also shell
  wildcard pattern; '*' does not match directory separator.
  This option is ignored for the kinds of files having 'set auto-load ... off'.
  This options has security implications for untrusted inferiors.


> >   (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?

Yes, thanks.

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

There's a limit to how many projects one can pretest, and still do
something useful during the day (assuming GDB maintenance is not what
you get your paycheck for).  I'm heavily invested in Emacs, and am
practically the only person who deals with Windows pretests of Make
and Gawk.  Since there are a couple of people who obviously track the
GDB development on MS-Windows (they tend to report regressions on
trunk within days of their introduction), I hoped any such issues in
GDB will be caught by them, to say nothing of the people who use CVS
versions on Unix, and should have seen these issues a long time ago.

I'm open to ideas how to help make our pre-release testing better, but
that must be a collective effort, it cannot be blamed on a single
person, even if that person is me.  E.g., perhaps we should require at
least one positive success report on each supported platform, or at
least on the more popular ones, before we announce the pre-release a
success and go for the release.

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

[Joel Brobecker]

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

Same here. Very very much agreed, in fact. But I don't feel we have
much of a leg to stand on, when opposing the feature. Jan and I
discussed this feature quite a bit, as I recall, and came to the best
compromise we could. For your own personal purposes, you can turn
this feature off by default when configuring GDB. I think that
the configure option is: --without-auto-load-safe-path

> 2012-08-18  Eli Zaretskii  <eliz@gnu.org>
> 
> 	* auto-load.c (auto_load_objfile_script): If OBJFILE specifies a
> 	DOS/Windows-style .exe executable program, remove the .exe suffix
> 	when generating the script file name.

I think that the test should ideally be target-dependent. But short of
that, how about we just try without the .exe prefix if the first attempt
failed, regardless of host and/or target?

In other words:

   1. Try loading <filename>-gdb.gdb
   2. If (1) fails, and <filename> ends with '.exe':
      Try loading <filename-minus-exe>-gdb.gdb

That way, if you are cross-building a Windows GDB on GNU/Linux, and
try to debug it from GNU/Linux as well, the Linux-to-Windows cross GDB
would be able to pickup the gdb-gdb.gdb file automatically.

-- 
Joel

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

[Joel Brobecker]

> > BTW sorry for this note but 7.5 had a long pre-release time to catch these
> > issues you are reporting.
> 
> There's a limit to how many projects one can pretest, and still do
> something useful during the day (assuming GDB maintenance is not what
> you get your paycheck for).

I think that's a fair comment. On the other hand, there are always
going to be things tested by others that you might disagree with,
as is the case here. In any case, we have the option of making
a minor/corrective release, if it makes sense.

> I'm open to ideas how to help make our pre-release testing better

I usually make pre-release packages and then wait for a minimum
of 2 weeks before producing the official release. If you'd like,
you can build and install them the same way you would for the first
release. If all goes well, the first official release could be
your first corrective release...

-- 
Joel

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

[Eli Zaretskii]

> Date: Sat, 18 Aug 2012 09:10:49 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > This new feature in GDB 7.5 looks like a nuisance in my (short)
> > experience.
> 
> Same here. Very very much agreed, in fact. But I don't feel we have
> much of a leg to stand on, when opposing the feature. Jan and I
> discussed this feature quite a bit, as I recall, and came to the best
> compromise we could.

Let's see what the users at large say about this.

> For your own personal purposes, you can turn this feature off by
> default when configuring GDB. I think that the configure option is:
> --without-auto-load-safe-path

It's easier to do that in ~/.gdbinit.

> > 2012-08-18  Eli Zaretskii  <eliz@gnu.org>
> > 
> > 	* auto-load.c (auto_load_objfile_script): If OBJFILE specifies a
> > 	DOS/Windows-style .exe executable program, remove the .exe suffix
> > 	when generating the script file name.
> 
> I think that the test should ideally be target-dependent. But short of
> that, how about we just try without the .exe prefix if the first attempt
> failed, regardless of host and/or target?

Like in the patch below?  I can drop the #ifdef, if no one objects (it
could surprise Unix users who call their programs FOO.exe for some
reason).

--- gdb/auto-load.c~	2012-08-18 15:47:48.953125000 +0300
+++ gdb/auto-load.c	2012-08-18 19:44:20.859375000 +0300
@@ -708,20 +708,6 @@ auto_load_objfile_script (struct objfile
 
@@ -735,6 +721,29 @@ auto_load_objfile_script (struct objfile
     fprintf_unfiltered (gdb_stdlog, _("auto-load: Attempted file \"%s\" %s.\n"),
 			debugfile, input ? _("exists") : _("does not exist"));
 
+#if defined (__MSDOS__) || defined (__MINGW32__)
+  /* For Windows/DOS .exe executables, strip the .exe suffix, so that
+     FOO-gdb.gdb could be used for FOO.exe, and try again.  */
+  if (!input)
+    {
+      const size_t lexe = sizeof (".exe") - 1;
+
+      if (len > lexe
+	  && strcasecmp (realname + len - lexe, ".exe") == 0)
+	{
+	  len -= lexe;
+	  realname[len] = '\0';
+	  filename = xrealloc (filename, len + strlen (language->suffix) + 1);
+	  memcpy (filename, realname, len);
+	  strcpy (filename + len, language->suffix);
+	  input = fopen (filename, "r");
+	  debugfile = filename;
+	  if (debug_auto_load)
+	    fprintf_unfiltered (gdb_stdlog, _("auto-load: Attempted file \"%s\" %s.\n"),
+				debugfile, input ? _("exists") : _("does not exist"));
+	}
+    }
+#endif
   if (!input)
     {
       VEC (char_ptr) *vec;

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

[Eli Zaretskii]

> Date: Sat, 18 Aug 2012 09:19:25 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb-patches@sourceware.org
> 
> > > BTW sorry for this note but 7.5 had a long pre-release time to catch these
> > > issues you are reporting.
> > 
> > There's a limit to how many projects one can pretest, and still do
> > something useful during the day (assuming GDB maintenance is not what
> > you get your paycheck for).
> 
> I think that's a fair comment. On the other hand, there are always
> going to be things tested by others that you might disagree with,
> as is the case here.

That's life, and I accept that.  I can always patch my own GDB to fix
any such problems.  I only wrote the above in response to Jan's
comment about having ample time to complain about these issues before
the release.

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

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> 2012-08-18  Jan Kratochvil  <jan.kratochvil@redhat.com>
Jan> 	* cli/cli-decode.c (print_doc_line): Keep skipping '.' and ',' not
Jan> 	followed by a whitespace.

This looks reasonable to me.
I vaguely recall that there is a PR open in this area.

Tom

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

[Jan Kratochvil]

On Sat, 18 Aug 2012 19:07:49 +0200, Eli Zaretskii wrote:
> Like in the patch below?  I can drop the #ifdef, if no one objects (it
> could surprise Unix users who call their programs FOO.exe for some
> reason).

Yes, Joel also was for dropping the #ifdef.

Also I believe GDB should test the .exe-less filenames even
in 'set auto-load scripts-directory' entries.

What about the patch below?

Going to run a regression test (but auto-load does not have testcases).


Thanks,
Jan


> --- gdb/auto-load.c~	2012-08-18 15:47:48.953125000 +0300
> +++ gdb/auto-load.c	2012-08-18 19:44:20.859375000 +0300
> @@ -708,20 +708,6 @@ auto_load_objfile_script (struct objfile
>  
> @@ -735,6 +721,29 @@ auto_load_objfile_script (struct objfile
>      fprintf_unfiltered (gdb_stdlog, _("auto-load: Attempted file \"%s\" %s.\n"),
>  			debugfile, input ? _("exists") : _("does not exist"));
>  
> +#if defined (__MSDOS__) || defined (__MINGW32__)
> +  /* For Windows/DOS .exe executables, strip the .exe suffix, so that
> +     FOO-gdb.gdb could be used for FOO.exe, and try again.  */
> +  if (!input)
> +    {
> +      const size_t lexe = sizeof (".exe") - 1;
> +
> +      if (len > lexe
> +	  && strcasecmp (realname + len - lexe, ".exe") == 0)
> +	{
> +	  len -= lexe;
> +	  realname[len] = '\0';
> +	  filename = xrealloc (filename, len + strlen (language->suffix) + 1);

Here is a bug, former FILENAME is already registered for xfree in cleanups.

> +	  memcpy (filename, realname, len);
> +	  strcpy (filename + len, language->suffix);
> +	  input = fopen (filename, "r");
> +	  debugfile = filename;
> +	  if (debug_auto_load)
> +	    fprintf_unfiltered (gdb_stdlog, _("auto-load: Attempted file \"%s\" %s.\n"),
> +				debugfile, input ? _("exists") : _("does not exist"));
> +	}
> +    }
> +#endif
>    if (!input)
>      {
>        VEC (char_ptr) *vec;



gdb/
2012-08-20  Eli Zaretskii  <eliz@gnu.org>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>

	* auto-load.c (auto_load_objfile_script): Rename to ...
	(auto_load_objfile_script_1): ... here, change variable realname to
	parameter realname, document it, add return value, add variable retval.
	(auto_load_objfile_script): New function.

gdb/doc/
2012-08-20  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.texinfo (objfile-gdb.py file): New paragraph for .exe stripping.

diff --git a/gdb/auto-load.c b/gdb/auto-load.c
index 03a7539..f1cb5f8 100644
--- a/gdb/auto-load.c
+++ b/gdb/auto-load.c
@@ -693,27 +693,25 @@ clear_section_scripts (void)
     }
 }
 
-/* Look for the auto-load script in LANGUAGE associated with OBJFILE and load
-   it.  */
+/* Look for the auto-load script in LANGUAGE associated with OBJFILE where
+   OBJFILE's gdb_realpath is REALNAME and load it.  Return 1 if we found any
+   matching script, return 0 otherwise.  */
 
-void
-auto_load_objfile_script (struct objfile *objfile,
-			  const struct script_language *language)
+static int
+auto_load_objfile_script_1 (struct objfile *objfile, const char *realname,
+			    const struct script_language *language)
 {
-  char *realname;
   char *filename, *debugfile;
-  int len;
+  int len, retval;
   FILE *input;
   struct cleanup *cleanups;
 
-  realname = gdb_realpath (objfile->name);
   len = strlen (realname);
   filename = xmalloc (len + strlen (language->suffix) + 1);
   memcpy (filename, realname, len);
   strcpy (filename + len, language->suffix);
 
   cleanups = make_cleanup (xfree, filename);
-  make_cleanup (xfree, realname);
 
   input = fopen (filename, "r");
   debugfile = filename;
@@ -768,6 +766,44 @@ auto_load_objfile_script (struct objfile *objfile,
 	 and these scripts are required to be idempotent under multiple
 	 loads anyway.  */
       language->source_script_for_objfile (objfile, input, debugfile);
+
+      retval = 1;
+    }
+  else
+    retval = 0;
+
+  do_cleanups (cleanups);
+  return retval;
+}
+
+/* Look for the auto-load script in LANGUAGE associated with OBJFILE and load
+   it.  */
+
+void
+auto_load_objfile_script (struct objfile *objfile,
+			  const struct script_language *language)
+{
+  char *realname = gdb_realpath (objfile->name);
+  struct cleanup *cleanups = make_cleanup (xfree, realname);
+
+  if (!auto_load_objfile_script_1 (objfile, realname, language))
+    {
+      /* For Windows/DOS .exe executables, strip the .exe suffix, so that
+	 FOO-gdb.gdb could be used for FOO.exe, and try again.  */
+
+      size_t len = strlen (realname);
+      const size_t lexe = sizeof (".exe") - 1;
+
+      if (len > lexe && strcasecmp (realname + len - lexe, ".exe") == 0)
+	{
+	  len -= lexe;
+	  realname[len] = '\0';
+	  if (debug_auto_load)
+	    fprintf_unfiltered (gdb_stdlog, _("auto-load: Stripped .exe suffix, "
+					      "retrying with \"%s\".\n"),
+				realname);
+	  auto_load_objfile_script_1 (objfile, realname, language);
+	}
     }
 
   do_cleanups (cleanups);
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 08ba92d..66e217e 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -25765,6 +25765,13 @@ If this file does not exist, then @value{GDBN} will look for
 Note that loading of this script file also requires accordingly configured
 @code{auto-load safe-path} (@pxref{Auto-loading safe path}).
 
+For object files using @file{.exe} suffix @value{GDBN} tries to load first the
+scripts normally according to its @file{.exe} filename.  But if no scripts are
+found @value{GDBN} also tries script filenames matching the object file without
+its @file{.exe} suffix.  This @file{.exe} stripping is case insensitive and it
+is attempted on any platform.  This makes the script filenames compatible
+between Unix and MS-Windows hosts.
+
 @table @code
 @anchor{set auto-load scripts-directory}
 @kindex set auto-load scripts-directory

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

[Eli Zaretskii]

> Date: Mon, 20 Aug 2012 17:07:25 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org
> 
> On Sat, 18 Aug 2012 19:07:49 +0200, Eli Zaretskii wrote:
> > Like in the patch below?  I can drop the #ifdef, if no one objects (it
> > could surprise Unix users who call their programs FOO.exe for some
> > reason).
> 
> Yes, Joel also was for dropping the #ifdef.
> 
> Also I believe GDB should test the .exe-less filenames even
> in 'set auto-load scripts-directory' entries.
> 
> What about the patch below?

Looks good to me, thanks.

[commit+7.5] apropos fix for auto-load texts [Re: GDB 7.5: Problems with the auto-load safe-path feature]

[Jan Kratochvil]

On Sat, 18 Aug 2012 15:21:28 +0200, Jan Kratochvil wrote:
> 2012-08-18  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* cli/cli-decode.c (print_doc_line): Keep skipping '.' and ',' not
> 	followed by a whitespace.

Checked in:
	http://sourceware.org/ml/gdb-cvs/2012-08/msg00201.html
and for 7.5:
	http://sourceware.org/ml/gdb-cvs/2012-08/msg00202.html


Thanks,
Jan

[commit+7.5] auto-load for .exe files [Re: GDB 7.5: Problems with the auto-load safe-path feature]

[Jan Kratochvil]

On Mon, 20 Aug 2012 17:07:25 +0200, Jan Kratochvil wrote:
> gdb/
> 2012-08-20  Eli Zaretskii  <eliz@gnu.org>
> 	    Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* auto-load.c (auto_load_objfile_script): Rename to ...
> 	(auto_load_objfile_script_1): ... here, change variable realname to
> 	parameter realname, document it, add return value, add variable retval.
> 	(auto_load_objfile_script): New function.
> 
> gdb/doc/
> 2012-08-20  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* gdb.texinfo (objfile-gdb.py file): New paragraph for .exe stripping.

Checked in:
	http://sourceware.org/ml/gdb-cvs/2012-08/msg00203.html
and for 7.5:
	http://sourceware.org/ml/gdb-cvs/2012-08/msg00204.html


Jan