RE: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

RE: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Aleksandar Ristovski]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]



> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: January 8, 2008 8:47 AM
> To: Eli Zaretskii
> Cc: dje@google.com; gdb-patches@sources.redhat.com; Aleksandar Ristovski;
> gcc-patches@gcc.gnu.org; Ryan Mansfield
> Subject: Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st
> yles
> 
> On Tue, Jan 08, 2008 at 06:24:33AM +0200, Eli Zaretskii wrote:
> > Yes, but why does GDB want to know at startup something about start.S
> > and crtn.S?
> 
> I believe we need this information when building psymtabs.  If not, it
> may be because we need symbol information for the program entry point.
> One or the other.
> 
> > Anyway, whatever problems can happen with these calls if we adopt my
> > suggestion of a user option, they already happen today.  So there's
> > nothing to lose here.
> 
> True.
> 
> --
> Daniel Jacobowitz
> CodeSourcery

How about this approach:

We use option "substitute-path" to rewrite paths that we want to check for
IS_ABSOLUTE_PATH. The logic would be: gdb compares paths in a way native to
its configured host system, but user should provide rules for rewriting
non-native paths. For example, when debugging executable that has DOS paths
in debug info, substitute rule could be 
C: /c
Users would, therefore, be responsible for providing the substitute rules if
they have a case of debugging binary compiled on a non-native file system.

(This only works for drive letter in DOS paths, doesn't address the dir.
Separator issue).

The attached patch is just to demonstrate the idea, it is not final
implementation. 
Thanks,

Aleksandar Ristovski
QNX Software Systems


