Re: Build question

Re: Build question

[Eli Zaretskii]

> From: Danny Backx <danny.backx@scarlet.be>
> Cc: gdb@sourceware.org
> Date: Sat, 05 Sep 2009 11:35:11 +0200

Patches should be sent to gdb-patches@ (redirected).

> ESR said "early and often", right ? Here is a first draft of my work.
> Showing this early allows you to steer me in the right direction.

Thanks.

> Otherwise, this code appears to work for me. I hardcoded the variable in
> gdb/main.c, set this to both 0 and 1 for testing, and saw the expected
> results.

Later we should probably have a user option to control that.

> Should I copy code that handles a variable like "solib-search-path" or
> "annotate" to set the _have_dos_based_file_system at runtime ?

Yes, IMO.

> +/* Filesystem type */
> +int _have_dos_based_file_system = 1;

I don't like its starting with an underline.  This is a normal
variable, no need to pretend it's internal or something.

> +      if (_have_dos_based_file_system) {

Please use the GNU style of brace-placing.

> +      } else {

Ditto.

> +/*
> + * Defined in gdb/main.c
> + *
> + * This determines whether we have
> + *   as a separator : / or \
> + *   a prefix [a-z]: or not
> + * Replaces HAVE_DOS_BASED_FILE_SYSTEM and FILENAME_PREFIX_LEN.
> + *
> + * Case sensitive/insensitive file name comparison is *not* influenced by this.
> + */

This is not the GNU style of comments.

> +static inline int _isalpha(int c)
> +{ 
> +  if (c <= 'Z' && c >= 'A')
> +    return TRUE;
> +  if (c <= 'z' && c >= 'a')
> +    return TRUE;
> +  return FALSE;
> +}

I'm not sure what The Powers That Be think about defining inline
functions in a header.  In general, if a host does not support the
`inline' keyword, it will be defined away, so you get several
identically-named functions in the same program (although I think
`static' prevents them from causing a link error).

Re: Build question

[Joel Brobecker]

> > +static inline int _isalpha(int c)
> > +{ 
> > +  if (c <= 'Z' && c >= 'A')
> > +    return TRUE;
> > +  if (c <= 'z' && c >= 'a')
> > +    return TRUE;
> > +  return FALSE;
> > +}
> 
> I'm not sure what The Powers That Be think about defining inline
> functions in a header.

As far as I am concerned, I would really like us to avoid them.
In this case, is the author trying to achieve performance or
to get a behavior that's independent from the locale?

-- 
Joel

Re: Build question

[Danny Backx]

On Mon, 2009-09-07 at 15:11 -0700, Joel Brobecker wrote:
> > > +static inline int _isalpha(int c)
> > > +{ 
> > > +  if (c <= 'Z' && c >= 'A')
> > > +    return TRUE;
> > > +  if (c <= 'z' && c >= 'a')
> > > +    return TRUE;
> > > +  return FALSE;
> > > +}
> > 
> > I'm not sure what The Powers That Be think about defining inline
> > functions in a header.
> 
> As far as I am concerned, I would really like us to avoid them.
> In this case, is the author trying to achieve performance or
> to get a behavior that's independent from the locale?

They are slightly more readable than the equivalent macros.
I've converted my code to use macros already. I need to add code to it
(to set the option) before I submit a new version.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Build question

[Danny Backx]

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

On Sat, 2009-09-05 at 19:09 +0300, Eli Zaretskii wrote:
> > Otherwise, this code appears to work for me. I hardcoded the variable in
> > gdb/main.c, set this to both 0 and 1 for testing, and saw the expected
> > results.
> 
> Later we should probably have a user option to control that.

This, and the changes you requested, are now in this new patch. Unless I
missed something :-)

Two almost identical remote debugging sessions showing the functionality
are below. It is a bit awkward, but this change influences the place
where the DLL names are read, which is when connecting to the target.

So changing the setting while in a debugging session won't affect the
result of "info share". That's why there are two separate sessions in
the output below.

Please review.

	Danny

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


pavilion: {310} ./gdb ~/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe

warning: A handler for the OS ABI "Windows CE" is not built into this
configuration
of GDB.  Attempting to continue with the default i386 settings.

GNU gdb (GDB) 6.8.50.20090905-cvs
Copyright (C) 2009 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 "--host=i686-pc-linux-gnu
--target=i386-mingw32ce".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe...done.
(gdb) set
solib-search-path /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++:/opt/x86mingw32ce/bin:/opt/x86mingw32ce/i386-mingw32ce/lib
(gdb) info share
No shared libraries loaded at this time.
(gdb) target remote ebox:9999
Remote debugging using ebox:9999
Error while mapping shared library sections:
\network\x86\libgcc_s_sjlj-1.dll: No such file or directory.
Error while mapping shared library sections:
\network\x86\libstdc++-6.dll: No such file or directory.
Error while mapping shared library sections:
\network\x86\libx.dll: No such file or directory.
Error while mapping shared library sections:
coredll.dll: No such file or directory.
Symbol file not found for \network\x86\libgcc_s_sjlj-1.dll
Symbol file not found for \network\x86\libstdc++-6.dll
Symbol file not found for \network\x86\libx.dll
Symbol file not found for coredll.dll
WinMainCRTStartup (hInst=0x586000a, hPrevInst=0x0, lpCmdLine=0x2601fc70
L"", nCmdShow=5)

