No Subject

No Subject

[Philippe De Muyter]

Am I the only one to have (sometimes) the problem of finding a non-executable
with the same name earlier in my path than the program I want to debug ?

Here is a patch.

I also removed the obsolete (now that we have gdb_string.h) strstr
declaration comment.

Mon Apr  6 13:20:21 1998  Philippe De Muyter  <phdm@macqel.be>

	* source.c (openp): Accept only files that match prot.
	* exec.c (exec_file_command): Request openp to find an executable
	file.

--- ./gdb/source.c	Mon Apr  6 11:22:17 1998
+++ ./gdb/source.c	Mon Apr  6 09:49:08 1998
@@ -83,11 +83,6 @@
 
 static void find_source_lines PARAMS ((struct symtab *, int));
 
-/* If we use this declaration, it breaks because of fucking ANSI "const" stuff
-   on some systems.  We just have to not declare it at all, have it default
-   to int, and possibly botch on a few systems.  Thanks, ANSIholes... */
-/* extern char *strstr(); */
-
 /* Path of directories to search for source files.
    Same format as the PATH environment variable's value.  */
 
@@ -521,7 +516,7 @@ openp (path, try_cwd_first, string, mode
     {
       int i;
       filename = string;
-      fd = open (filename, mode, prot);
+      fd = open (filename, mode);
       if (fd >= 0)
 	goto done;
       for (i = 0; string[i]; i++)
@@ -570,8 +565,10 @@ openp (path, try_cwd_first, string, mode
       strcat (filename+len, SLASH_STRING);
       strcat (filename, string);
 
-      fd = open (filename, mode);
-      if (fd >= 0) break;
+      /* Accept only files matching prot. */
+      if ((prot == 0 || access(filename, prot) == 0)
+      	  && (fd = open (filename, mode)) >= 0)
+	break;
     }
 
  done:
--- ./gdb/exec.c	Mon Apr  6 11:22:18 1998
+++ ./gdb/exec.c	Sat Apr  4 09:37:50 1998
@@ -32,6 +32,12 @@
 #endif
 
 #include <fcntl.h>
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif
+#ifndef X_OK
+#define X_OK	1
+#endif
 #include "gdb_string.h"
 
 #include "gdbcore.h"
@@ -185,8 +191,8 @@ exec_file_command (args, from_tty)
       make_cleanup (free, filename);
       
       scratch_chan = openp (getenv ("PATH"), 1, filename, 
-			    write_files? O_RDWR|O_BINARY: O_RDONLY|O_BINARY, 0,
-			    &scratch_pathname);
+			    write_files? O_RDWR|O_BINARY: O_RDONLY|O_BINARY,
+			    X_OK, &scratch_pathname);
 #if defined(__GO32__) || defined(_WIN32)
       if (scratch_chan < 0)
       {

No Subject

[Stan Shebs]

   Date: Mon, 6 Apr 1998 13:41:37 +0200 (MET DST)
   From: "Philippe De Muyter" <phdm@macqel.be>

   Am I the only one to have (sometimes) the problem of finding a non-executable
   with the same name earlier in my path than the program I want to debug ?

Apparently. :-)  But seriously, I don't think this change is a good idea.
While it would work fine for native Unix debugging, it will lose for
just about everything else.  For both cross-Unix and embedded debugging
you almost certainly want the programs *not* to be marked as executable,
so that your current host doesn't try to execute them.

However, if you set things up so that this test is only made when
using a Unix child_ops, this would be a useful addition.

							Stan

Re:

[Michael Snyder]

Stan Shebs wrote:
> 
>    Date: Mon, 6 Apr 1998 13:41:37 +0200 (MET DST)
>    From: "Philippe De Muyter" <phdm@macqel.be>
> 
>    Am I the only one to have (sometimes) the problem of finding a non-executable
>    with the same name earlier in my path than the program I want to debug ?
> 
> Apparently. :-)  But seriously, I don't think this change is a good idea.
> While it would work fine for native Unix debugging, it will lose for
> just about everything else.  For both cross-Unix and embedded debugging
> you almost certainly want the programs *not* to be marked as executable,
> so that your current host doesn't try to execute them.
> 
> However, if you set things up so that this test is only made when
> using a Unix child_ops, this would be a useful addition.