[-- Attachment #2: IS_ABSOLUTE_PATHpatch.diff --]
[-- Type: application/octet-stream, Size: 4395 bytes --]

Index: gdb/source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.83
diff -u -p -r1.83 source.c
--- gdb/source.c	1 Jan 2008 22:53:13 -0000	1.83
+++ gdb/source.c	9 Jan 2008 16:09:40 -0000
@@ -895,7 +895,7 @@ get_substitute_path_rule (const char *pa
    Return NULL if no substitution rule was specified by the user,
    or if no rule applied to the given PATH.  */
    
-static char *
+char *
 rewrite_source_path (const char *path)
 {
   const struct substitute_path_rule *rule = get_substitute_path_rule (path);
Index: gdb/source.h
===================================================================
RCS file: /cvs/src/src/gdb/source.h,v
retrieving revision 1.9
diff -u -p -r1.9 source.h
--- gdb/source.h	1 Jan 2008 22:53:13 -0000	1.9
+++ gdb/source.h	9 Jan 2008 16:09:40 -0000
@@ -20,6 +20,7 @@
 #define SOURCE_H
 
 struct symtab;
+struct partial_symtab;
 
 /* Open a source file given a symtab S.  Returns a file descriptor or
    negative number for error.  */
@@ -66,4 +67,7 @@ extern struct symtab_and_line set_curren
 
 /* Reset any information stored about a default file and line to print. */
 extern void clear_current_source_symtab_and_line (void);
+
+extern char *rewrite_source_path (const char *path);
+
 #endif
Index: gdb/utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.184
diff -u -p -r1.184 utils.c
--- gdb/utils.c	1 Jan 2008 22:53:13 -0000	1.184
+++ gdb/utils.c	9 Jan 2008 16:09:40 -0000
@@ -34,6 +34,8 @@
 #include <pc.h>
 #endif
 
+#include "source.h"
+
 /* SunOS's curses.h has a '#define reg register' in it.  Thank you Sun. */
 #ifdef reg
 #undef reg
@@ -3223,3 +3225,21 @@ ldirname (const char *filename)
   dirname[base - filename] = '\0';
   return dirname;
 }
+
+int
+is_absolute_path (const char *path)
+{
+  char *rwpath = rewrite_source_path (path);
+
+  if (rwpath == NULL)
+    rwpath = (char *) path;
+  else
+    make_cleanup (xfree, rwpath);
+
+#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+  return IS_ABSOLUTE_PATH_DOS (rwpath);
+#else
+  return IS_ABSOLUTE_PATH_POSIX (rwpath);
+#endif
+
+}
Index: include/filenames.h
===================================================================
RCS file: /cvs/src/src/include/filenames.h,v
retrieving revision 1.4
diff -u -p -r1.4 filenames.h
--- include/filenames.h	29 Mar 2007 21:03:43 -0000	1.4
+++ include/filenames.h	9 Jan 2008 16:09:41 -0000
@@ -26,6 +26,22 @@ Foundation, Inc., 51 Franklin Street - F
 #ifndef FILENAMES_H
 #define FILENAMES_H
 
+/* For DOS style paths.  */
+
+#define IS_DIR_SEPARATOR_DOS(c)	  ((c) == '/' || (c) == '\\')
+
+/*Note that IS_ABSOLUTE_PATH_DOS macro does not recognize
+  path starting with '/' as an absolute path. Otherwise, it behaves
+  as IS_DIR_SEPARATOR macro when configured for DOS-like
+  file system (see comment for IS_ABSOLUTE_PATH below).  */
+
+#define IS_ABSOLUTE_PATH_DOS(f)	  (IS_DIR_SEPARATOR_DOS((f)[0]) || (((f)[0]) && ((f)[1] == ':')))
+
+/* For POSIX style paths.  */
+
+#define IS_DIR_SEPARATOR_POSIX(c)	  ((c) == '/')
+#define IS_ABSOLUTE_PATH_POSIX(f)	  (IS_DIR_SEPARATOR_POSIX((f)[0]))
+
 #if defined(__MSDOS__) || defined(_WIN32) || defined(__OS2__) || defined (__CYGWIN__)
 
 #ifndef HAVE_DOS_BASED_FILE_SYSTEM
@@ -37,16 +53,19 @@ Foundation, Inc., 51 Franklin Street - F
    only semi-absolute.  This is because the users of IS_ABSOLUTE_PATH
    want to know whether to prepend the current working directory to
    a file name, which should not be done with a name like d:foo.  */
-#define IS_ABSOLUTE_PATH(f)	(IS_DIR_SEPARATOR((f)[0]) || (((f)[0]) && ((f)[1] == ':')))
+//#define IS_ABSOLUTE_PATH(f)	(IS_DIR_SEPARATOR((f)[0]) || (((f)[0]) && ((f)[1] == ':')))
 
 #else  /* not DOSish */
 
 #define IS_DIR_SEPARATOR(c)	((c) == '/')
-#define IS_ABSOLUTE_PATH(f)	(IS_DIR_SEPARATOR((f)[0]))
+// #define IS_ABSOLUTE_PATH(f)	(IS_DIR_SEPARATOR((f)[0]))
+extern int is_absolute_path (const char *path);
 
 #endif /* not DOSish */
 
 extern int filename_cmp (const char *s1, const char *s2);
 #define FILENAME_CMP(s1, s2)	filename_cmp(s1, s2)
 
+extern int is_absolute_path (const char *path);
+#define IS_ABSOLUTE_PATH(f) is_absolute_path(f)
 #endif /* FILENAMES_H */

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> From: Aleksandar Ristovski <ARistovski@qnx.com>
> Cc: dje@google.com, gdb-patches@sources.redhat.com,  	gcc-patches@gcc.gnu.org, Ryan Mansfield <RMansfield@qnx.com>
> Date: Wed, 9 Jan 2008 11:13:11 -0500
> 
> (This only works for drive letter in DOS paths, doesn't address the dir.
> Separator issue).

Right, and therefore why is it useful to consider partial solutions?
Can we at all use similar method to handle the slashes?

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Daniel Jacobowitz]

On Wed, Jan 09, 2008 at 09:09:24PM +0200, Eli Zaretskii wrote:
> > From: Aleksandar Ristovski <ARistovski@qnx.com>
> > Cc: dje@google.com, gdb-patches@sources.redhat.com,  	gcc-patches@gcc.gnu.org, Ryan Mansfield <RMansfield@qnx.com>
> > Date: Wed, 9 Jan 2008 11:13:11 -0500
> > 
> > (This only works for drive letter in DOS paths, doesn't address the dir.
> > Separator issue).
> 
> Right, and therefore why is it useful to consider partial solutions?
> Can we at all use similar method to handle the slashes?

I used to use a local version of filename_cmp which treated both / and
\ as directory separators.  Barring the strict POSIX filename support
issue, which we've agreed can be handled by a user option, it worked
well enough.  You would still need to use substitute-path to handle
drive names; this wasn't an issue for me, since I was running the GDB
testsuite, which uses "dir" heavily to find source files.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> Date: Wed, 9 Jan 2008 14:42:36 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Aleksandar Ristovski <ARistovski@qnx.com>, dje@google.com,
> 	gdb-patches@sources.redhat.com, gcc-patches@gcc.gnu.org,
> 	RMansfield@qnx.com
> 
> I used to use a local version of filename_cmp which treated both / and
> \ as directory separators.  Barring the strict POSIX filename support
> issue, which we've agreed can be handled by a user option, it worked
> well enough.

That would be an okay solution.  (I always argued that treating file
names like simple strings is wrong.)

> You would still need to use substitute-path to handle drive names

Why? can't filename_cmp handle that as well?

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Daniel Jacobowitz]