at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
35      {
(gdb) info share
From        To          Syms Read   Shared Object Library
                        No          \network\x86\libgcc_s_sjlj-1.dll
                        No          \network\x86\libstdc++-6.dll
                        No          \network\x86\libx.dll
                        No          coredll.dll
(gdb) q
A debugging session is active.

        Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) n
Not confirmed.
(gdb) detach
Ending remote debugging.
(gdb) q
pavilion: {311} ./gdb ~/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe

warning: A handler for the OS ABI "Windows CE" is not built into this
configuration
of GDB.  Attempting to continue with the default i386 settings.

GNU gdb (GDB) 6.8.50.20090905-cvs
Copyright (C) 2009 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 "--host=i686-pc-linux-gnu
--target=i386-mingw32ce".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe...done.
(gdb) q
pavilion: {312} cat ~/xx
gdbserver :9999 /network/x86/usedemo.exe
./gdb ~/tmp/arm/test/remedy.nl/shlib/4.stdc++/usedemo.exe
set solib-search-path /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++:/opt/x86mingw32ce/bin:/opt/x86mingw32ce/i386-mingw32ce/lib
target remote ebox:9999
info share
pavilion: {313} ./gdb ~/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe

warning: A handler for the OS ABI "Windows CE" is not built into this
configuration
of GDB.  Attempting to continue with the default i386 settings.

GNU gdb (GDB) 6.8.50.20090905-cvs
Copyright (C) 2009 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 "--host=i686-pc-linux-gnu
--target=i386-mingw32ce".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/usedemo.exe...done.
(gdb) set
solib-search-path /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++:/opt/x86mingw32ce/bin:/opt/x86mingw32ce/i386-mingw32ce/lib
(gdb) set dos_based_file_system on
(gdb) target remote ebox:9999
Remote debugging using ebox:9999
Error while mapping shared library sections:
coredll.dll: No such file or directory.
Reading symbols from /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll...done.
Loaded symbols for /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
Reading symbols from /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc
++-6.dll...done.
Loaded symbols for /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
Reading symbols from /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/libx.dll...done.
Loaded symbols for /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc
++/libx.dll
Symbol file not found for coredll.dll
WinMainCRTStartup (hInst=0x41f000e, hPrevInst=0x0, lpCmdLine=0x2a01fc70
L"", nCmdShow=5)