I don't think I have ever had this problem.  Is it not the case
that GDB always looks in the "current working directory" first, 
and only then looks along your path?  (certainly I do not have
"current working directory" on my path!)

If the above is the case, then under what circumstances could 
you have this problem?  The only one that I can think of is if
you were trying to debug something that is NOT in your current
working directory, yet you did NOT give a path to the binary
that you wanted to debug.

In which case, I would have to ask, "why would you want to do that?"

Michael

Re:

[Michael Meissner]

Stan Shebs wrote:

|    Date: Mon, 6 Apr 1998 13:41:37 +0200 (MET DST)
|    From: "Philippe De Muyter" <phdm@macqel.be>
| 
|    Am I the only one to have (sometimes) the problem of finding a non-executable
|    with the same name earlier in my path than the program I want to debug ?
| 
| Apparently. :-)  But seriously, I don't think this change is a good idea.
| While it would work fine for native Unix debugging, it will lose for
| just about everything else.  For both cross-Unix and embedded debugging
| you almost certainly want the programs *not* to be marked as executable,
| so that your current host doesn't try to execute them.

Maybe on YOUR system you don't want them to be marked executable.  On
my 2.1.xx linux system, I just tell the system to run the appropriate
simulator for the binary (for example big and little endian
PowerPC's), so I definately want the executable bit set.

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

No Subject

[Andris Pavenis]

Hi!

Tried gdb-4.17.85 on i586-pc-linux-gnu (with glibc-2.1) and met following
problem that was no with gdb-4.17:

Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
gdb-stderr, etc). As the result if I'm building all except main.c in
object library to use with some IDE that uses gdb for debugging 
(rhide-1.4.7),  I'm getting unresolved references. 

So I'm suggesting rather ugly hack (moving these definitions to top.c
and puting there static constructor that initializes gdb_std*). I agree does
not look nice, but I'm sending it only to point to possible problem.
I cannot use _initialize_* here as files must be defined before running
all _initialize_* procedures.

An alternative idea could be duplicating init code and global vrariables in
rhide.

Andris


--- main.c~1	Wed Feb 24 22:55:05 1999
+++ main.c	Mon Mar  8 16:38:44 1999
@@ -54,18 +54,6 @@
 
 int display_space;
 
-/* Whether this is the command line version or not */
-int tui_version = 0;
-
-/* Whether xdb commands will be handled */
-int xdb_commands = 0;
-
-/* Whether dbx commands will be handled */
-int dbx_commands = 0;
-
-GDB_FILE *gdb_stdout;
-GDB_FILE *gdb_stderr;
-
 /* Whether to enable writing into executable and core files */
 extern int write_files;
 
@@ -161,20 +149,6 @@
 
   getcwd (gdb_dirbuf, sizeof (gdb_dirbuf));
   current_directory = gdb_dirbuf;
-
-  gdb_file_size = sizeof(GDB_FILE);
-
-  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stdout->ts_streamtype = afile;
-  gdb_stdout->ts_filestream = stdout;
-  gdb_stdout->ts_strbuf = NULL;
-  gdb_stdout->ts_buflen = 0;
-
-  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stderr->ts_streamtype = afile;
-  gdb_stderr->ts_filestream = stderr;
-  gdb_stderr->ts_strbuf = NULL;
-  gdb_stderr->ts_buflen = 0;
 
   /* Parse arguments and options.  */
   {
--- top.c~1	Fri Jan 29 11:46:03 1999
+++ top.c	Mon Mar  8 16:37:03 1999
@@ -53,6 +53,19 @@
 
 extern void initialize_utils PARAMS ((void));
 
+
+/* Whether this is the command line version or not */
+int tui_version = 0;
+
+/* Whether xdb commands will be handled */
+int xdb_commands = 0;
+
+/* Whether dbx commands will be handled */
+int dbx_commands = 0;
+
+GDB_FILE *gdb_stdout;
+GDB_FILE *gdb_stderr;
+
 /* Prototypes for local functions */
 
 static void dont_repeat_command PARAMS ((char *, int));
@@ -467,6 +480,28 @@
 SIGJMP_BUF error_return;
 /* Where to go for return_to_top_level (RETURN_QUIT).  */
 SIGJMP_BUF quit_return;
+
+
+
+void __attribute__((constructor))
+_init_gdb_stdio (void)
+{
+  int gdb_file_size;
+  gdb_file_size = sizeof(GDB_FILE);
+
+  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stdout->ts_streamtype = afile;
+  gdb_stdout->ts_filestream = stdout;
+  gdb_stdout->ts_strbuf = NULL;
+  gdb_stdout->ts_buflen = 0;
+
+  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stderr->ts_streamtype = afile;
+  gdb_stderr->ts_filestream = stderr;
+  gdb_stderr->ts_strbuf = NULL;
+  gdb_stderr->ts_buflen = 0;
+}
+
 
 /* Return for reason REASON.  This generally gets back to the command
    loop, but can be caught via catch_errors.  */

No Subject

[Andris Pavenis]

Hi!

Tried gdb-4.17.85 on i586-pc-linux-gnu (with glibc-2.1) and met following
problem that was no with gdb-4.17:

Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
gdb-stderr, etc). As the result if I'm building all except main.c in
object library to use with some IDE that uses gdb for debugging 
(rhide-1.4.7),  I'm getting unresolved references. 