On Thu, Jan 10, 2008 at 06:12:45AM +0200, Eli Zaretskii wrote:
> > You would still need to use substitute-path to handle drive names
> 
> Why? can't filename_cmp handle that as well?

I didn't think that statement through.  You need to use
substitute-path or "dir", because opening "c:\foo" on a Linux system
isn't going to find anything useful.

There's probably work to be done converting Windows slashes to POSIX
slashes automatically.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

[I added gdb-patches to the discussion.]

> Date: Sun, 6 Jan 2008 00:40:30 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gcc-patches@gcc.gnu.org,
> 	Ryan Mansfield <RMansfield@qnx.com>
> 
> On Sun, Jan 06, 2008 at 12:30:11AM -0500, Aleksandar Ristovski wrote:
> > > 
> > > But the form of the file names is determined by the platform on which
> > > you compiled the sources, right?  
> > 
> > Right and this is the problem: IS_ABSOLUTE_PATH is determined at compile
> > time only by platform on which gdb will be running. Gdb, however needs to
> > deal with binaries possibly built on a platform with different file system
> > (we often have this case: gdb on POSIX file system debugging binary built on
> > windows).
> 
> I also regularly work with the other direction, POSIX build system and
> Windows debug host.

In that case, I think it's wrong to allow both styles of slashes and
absolute file names.  Instead, we should have a user option to set the
correct style, which would default to the convention of the platform
where GDB was built to run.

If you agree with this approach, then the _ANY version of the macros
is not needed.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Doug Evans]

On Jan 6, 2008 11:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> [I added gdb-patches to the discussion.]
>
> > Date: Sun, 6 Jan 2008 00:40:30 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, gcc-patches@gcc.gnu.org,
> >       Ryan Mansfield <RMansfield@qnx.com>
> >
> > On Sun, Jan 06, 2008 at 12:30:11AM -0500, Aleksandar Ristovski wrote:
> > > >
> > > > But the form of the file names is determined by the platform on which
> > > > you compiled the sources, right?
> > >
> > > Right and this is the problem: IS_ABSOLUTE_PATH is determined at compile
> > > time only by platform on which gdb will be running. Gdb, however needs to
> > > deal with binaries possibly built on a platform with different file system
> > > (we often have this case: gdb on POSIX file system debugging binary built on
> > > windows).
> >
> > I also regularly work with the other direction, POSIX build system and
> > Windows debug host.
>
> In that case, I think it's wrong to allow both styles of slashes and
> absolute file names.  Instead, we should have a user option to set the
> correct style, which would default to the convention of the platform
> where GDB was built to run.
>
> If you agree with this approach, then the _ANY version of the macros
> is not needed.