at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35
35      {
(gdb) info share
From        To          Syms Read   Shared Object Library
0x42371000  0x4237c1fc
Yes         /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
0x41f01000  0x41fd2988
Yes         /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
0x41ee1000  0x41ee7068
Yes         /home/danny/tmp/arm/test/remedy.nl/shlib/4.stdc++/libx.dll
                        No          coredll.dll
(gdb) c
Continuing.

Program exited with code 017.
(gdb) q
pavilion: {314} 

[-- Attachment #2: gdb-diff-dos-2 --]
[-- Type: text/x-patch, Size: 10775 bytes --]

Index: bfd/archive.c
===================================================================
RCS file: /cvs/src/src/bfd/archive.c,v
retrieving revision 1.58
diff -u -r1.58 archive.c
--- bfd/archive.c	2 Sep 2009 07:18:35 -0000	1.58
+++ bfd/archive.c	8 Sep 2009 20:07:38 -0000
@@ -1295,7 +1295,7 @@
 {
   const char *filename = strrchr (file, '/');
 
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+  if (have_dos_based_file_system)
   {
     /* We could have foo/bar\\baz, or foo\\bar, or d:bar.  */
     char *bslash = strrchr (file, '\\');
@@ -1304,11 +1304,13 @@
     if (filename == NULL && file[0] != '\0' && file[1] == ':')
       filename = file + 1;
   }
-#endif
-  if (filename != NULL)
-    filename++;
   else
-    filename = file;
+  {
+    if (filename != NULL)
+      filename++;
+    else
+      filename = file;
+  }
   return filename;
 }
 #endif
@@ -1820,7 +1822,7 @@
   const char *filename = strrchr (pathname, '/');
   size_t maxlen = ar_maxnamelen (abfd);
 
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+  if (have_dos_based_file_system)
   {
     /* We could have foo/bar\\baz, or foo\\bar, or d:bar.  */
     char *bslash = strrchr (pathname, '\\');
@@ -1829,7 +1831,6 @@
     if (filename == NULL && pathname[0] != '\0' && pathname[1] == ':')
       filename = pathname + 1;
   }
-#endif
 
   if (filename == NULL)
     filename = pathname;
@@ -1868,7 +1869,7 @@
   const char *filename = strrchr (pathname, '/');
   size_t maxlen = ar_maxnamelen (abfd);
 
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+  if (have_dos_based_file_system)
   {
     /* We could have foo/bar\\baz, or foo\\bar, or d:bar.  */
     char *bslash = strrchr (pathname, '\\');
@@ -1878,7 +1879,6 @@
     if (filename == NULL && pathname[0] != '\0' && pathname[1] == ':')
       filename = pathname + 1;
   }
-#endif
 
   if (filename == NULL)
     filename = pathname;
Index: gdb/completer.c
===================================================================
RCS file: /cvs/src/src/gdb/completer.c,v
retrieving revision 1.34
diff -u -r1.34 completer.c
--- gdb/completer.c	25 Mar 2009 10:50:56 -0000	1.34
+++ gdb/completer.c	8 Sep 2009 20:07:45 -0000
@@ -232,13 +232,12 @@
 	  else
 	    break;		/* Hit the end of text.  */
 	}
-#if HAVE_DOS_BASED_FILE_SYSTEM
       /* If we have a DOS-style absolute file name at the beginning of
 	 TEXT, and the colon after the drive letter is the only colon
 	 we found, pretend the colon is not there.  */
-      else if (p < text + 3 && *p == ':' && p == text + 1 + quoted)
+      else if (have_dos_based_file_system
+            && p < text + 3 && *p == ':' && p == text + 1 + quoted)
 	;
-#endif
       else if (*p == ':' && !colon)
 	{
 	  colon = p;
Index: gdb/source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.103
diff -u -r1.103 source.c
--- gdb/source.c	23 Jul 2009 23:20:00 -0000	1.103
+++ gdb/source.c	8 Sep 2009 20:07:46 -0000
@@ -474,14 +474,20 @@
       /* name is the start of the directory.
 	 p is the separator (or null) following the end.  */
 
-      while (!(IS_DIR_SEPARATOR (*name) && p <= name + 1)	/* "/" */
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
-      /* On MS-DOS and MS-Windows, h:\ is different from h: */
-	     && !(p == name + 3 && name[1] == ':')		/* "d:/" */
-#endif
-	     && IS_DIR_SEPARATOR (p[-1]))
-	/* Sigh. "foo/" => "foo" */
-	--p;
+      if (have_dos_based_file_system) {
+        while (!(IS_DIR_SEPARATOR (*name) && p <= name + 1)	/* "/" */
+        /* On MS-DOS and MS-Windows, h:\ is different from h: */
+	       && !(p == name + 3 && name[1] == ':')		/* "d:/" */
+	       && IS_DIR_SEPARATOR (p[-1]))
+	  /* Sigh. "foo/" => "foo" */
+	  --p;
+      } else {
+        while (!(IS_DIR_SEPARATOR (*name) && p <= name + 1)	/* "/" */
+        /* On MS-DOS and MS-Windows, h:\ is different from h: */
+	       && IS_DIR_SEPARATOR (p[-1]))
+	  /* Sigh. "foo/" => "foo" */
+	  --p;
+      }
       *p = '\0';
 
       while (p > name && p[-1] == '.')
@@ -514,10 +520,9 @@
 
       if (name[0] == '~')
 	name = tilde_expand (name);
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
-      else if (IS_ABSOLUTE_PATH (name) && p == name + 2) /* "d:" => "d:." */
+      else if (have_dos_based_file_system
+	    && IS_ABSOLUTE_PATH (name) && p == name + 2) /* "d:" => "d:." */
 	name = concat (name, ".", (char *)NULL);
-#endif
       else if (!IS_ABSOLUTE_PATH (name) && name[0] != '$')
 	name = concat (current_directory, SLASH_STRING, name, (char *)NULL);
       else
Index: gdb/top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.170
diff -u -r1.170 top.c
--- gdb/top.c	31 Aug 2009 20:18:45 -0000	1.170
+++ gdb/top.c	8 Sep 2009 20:07:47 -0000
@@ -184,6 +184,9 @@
 char *lim_at_start;
 #endif
 
+/* Filesystem type */
+int have_dos_based_file_system = 0;
+
 /* Signal to catch ^Z typed while reading a command: SIGTSTP or SIGCONT.  */
 
 #ifndef STOP_SIGNAL
@@ -676,6 +679,15 @@
 		    value);
 }
 