So I'm suggesting rather ugly hack (moving these definitions to top.c
and puting there static constructor that initializes gdb_std*). I agree does
not look nice, but I'm sending it only to point to possible problem.
I cannot use _initialize_* here as files must be defined before running
all _initialize_* procedures.

An alternative idea could be duplicating init code and global vrariables in
rhide.

Andris


--- main.c~1	Wed Feb 24 22:55:05 1999
+++ main.c	Mon Mar  8 16:38:44 1999
@@ -54,18 +54,6 @@
 
 int display_space;
 
-/* Whether this is the command line version or not */
-int tui_version = 0;
-
-/* Whether xdb commands will be handled */
-int xdb_commands = 0;
-
-/* Whether dbx commands will be handled */
-int dbx_commands = 0;
-
-GDB_FILE *gdb_stdout;
-GDB_FILE *gdb_stderr;
-
 /* Whether to enable writing into executable and core files */
 extern int write_files;
 
@@ -161,20 +149,6 @@
 
   getcwd (gdb_dirbuf, sizeof (gdb_dirbuf));
   current_directory = gdb_dirbuf;
-
-  gdb_file_size = sizeof(GDB_FILE);
-
-  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stdout->ts_streamtype = afile;
-  gdb_stdout->ts_filestream = stdout;
-  gdb_stdout->ts_strbuf = NULL;
-  gdb_stdout->ts_buflen = 0;
-
-  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stderr->ts_streamtype = afile;
-  gdb_stderr->ts_filestream = stderr;
-  gdb_stderr->ts_strbuf = NULL;
-  gdb_stderr->ts_buflen = 0;
 
   /* Parse arguments and options.  */
   {
--- top.c~1	Fri Jan 29 11:46:03 1999
+++ top.c	Mon Mar  8 16:37:03 1999
@@ -53,6 +53,19 @@
 
 extern void initialize_utils PARAMS ((void));
 
+
+/* Whether this is the command line version or not */
+int tui_version = 0;
+
+/* Whether xdb commands will be handled */
+int xdb_commands = 0;
+
+/* Whether dbx commands will be handled */
+int dbx_commands = 0;
+
+GDB_FILE *gdb_stdout;
+GDB_FILE *gdb_stderr;
+
 /* Prototypes for local functions */
 
 static void dont_repeat_command PARAMS ((char *, int));
@@ -467,6 +480,28 @@
 SIGJMP_BUF error_return;
 /* Where to go for return_to_top_level (RETURN_QUIT).  */
 SIGJMP_BUF quit_return;
+
+
+
+void __attribute__((constructor))
+_init_gdb_stdio (void)
+{
+  int gdb_file_size;
+  gdb_file_size = sizeof(GDB_FILE);
+
+  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stdout->ts_streamtype = afile;
+  gdb_stdout->ts_filestream = stdout;
+  gdb_stdout->ts_strbuf = NULL;
+  gdb_stdout->ts_buflen = 0;
+
+  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stderr->ts_streamtype = afile;
+  gdb_stderr->ts_filestream = stderr;
+  gdb_stderr->ts_strbuf = NULL;
+  gdb_stderr->ts_buflen = 0;
+}
+
 
 /* Return for reason REASON.  This generally gets back to the command
    loop, but can be caught via catch_errors.  */