It seems like GDB should know what to use, or at least be able to
figure it out (in cases where it really matters).  Are we really sure
we need an option?  How would this option work in practice?  If one
ever wanted to set it to the non-default value it'd be rather
cumbersome to have to set it and then reset it for one-off uses of
"the other" path kind.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> Date: Sun, 6 Jan 2008 12:03:08 -0800
> From: "Doug Evans" <dje@google.com>
> Cc: "Daniel Jacobowitz" <drow@false.org>, gdb-patches@sources.redhat.com,
>         ARistovski@qnx.com, gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> 
> > In that case, I think it's wrong to allow both styles of slashes and
> > absolute file names.  Instead, we should have a user option to set the
> > correct style, which would default to the convention of the platform
> > where GDB was built to run.
> >
> > If you agree with this approach, then the _ANY version of the macros
> > is not needed.
> 
> It seems like GDB should know what to use, or at least be able to
> figure it out (in cases where it really matters).

How can GDB figure that out?  We don't tell it enough about the
program being debugged for that.

But if I'm wrong, and GDB _can_ figure it out on its own, then it
should use the right style of file names automagically, and the _ANY
set of macros is again not needed.

> Are we really sure we need an option?

If GDB cannot figure this out, the user should tell it, since the user
always knows.

> How would this option work in practice?

How about

 (gdb) set filename-style (dos|unix)

?

> If one ever wanted to set it to the non-default value it'd be
> rather cumbersome to have to set it and then reset it for one-off
> uses of "the other" path kind.

No more cumbersome than any other similar option, like "set
demangle-style", for example.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Doug Evans]

On Jan 6, 2008 12:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > How would this option work in practice?
>
> How about
>
>  (gdb) set filename-style (dos|unix)
>
> ?

Apologies.  The question on how it would work in practice and the
comment on being cumbersome weren't intended to be treated in
isolation.

> > If one ever wanted to set it to the non-default value it'd be
> > rather cumbersome to have to set it and then reset it for one-off
> > uses of "the other" path kind.
>
> No more cumbersome than any other similar option, like "set
> demangle-style", for example.

I haven't used demangle-style enough to know if the use-cases are similar.

What would the option apply to?  How would the user know when and when
not to use it?

One thing that occurs to me is what if I do "bash$ gdb
/prog/with/other/path/format"?   Will gdb need to know the format
before the user gets a chance to specify the format? [Now we're not
just adding an option but a command line parameter too.]

Another thing that occurs to me is that I vaguely remember building
libraries in one environment and then using the library in another.  I
could be mistaken, it's been awhile.  Can one have a case where both
path formats are in use simultaneously?

I don't mean to belabor the issue.  It's just that an option seems
problematic at best.  I could be wrong of course.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Daniel Jacobowitz]

On Sun, Jan 06, 2008 at 01:07:25PM -0800, Doug Evans wrote:
> Another thing that occurs to me is that I vaguely remember building
> libraries in one environment and then using the library in another.  I
> could be mistaken, it's been awhile.  Can one have a case where both
> path formats are in use simultaneously?