+static void
+show_dos_based_file_system (struct ui_file *file, int from_tty,
+		       struct cmd_list_element *c, const char *value)
+{
+  fprintf_filtered (file, _("\
+Whether the target has a DOS based file system is \"%s\".\n"),
+		    value);
+}
+
 /* This is like readline(), but it has some gdb-specific behavior.
    gdb may want readline in both the synchronous and async modes during
    a single gdb invocation.  At the ordinary top-level prompt we might
@@ -1630,6 +1642,14 @@
 			    show_history_filename,
 			    &sethistlist, &showhistlist);
 
+  add_setshow_boolean_cmd ("dos_based_file_system", class_support,
+			    &have_dos_based_file_system, _("\
+Set whether the target has a DOS based file system"), _("\
+Show whether the target has a DOS based file system"), _("\
+whether the target has a DOS based file system"), NULL,
+			    show_dos_based_file_system,
+			    &setlist, &showlist);
+
   add_setshow_boolean_cmd ("confirm", class_support, &caution, _("\
 Set whether to confirm potentially dangerous operations."), _("\
 Show whether to confirm potentially dangerous operations."), NULL,
Index: gdb/utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.219
diff -u -r1.219 utils.c
--- gdb/utils.c	18 Aug 2009 16:17:16 -0000	1.219
+++ gdb/utils.c	8 Sep 2009 20:07:49 -0000
@@ -3280,15 +3280,14 @@
   strncpy (dir_name, filename, base_name - filename);
   dir_name[base_name - filename] = '\000';
 
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
   /* We need to be careful when filename is of the form 'd:foo', which
      is equivalent of d:./foo, which is totally different from d:/foo.  */
-  if (strlen (dir_name) == 2 && isalpha (dir_name[0]) && dir_name[1] == ':')
+  if (have_dos_based_file_system
+   && strlen (dir_name) == 2 && isalpha (dir_name[0]) && dir_name[1] == ':')
     {
       dir_name[2] = '.';
       dir_name[3] = '\000';
     }
-#endif
 
   /* Canonicalize the directory prefix, and build the resulting
      filename. If the dirname realpath already contains an ending
Index: gdb/cli/cli-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v
retrieving revision 1.92
diff -u -r1.92 cli-cmds.c
--- gdb/cli/cli-cmds.c	11 Jul 2009 14:04:23 -0000	1.92
+++ gdb/cli/cli-cmds.c	8 Sep 2009 20:07:50 -0000
@@ -357,24 +357,27 @@
   if (chdir (dir) < 0)
     perror_with_name (dir);
 
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
   /* There's too much mess with DOSish names like "d:", "d:.",
      "d:./foo" etc.  Instead of having lots of special #ifdef'ed code,
      simply get the canonicalized name of the current directory.  */
-  dir = getcwd (gdb_dirbuf, sizeof (gdb_dirbuf));
-#endif
+  if (have_dos_based_file_system)
+    dir = getcwd (gdb_dirbuf, sizeof (gdb_dirbuf));
 
   len = strlen (dir);
   if (IS_DIR_SEPARATOR (dir[len - 1]))
     {
       /* Remove the trailing slash unless this is a root directory
          (including a drive letter on non-Unix systems).  */
-      if (!(len == 1)		/* "/" */
-#ifdef HAVE_DOS_BASED_FILE_SYSTEM
-	  && !(len == 3 && dir[1] == ':') /* "d:/" */
-#endif
-	  )
-	len--;
+      if (have_dos_based_file_system)
+        {
+          if (!(len == 1) /* "/" */ && !(len == 3 && dir[1] == ':') /* "d:/" */)
+	    len--;
+        }
+      else
+        {
+          if (!(len == 1))		/* "/" */
+	    len--;
+        }
     }
 
   dir = savestring (dir, len);
Index: include/filenames.h
===================================================================
RCS file: /cvs/src/src/include/filenames.h,v
retrieving revision 1.5
diff -u -r1.5 filenames.h
--- include/filenames.h	21 Mar 2008 23:40:18 -0000	1.5
+++ include/filenames.h	8 Sep 2009 20:07:52 -0000
@@ -5,7 +5,7 @@
    use forward- and back-slash in path names interchangeably, and
    some of them have case-insensitive file names.
 
-   Copyright 2000, 2001, 2007 Free Software Foundation, Inc.
+   Copyright 2000, 2001, 2007, 2009 Free Software Foundation, Inc.
 
 This file is part of BFD, the Binary File Descriptor library.
 
@@ -30,25 +30,36 @@
 extern "C" {
 #endif
 
-#if defined(__MSDOS__) || defined(_WIN32) || defined(__OS2__) || defined (__CYGWIN__)
+/* Defined in gdb/top.c
+  
+   This determines whether we have
+     as a separator : / or \
+     a prefix [a-z]: or not
+   Replaces HAVE_DOS_BASED_FILE_SYSTEM and FILENAME_PREFIX_LEN.
+  
+   Case sensitive/insensitive file name comparison is *not* influenced by this. */
+
+extern int have_dos_based_file_system;
+
+#define	_isalpha(c) (((c >= 'A') && (c <= 'Z')) || ((c >= 'a') && (c <= 'z')))
+
+#define	IS_DIR_SEPARATOR(c)	\
+		((have_dos_based_file_system) ? \
+		((c == '/') || (c == '\\')) : \
+		(c == '/'))
 
-#ifndef HAVE_DOS_BASED_FILE_SYSTEM
-#define HAVE_DOS_BASED_FILE_SYSTEM 1
+#ifndef FALSE
+#define FALSE 0
+#endif
+#ifndef TRUE
+#define TRUE 1
 #endif
 
-#define IS_DIR_SEPARATOR(c)	((c) == '/' || (c) == '\\')
-/* Note that IS_ABSOLUTE_PATH accepts d:foo as well, although it is
-   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] == ':')))
-
-#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])) ? TRUE : \
+	(have_dos_based_file_system ? (_isalpha(f[0]) && (f[1] == ':')) : FALSE))
 
-#endif /* not DOSish */
+#endif	/* static inline functions */
 
 extern int filename_cmp (const char *s1, const char *s2);
 #define FILENAME_CMP(s1, s2)	filename_cmp(s1, s2)

Re: Build question

[Tom Tromey]

>>>>> "Danny" == Danny Backx <danny.backx@scarlet.be> writes:

Danny> Two almost identical remote debugging sessions showing the functionality
Danny> are below. It is a bit awkward, but this change influences the place
Danny> where the DLL names are read, which is when connecting to the target.

That seems unfortunate.

I don't mind having a user setting as a fallback, but it seems like
ordinarily GDB could detect the target's filesystem type, via a new
target method perhaps.

Danny> Index: bfd/archive.c

Changes to BFD need approval from the binutils maintainers.

Do you need most of these changes?  I thought perhaps you would only
need a change in the one place where the DLL name is searched for on the
host filesystem.

Danny> Index: gdb/top.c
Danny> +/* Filesystem type */
Danny> +int have_dos_based_file_system = 0;

Danny> Index: include/filenames.h

include is part of libiberty, so you'll need approval from the libiberty
maintainers.

Given that more programs than gdb use BFD and libiberty, you will at the
very least need to put have_dos_based_file_system elsewhere (i.e., in
libiberty).

Tom

Re: Build question

[Danny Backx]

On Wed, 2009-09-09 at 13:57 -0600, Tom Tromey wrote:
> >>>>> "Danny" == Danny Backx <danny.backx@scarlet.be> writes:

> Danny> Index: bfd/archive.c
> Changes to BFD need approval from the binutils maintainers.
> 
> Do you need most of these changes?  I thought perhaps you would only
> need a change in the one place where the DLL name is searched for on the
> host filesystem.
> 
> Danny> Index: gdb/top.c
> Danny> +/* Filesystem type */
> Danny> +int have_dos_based_file_system = 0;
> 
> Danny> Index: include/filenames.h
> 
> include is part of libiberty, so you'll need approval from the libiberty
> maintainers.
> 
> Given that more programs than gdb use BFD and libiberty, you will at the
> very least need to put have_dos_based_file_system elsewhere (i.e., in
> libiberty).

I'll create a version 3 of my patch (stripped down) and ask binutils and
libiberty owners.

I'll look into the other issue too (whether it would be possible to do
the right thing when setting the variable in the middle of a session).

Question : it looks like breaking a gdb-gdbserver session always kills
the inferior. Or at least it does so on my target. Has this been subject
of research yet ? I would expect it to be possible to detach without
killing the inferior, much like you can when debugging a linux process
from a linux gdb.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Build question

[Pedro Alves]

On Friday 11 September 2009 15:42:53, Danny Backx wrote:
> Question : it looks like breaking a gdb-gdbserver session always kills
> the inferior. Or at least it does so on my target. Has this been subject
> of research yet ? I would expect it to be possible to detach without
> killing the inferior, much like you can when debugging a linux process
> from a linux gdb.

What do you mean by breaking, and what do you mean by
detaching?  Please be specific.

Neither DebugActiveProcessStop nor DebugSetProcessKillOnExit were support
by Windows CE up until version 5.  I see that DebugActiveProcessStop
was added to CE 6.0:

 http://msdn.microsoft.com/pt-br/library/aa924105.aspx

... although there's no sign of DebugSetProcessKillOnExit.

win32-low.c:win32_detach has this:

/* Detach from inferior PID.  */
static int
win32_detach (int pid)
{
  struct process_info *process;
  winapi_DebugActiveProcessStop DebugActiveProcessStop = NULL;
  winapi_DebugSetProcessKillOnExit DebugSetProcessKillOnExit = NULL;
#ifdef _WIN32_WCE
  HMODULE dll = GetModuleHandle (_T("COREDLL.DLL"));
#else
  HMODULE dll = GetModuleHandle (_T("KERNEL32.DLL"));
#endif
  DebugActiveProcessStop = GETPROCADDRESS (dll, DebugActiveProcessStop);
  DebugSetProcessKillOnExit = GETPROCADDRESS (dll, DebugSetProcessKillOnExit);

  if (DebugSetProcessKillOnExit == NULL
      || DebugActiveProcessStop == NULL)
    return -1;

Try checking if DebugActiveProcessStop is non-NULL here on
your CE >= 6.0 device, and tweak this code to make it possible to detach
with DebugActiveProcessStop even if we don't support
DebugSetProcessKillOnExit.

(In fact, I don't understand why DebugSetProcessKillOnExit is
needed here.  does Windows really kill a detached inferior when
gdbserver exits _after_having_detached_from_it_?)

-- 
Pedro Alves

Re: Build question

[Pedro Alves]

On Friday 11 September 2009 16:22:32, Pedro Alves wrote:
>  http://msdn.microsoft.com/pt-br/library/aa924105.aspx

Errr, the same in English only: <http://msdn.microsoft.com/en-us/library/aa924105.aspx>

:-)

-- 
Pedro Alves

Re: Build question

[Danny Backx]

On Fri, 2009-09-11 at 16:22 +0100, Pedro Alves wrote:
> On Friday 11 September 2009 15:42:53, Danny Backx wrote:
> > Question : it looks like breaking a gdb-gdbserver session always kills
> > the inferior. Or at least it does so on my target. Has this been subject
> > of research yet ? I would expect it to be possible to detach without
> > killing the inferior, much like you can when debugging a linux process
> > from a linux gdb.
> 
> What do you mean by breaking, and what do you mean by
> detaching?  Please be specific.

Good question :-) Turns out I had not analysed my question sufficiently
before sending this mail.

What I was looking for is for gdbserver (and the inferior) to linger
after disconnecting gdb-gdbserver, until I reconnect to it with maybe
another gdb session.

Maybe my question is a bit too funky.

> Neither DebugActiveProcessStop nor DebugSetProcessKillOnExit were support
> by Windows CE up until version 5.  I see that DebugActiveProcessStop
> was added to CE 6.0:

> Try checking if DebugActiveProcessStop is non-NULL here on
> your CE >= 6.0 device, and tweak this code to make it possible to detach
> with DebugActiveProcessStop even if we don't support
> DebugSetProcessKillOnExit.
> 
> (In fact, I don't understand why DebugSetProcessKillOnExit is
> needed here.  does Windows really kill a detached inferior when
> gdbserver exits _after_having_detached_from_it_?)

No, I don't see that. FYI see two examples below, both show both the gdb
and gdbserver session (they're on my screen in two xterms).

Scenario 1 : detach gdb (from gdbserver)
 -> gdbserver appears to detach from inferior
 -> gdbserver terminates
 -> inferior continues to run

(gdb) target remote ebox:9999
Remote debugging using ebox:9999
(gdb) detach
Ending remote debugging.
(gdb) 

\network\x86>  gdbserver :9999 /network/x86/usedemo.exe
Process /network/x86/usedemo.exe created; pid = 88473610
Listening on port 9999
Remote debugging from host 172.17.1.10
Detaching from process 88473610
\network\x86> In main
Message from DLL
After DLL call

Scenario 2 : quit gdb
 -> gdb tells gdbserver to terminate inferior
 -> gdbserver terminates inferior
 -> gdbserver terminates

(gdb) target remote ebox:9999
Remote debugging using ebox:9999
(gdb) q
A debugging session is active.

        Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) y


\network\x86> gdbserver :9999 /network/x86/usedemo.exe
Process /network/x86/usedemo.exe created; pid = 92536842
Listening on port 9999
Remote debugging from host 172.17.1.10
Killing all inferiors
\network\x86> 

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Build question

[Pedro Alves]