Yes, that's what I was going to add.  This is how I normally work.
We build toolchains using a GNU/Linux host, including libraries.  When
our customers run the IDE on Windows, they get mixed debug
information; some has Windows paths, some has POSIX paths.  I think
that a best-effort approach to work with both is more valuable than
handling the few corner cases where that breaks down (e.g. paths
containing a '\' or ':' on a POSIX system).

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> Date: Sun, 6 Jan 2008 22:40:31 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com,
> 	ARistovski@qnx.com, gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> 
> On Sun, Jan 06, 2008 at 01:07:25PM -0800, Doug Evans wrote:
> > Another thing that occurs to me is that I vaguely remember building
> > libraries in one environment and then using the library in another.  I
> > could be mistaken, it's been awhile.  Can one have a case where both
> > path formats are in use simultaneously?
> 
> Yes, that's what I was going to add.  This is how I normally work.
> We build toolchains using a GNU/Linux host, including libraries.  When
> our customers run the IDE on Windows, they get mixed debug
> information; some has Windows paths, some has POSIX paths.  I think
> that a best-effort approach to work with both is more valuable than
> handling the few corner cases where that breaks down (e.g. paths
> containing a '\' or ':' on a POSIX system).

We must have a way for a user on a Posix system to have file names
with `\' or `:'.  It is IMO unacceptable to say that these cases,
however corner, are simply not supported.  Other packages, such as
Bash, do give you a way of having them, albeit an inconvenient way.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Daniel Jacobowitz]

On Mon, Jan 07, 2008 at 06:20:29AM +0200, Eli Zaretskii wrote:
> We must have a way for a user on a Posix system to have file names
> with `\' or `:'.  It is IMO unacceptable to say that these cases,
> however corner, are simply not supported.  Other packages, such as
> Bash, do give you a way of having them, albeit an inconvenient way.

Can you suggest one that does not break these more common cases?

Perhaps a tri-state option...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> Date: Mon, 7 Jan 2008 08:16:49 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: dje@google.com, gdb-patches@sources.redhat.com, ARistovski@qnx.com,
> 	gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> 
> On Mon, Jan 07, 2008 at 06:20:29AM +0200, Eli Zaretskii wrote:
> > We must have a way for a user on a Posix system to have file names
> > with `\' or `:'.  It is IMO unacceptable to say that these cases,
> > however corner, are simply not supported.  Other packages, such as
> > Bash, do give you a way of having them, albeit an inconvenient way.
> 
> Can you suggest one that does not break these more common cases?
> 
> Perhaps a tri-state option...

Yes, I still think a user option is the best solution.

Failing that, perhaps some kind of quoting would do.  But I'm afraid
that would require lots of changes to GDB code.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> Date: Sun, 6 Jan 2008 13:07:25 -0800
> From: "Doug Evans" <dje@google.com>
> Cc: drow@false.org, gdb-patches@sources.redhat.com, ARistovski@qnx.com,
>         gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> 
> What would the option apply to?  How would the user know when and when
> not to use it?

I don't really understand the question.  How would the user know when
to use any other option?  If they read the documentation and
understand the issues, they will know.

> One thing that occurs to me is what if I do "bash$ gdb
> /prog/with/other/path/format"?   Will gdb need to know the format
> before the user gets a chance to specify the format?

No.  We were talking about finding sources given file names recorded
in the debug info.  Finding the program given the command-line
arguments is not the same problem, and I don't thing GDB uses any of
these macros to do that, or needs to.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Doug Evans]

On Jan 6, 2008 8:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sun, 6 Jan 2008 13:07:25 -0800
> > From: "Doug Evans" <dje@google.com>
> > Cc: drow@false.org, gdb-patches@sources.redhat.com, ARistovski@qnx.com,
> >         gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> >
> > What would the option apply to?  How would the user know when and when
> > not to use it?
>
> I don't really understand the question.  How would the user know when
> to use any other option?  If they read the documentation and
> understand the issues, they will know.

I realize the question may sound odd.  I asked it because the range to
which the option may apply seems vast, whereas the range to which it
will be applied (AIUI) seems small, leading to excessive confusion.
If I'm mistaken about that then ignore the question.

Of course, one might be able to come up with a suitable enough name
for the option to mitigate the confusion.  I don't know.  I'd be
curious to see a patch.

> > One thing that occurs to me is what if I do "bash$ gdb
> > /prog/with/other/path/format"?   Will gdb need to know the format
> > before the user gets a chance to specify the format?
>
> No.  We were talking about finding sources given file names recorded
> in the debug info.  Finding the program given the command-line
> arguments is not the same problem, and I don't thing GDB uses any of
> these macros to do that, or needs to.

Perhaps I should have written "gdb
prog.with.other.path.format.in.debug.info".  :-)
As a datapoint, and to give some context for the above, I patched
filenames.h to print a message whenever IS_ABSOLUTE_PATH is called.