On Saturday 12 September 2009 15:49:21, Danny Backx wrote:
> On Fri, 2009-09-11 at 16:22 +0100, Pedro Alves wrote:
> > On Friday 11 September 2009 15:42:53, Danny Backx wrote:
> > > Question : it looks like breaking a gdb-gdbserver session always kills
> > > the inferior. Or at least it does so on my target. Has this been subject
> > > of research yet ? I would expect it to be possible to detach without
> > > killing the inferior, much like you can when debugging a linux process
> > > from a linux gdb.
> > 
> > What do you mean by breaking, and what do you mean by
> > detaching?  Please be specific.
> 
> Good question :-) Turns out I had not analysed my question sufficiently
> before sending this mail.
> 
> What I was looking for is for gdbserver (and the inferior) to linger
> after disconnecting gdb-gdbserver, until I reconnect to it with maybe
> another gdb session.
> 
> Maybe my question is a bit too funky.
> 
> > Neither DebugActiveProcessStop nor DebugSetProcessKillOnExit were support
> > by Windows CE up until version 5.  I see that DebugActiveProcessStop
> > was added to CE 6.0:
> 
> > Try checking if DebugActiveProcessStop is non-NULL here on
> > your CE >= 6.0 device, and tweak this code to make it possible to detach
> > with DebugActiveProcessStop even if we don't support
> > DebugSetProcessKillOnExit.
> 
> \network\x86> testapi coredll DebugActiveProcessStop
>         coredll implements DebugActiveProcessStop (0x4003F4F0)
> \network\x86> testapi coredll DebugSetProcessKillOnExit
>         coredll implements DebugSetProcessKillOnExit (0x4003F510)
> \network\x86> 

So your device supports both DebugActiveProcessStop and
DebugSetProcessKillOnExit then.

> > (In fact, I don't understand why DebugSetProcessKillOnExit is
> > needed here.  does Windows really kill a detached inferior when
> > gdbserver exits _after_having_detached_from_it_?)
> 
> No, I don't see that. FYI see two examples below, both show both the gdb
> and gdbserver session (they're on my screen in two xterms).

What I meant by that, was: I was wondering if 
when you detach with the DebugActiveProcessStop api, while
DebugSetProcessKillOnExit is set to true, Windows is dump enough
to kill the former inferior when gdbserver exits.  If not, then
it looks like we don't need that call to DebugSetProcessKillOnExit
there, ever.  And I wondered about that because the link I showed
you referred that support for DebugActiveProcessStop was added
to CE 6.0, while DebugSetProcessKillOnExit wasn't.  But your
test app shows that DebugSetProcessKillOnExit is supported in
your device...

> 
> Scenario 1 : detach gdb (from gdbserver)
>  -> gdbserver appears to detach from inferior
>  -> gdbserver terminates
>  -> inferior continues to run
> 
> (gdb) target remote ebox:9999
> Remote debugging using ebox:9999
> (gdb) detach
> Ending remote debugging.
> (gdb) 

So, gdbserver's "detach" already works fine as is?

> 
> \network\x86>  gdbserver :9999 /network/x86/usedemo.exe
> Process /network/x86/usedemo.exe created; pid = 88473610
> Listening on port 9999
> Remote debugging from host 172.17.1.10
> Detaching from process 88473610
> \network\x86> In main
> Message from DLL
> After DLL call
> 
> Scenario 2 : quit gdb
>  -> gdb tells gdbserver to terminate inferior
>  -> gdbserver terminates inferior
>  -> gdbserver terminates
> 
> (gdb) target remote ebox:9999
> Remote debugging using ebox:9999
> (gdb) q
> A debugging session is active.
> 
>         Inferior 1 [Remote target] will be killed.
> 
> Quit anyway? (y or n) y
> 
> 
> \network\x86> gdbserver :9999 /network/x86/usedemo.exe
> Process /network/x86/usedemo.exe created; pid = 92536842
> Listening on port 9999
> Remote debugging from host 172.17.1.10
> Killing all inferiors
> \network\x86> 

And this is also working as expected?  What's the problem then?

-- 
Pedro Alves

Re: Build question

[Danny Backx]

I took the liberty of changing the order of some of the quotes below.

On Sat, 2009-09-12 at 16:03 +0100, Pedro Alves wrote:
> And this is also working as expected?  What's the problem then?

No problem, a question :

> On Saturday 12 September 2009 15:49:21, Danny Backx wrote:
> > On Fri, 2009-09-11 at 16:22 +0100, Pedro Alves wrote:
> > > On Friday 11 September 2009 15:42:53, Danny Backx wrote:
> > > > Question : it looks like breaking a gdb-gdbserver session always kills
> > > > the inferior. Or at least it does so on my target. Has this been subject
> > > > of research yet ? I would expect it to be possible to detach without
> > > > killing the inferior, much like you can when debugging a linux process
> > > > from a linux gdb.
> > > 
> > > What do you mean by breaking, and what do you mean by
> > > detaching?  Please be specific.
> > 
> > Good question :-) Turns out I had not analysed my question sufficiently
> > before sending this mail.
> > 
> > What I was looking for is for gdbserver (and the inferior) to linger
> > after disconnecting gdb-gdbserver, until I reconnect to it with maybe
> > another gdb session.
> > 
> > Maybe my question is a bit too funky.