dje@ruffy:~$ ./gdb -nx hello
GNU gdb 6.7.50.20080104-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux"...
IS_ABSOLUTE_PATH (/home/dje/hello.x32)
IS_ABSOLUTE_PATH (/home/dje/hello.x32)
IS_ABSOLUTE_PATH (start.S)
IS_ABSOLUTE_PATH (../sysdeps/i386/elf/start.S)
IS_ABSOLUTE_PATH (crti.S)
IS_ABSOLUTE_PATH (/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crti.S)
IS_ABSOLUTE_PATH (hello.c)
IS_ABSOLUTE_PATH (hello.c)
IS_ABSOLUTE_PATH (crtn.S)
IS_ABSOLUTE_PATH (/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crtn.S)
(gdb)

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> Date: Mon, 7 Jan 2008 09:35:30 -0800
> From: "Doug Evans" <dje@google.com>
> Cc: drow@false.org, gdb-patches@sources.redhat.com, ARistovski@qnx.com,         gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> 
> On Jan 6, 2008 8:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > > Date: Sun, 6 Jan 2008 13:07:25 -0800
> > > From: "Doug Evans" <dje@google.com>
> > > Cc: drow@false.org, gdb-patches@sources.redhat.com, ARistovski@qnx.com,
> > >         gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> > >
> > > What would the option apply to?  How would the user know when and when
> > > not to use it?
> >
> > I don't really understand the question.  How would the user know when
> > to use any other option?  If they read the documentation and
> > understand the issues, they will know.
> 
> I realize the question may sound odd.  I asked it because the range to
> which the option may apply seems vast, whereas the range to which it
> will be applied (AIUI) seems small, leading to excessive confusion.

Many GDB options are used only in very rare cases.  That doesn't make
them less useful: when you are in that rare situation, these options
are a godsend.

> Perhaps I should have written "gdb
> prog.with.other.path.format.in.debug.info".  :-)
> As a datapoint, and to give some context for the above, I patched
> filenames.h to print a message whenever IS_ABSOLUTE_PATH is called.
> 
> dje@ruffy:~$ ./gdb -nx hello
> GNU gdb 6.7.50.20080104-cvs
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-linux"...
> IS_ABSOLUTE_PATH (/home/dje/hello.x32)
> IS_ABSOLUTE_PATH (/home/dje/hello.x32)
> IS_ABSOLUTE_PATH (start.S)
> IS_ABSOLUTE_PATH (../sysdeps/i386/elf/start.S)
> IS_ABSOLUTE_PATH (crti.S)
> IS_ABSOLUTE_PATH (/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crti.S)
> IS_ABSOLUTE_PATH (hello.c)
> IS_ABSOLUTE_PATH (hello.c)
> IS_ABSOLUTE_PATH (crtn.S)
> IS_ABSOLUTE_PATH (/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crtn.S)

What GDB code causes these calls, and why?

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Daniel Jacobowitz]

On Mon, Jan 07, 2008 at 11:30:08PM +0200, Eli Zaretskii wrote:
> What GDB code causes these calls, and why?

The symbol readers do a lot of pathname comparison when they read in
debug information; that's the same code where the bug starting this
conversation was found.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Eli Zaretskii]

> Date: Mon, 7 Jan 2008 16:35:43 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Doug Evans <dje@google.com>, gdb-patches@sources.redhat.com,
> 	ARistovski@qnx.com, gcc-patches@gcc.gnu.org, RMansfield@qnx.com
> 
> On Mon, Jan 07, 2008 at 11:30:08PM +0200, Eli Zaretskii wrote:
> > What GDB code causes these calls, and why?
> 
> The symbol readers do a lot of pathname comparison when they read in
> debug information

Yes, but why does GDB want to know at startup something about start.S
and crtn.S?

Anyway, whatever problems can happen with these calls if we adopt my
suggestion of a user option, they already happen today.  So there's
nothing to lose here.

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Daniel Jacobowitz]

On Tue, Jan 08, 2008 at 06:24:33AM +0200, Eli Zaretskii wrote:
> Yes, but why does GDB want to know at startup something about start.S
> and crtn.S?

I believe we need this information when building psymtabs.  If not, it
may be because we need symbol information for the program entry point.
One or the other.

> Anyway, whatever problems can happen with these calls if we adopt my
> suggestion of a user option, they already happen today.  So there's
> nothing to lose here.

True.

-- 
Daniel Jacobowitz
CodeSourcery

RE: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Aleksandar Ristovski]

Oops... the patch I submitted has a few typos. Sorry about that. Here is the
correct one.

This patch introduces new IS_DIR_SEPARATOR_? And IS_ABSOLUTE_PATH_? Macros.

Old macros IS_DIR_SEPARATOR and IS_ABSOLUTE_PATH continue to be configured
host dependent.

Please see http://sourceware.org/ml/gdb/2008-01/msg00021.html for details on
why this patch.

---
Aleksandar Ristovski
QNX Software Systems

ChangeLog:
2008-01-04  Aleksandar Ristovski  <aristovski@qnx.com>

        * filenames.h (IS_DIR_SEPARATOR_DOS): New macro.
        (IS_ABSOLUTE_PATH_DOS): New macro.
        (IS_DIR_SEPARATOR_X): New macro.
        (IS_ABSOLUTE_PATH_X): New macro.
        (IS_DIR_SEPARATOR_ANY): New macro.
        (IS_ABSOLUTE_PATH_ANY): New macro.


Index: include/filenames.h
===================================================================
RCS file: /cvs/src/src/include/filenames.h,v
retrieving revision 1.4
diff -u -3 -p -r1.4 filenames.h
--- include/filenames.h	29 Mar 2007 21:03:43 -0000	1.4
+++ include/filenames.h	4 Jan 2008 19:22:02 -0000
@@ -26,6 +26,23 @@ Foundation, Inc., 51 Franklin Street - F
 #ifndef FILENAMES_H
 #define FILENAMES_H
 
+/* For DOS style paths. Note that these macros do not recognize
+  path starting with '/' as an absolute path.  */
+
+#define IS_DIR_SEPARATOR_DOS(c)	  ((c) == '/' || (c) == '\\')
+#define IS_ABSOLUTE_PATH_DOS(f)	  (((f)[0]) && ((f)[1] == ':'))
+
+/* For POSIX style paths.  */
+
+#define IS_DIR_SEPARATOR_X(c)	  ((c) == '/')
+#define IS_ABSOLUTE_PATH_X(f)	  (IS_DIR_SEPARATOR_X((f)[0]))
+
+/* Universal macros, to be used on paths that could be either
+   POSIX or DOS.  */
+
+#define IS_DIR_SEPARATOR_ANY(c)	  (IS_DIR_SEPARATOR_DOS(c))
+#define IS_ABSOLUTE_PATH_ANY(f)	  (IS_ABSOLUTE_PATH_X(f) ||
IS_ABSOLUTE_PATH_DOS(f))
+
 #if defined(__MSDOS__) || defined(_WIN32) || defined(__OS2__) || defined
(__CYGWIN__)
 
 #ifndef HAVE_DOS_BASED_FILE_SYSTEM

Re: [patch] IS_ABSOLUTE_PATH to handle both DOS and POSIX path st yles

[Daniel Jacobowitz]

On Fri, Jan 04, 2008 at 02:25:50PM -0500, Aleksandar Ristovski wrote:
> Oops... the patch I submitted has a few typos. Sorry about that. Here is the
> correct one.
> 
> This patch introduces new IS_DIR_SEPARATOR_? And IS_ABSOLUTE_PATH_? Macros.
> 
> Old macros IS_DIR_SEPARATOR and IS_ABSOLUTE_PATH continue to be configured
> host dependent.
> 
> Please see http://sourceware.org/ml/gdb/2008-01/msg00021.html for details on
> why this patch.

This looks OK to me, but the file belongs to libiberty - please send
it to gcc-patches, mention libiberty in the subject line, and DJ or
Ian will look at it.

-- 
Daniel Jacobowitz
CodeSourcery