I'll try to rephrase my question by means of a scenario :
1- start gdbserver (with inferior being debugged)
2- start gdb
3- connect gdb to gdbserver
4- do some debugging
5- notice that something's wrong
6- ?? tell gdbserver not to terminate when disconnected
7- tell gdb to disconnect from gdbserver
8- quit gdb
9- ... gdbserver+inferior are lingering (doing nothing until
   another gdb connects to it)
10- start another gdb
11- connect gdb to lingering gdbserver
12- continue debugging

What I am asking if this functionality is present, and whether it makes
sense to create it.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Build question

[Pedro Alves]

On Saturday 12 September 2009 18:00:43, Danny Backx wrote:

> 6- ?? tell gdbserver not to terminate when disconnected
> 7- tell gdb to disconnect from gdbserver

Did you try:

 (gdb) disconnect

?

-- 
Pedro Alves

Re: Build question

[Danny Backx]

On Sun, 2009-09-13 at 17:09 +0100, Pedro Alves wrote:
> On Saturday 12 September 2009 18:00:43, Danny Backx wrote:
> 
> > 6- ?? tell gdbserver not to terminate when disconnected
> > 7- tell gdb to disconnect from gdbserver
> 
> Did you try:
> 
>  (gdb) disconnect
> 
> ?

That does exactly what I needed, thanks.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Build question

[Danny Backx]

On Fri, 2009-09-11 at 16:22 +0100, Pedro Alves wrote:
>   DebugActiveProcessStop = GETPROCADDRESS (dll, DebugActiveProcessStop);
>   DebugSetProcessKillOnExit = GETPROCADDRESS (dll, DebugSetProcessKillOnExit);
> 
>   if (DebugSetProcessKillOnExit == NULL
>       || DebugActiveProcessStop == NULL)
>     return -1;
> 
> Try checking if DebugActiveProcessStop is non-NULL here on
> your CE >= 6.0 device, and tweak this code to make it possible to detach
> with DebugActiveProcessStop even if we don't support
> DebugSetProcessKillOnExit.

Apologies, I forgot to answer this part of the mail.

\network\x86> testapi coredll DebugActiveProcessStop
        coredll implements DebugActiveProcessStop (0x4003F4F0)
\network\x86> testapi coredll DebugSetProcessKillOnExit
        coredll implements DebugSetProcessKillOnExit (0x4003F510)
\network\x86> 

My testapi utility basically does what you asked (LoadLibrary -
GetProcAddress - print the result).

I'll look into this.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Build question

[Danny Backx]

On Wed, 2009-09-09 at 13:57 -0600, Tom Tromey wrote:
> >>>>> "Danny" == Danny Backx <danny.backx@scarlet.be> writes:
> Danny> Index: include/filenames.h
> 
> include is part of libiberty, so you'll need approval from the libiberty
> maintainers.
> 
> Given that more programs than gdb use BFD and libiberty, you will at the
> very least need to put have_dos_based_file_system elsewhere (i.e., in
> libiberty).

Who are the libiberty maintainers ? Is this part of another GNU
project ?

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Build question

[Joel Brobecker]

> Who are the libiberty maintainers ? Is this part of another GNU
> project ?

You can contact the libiberty maintainers thought the gcc-patches
mailing list.

-- 
Joel

Re: Build question

[Tom Tromey]

>>>>> "Danny" == Danny Backx <danny.backx@scarlet.be> writes:

Danny> Who are the libiberty maintainers ? Is this part of another GNU
Danny> project ?

It is part of src but also part of gcc.
The maintainers are mentioned in gcc's MAINTAINERS file:

libiberty		DJ Delorie		dj@redhat.com
libiberty		Ian Lance Taylor	ian@airs.com

Tom

Re: Build question

[Pedro Alves]

A Monday 14 September 2009 19:03:30, Tom Tromey escreveu:
> >>>>> "Danny" == Danny Backx <danny.backx@scarlet.be> writes:
> 
> Danny> Who are the libiberty maintainers ? Is this part of another GNU
> Danny> project ?
> 
> It is part of src but also part of gcc.
> The maintainers are mentioned in gcc's MAINTAINERS file:
> 
> libiberty		DJ Delorie		dj@redhat.com
> libiberty		Ian Lance Taylor	ian@airs.com
> 
> Tom
> 

For completeness: you'd easilly know to look at gcc's MAINTAINERS
file by first looking at the top level src/MAINTAINERS file:

intl/; config.rhost; libiberty/; libiberty's part of include/
        gcc: http://gcc.gnu.org
        Changes need to be done in tandem with the official GCC
        sources or submitted to the master file maintainer and brought
        in via a merge.  Note: approved patches in gcc's libiberty or
        intl are automatically approved in this libiberty and intl also;
        feel free to merge them yourself if needed sooner than the next
        merge.  Otherwise, changes are automatically merged, usually
        within a day.

-- 
Pedro Alves