* [RFC] win32-nat.c: Improve handling of 'set shell on'
@ 2008-01-09 9:05 Pierre Muller
2008-01-09 12:45 ` Daniel Jacobowitz
2008-01-09 18:56 ` Eli Zaretskii
0 siblings, 2 replies; 7+ messages in thread
From: Pierre Muller @ 2008-01-09 9:05 UTC (permalink / raw)
To: gdb-patches
I recently discovered that if you use
'set shell on' on cygwin native, there are
some specific problems that appear.
I ran the testsuite with a single line
modified:
-static int useshell = 0; /* use shell for subprocesses */
+static int useshell = 1; /* use shell for subprocesses */
Which made the use of shell to start the subprocess
the default.
The testuite results gave this:
--- gdb-cvs.sum 2008-01-08 11:09:16.684999100 +0100
+++ gdb-useshell.sum 2008-01-08 12:22:11.434999100 +0100
<<<< Middle cut >>>
=== gdb Summary ===
-# of expected passes 10522
-# of unexpected failures 514
+# of expected passes 10505
+# of unexpected failures 534
# of expected failures 59
# of known failures 31
# of unresolved testcases 38
Showing that you get 20 unexpected failures
more with 'use shell'
I finally traced the problem down to the fact that
saw_create can sometimes be messed up by
executables that launch other subprocesses.
After adding two new variables holding the main process
id and the shell process id, I changed the code to check that the processed
of the
event reported matches the main_process_id, otherwise
only checking for an EXIT_PROCESS_DEBUG_EVENT for shell_process_id,
even though I do not know if it would be acceptable
that the calling shell exits before the main process.
After that change the testsuite results are much closer
to the results I get without using 'set shell on':
=== gdb Summary ===
-# of expected passes 10522
-# of unexpected failures 514
+# of expected passes 10517
+# of unexpected failures 519
# of expected failures 59
# of known failures 31
# of unresolved testcases 38
Only 5 more failures instead of 20.
I send below the patch as I used it to check the testsuite results,
the second change, which sets the use of shell as a default,
would of course not be in my final patch...
Pierre Muller
PS: Is it possible to run the testsuite with a custom
script added ? This would facilitate testing of
other such options like 'set new-group'?
The testsuite uses --nx option which disables
reading of .gdbinit file, but is it possible to
add some other default option?
like "-x MySpecficOptionsFile".
Can that be set? How?
Which tests would fail because of this?
ChangeLog entry:
2008-01-09 Pierre Muller <muller@ics.u-strasbg.fr>
* win32-nat.c (main_process_id, shell_process_id) New variables.
// Not to be committed: Set default value of useshell to 1
(fake_create_process): Set main_process_id.
(get_win32_debug_event): only handle event if
current_event.dwProcessId is equal to main_process_id,
and EXIT_PROCESS_DEBUG_EVENT event if
current_event.dwProcessId is equal to shell_process_id.
(do_initial_win32_stuff) Set shell_process_id or
main_process_id depending on saw_create value.
(win32_mourn_inferior) wait until EXIT_PROCESS_DEBUG_EVENT
for shell_process_id is seen if shell_process_id is set.
(win32_kill_inferior) wait for EXIT_PROCESS_DEBUG_EVENT
for main_process_id and shell_process_id if shell_process_id is set.
Index: gdb/win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.146
diff -u -p -r1.146 win32-nat.c
--- gdb/win32-nat.c 6 Jan 2008 06:59:14 -0000 1.146
+++ gdb/win32-nat.c 9 Jan 2008 08:38:57 -0000
@@ -137,6 +137,8 @@ static DEBUG_EVENT current_event; /* The
static HANDLE current_process_handle; /* Currently executing process */
static thread_info *current_thread; /* Info on currently selected thread
*/
static DWORD main_thread_id; /* Thread ID of the main thread */
+static DWORD main_process_id; /* Process ID of debugged process */
+static DWORD shell_process_id; /* Process ID of the shell */
/* Counts of things. */
static int exception_count = 0;
@@ -154,7 +156,7 @@ static int debug_exec = 0; /* show exec
static int debug_events = 0; /* show events from kernel */
static int debug_memory = 0; /* show target memory accesses */
static int debug_exceptions = 0; /* show target exceptions */
-static int useshell = 0; /* use shell for subprocesses */
+static int useshell = 1; /* use shell for subprocesses */
/* This vector maps GDB's idea of a register's number into an address
in the win32 exception context vector.
@@ -1176,6 +1178,7 @@ fake_create_process (void)
/* We can not debug anything in that case. */
}
main_thread_id = current_event.dwThreadId;
+ main_process_id = current_event.dwProcessId;
current_thread = win32_add_thread (main_thread_id,
current_event.u.CreateThread.hThread);
return main_thread_id;
@@ -1295,19 +1298,23 @@ get_win32_debug_event (int pid, struct t
(unsigned) current_event.dwProcessId,
(unsigned) current_event.dwThreadId,
"CREATE_THREAD_DEBUG_EVENT"));
- if (saw_create != 1)
+ if (saw_create < 1)
{
if (!saw_create && attach_flag)
{
/* Kludge around a Windows bug where first event is a create
thread event. Caused when attached process does not have
a main thread. */
+
retval = ourstatus->value.related_pid = fake_create_process
();
- if (retval)
- saw_create++;
+ if (retval)
+ saw_create++;
}
break;
}
+ if (current_event.dwProcessId != main_process_id)
+ break;
+
/* Record the existence of this thread */
th = win32_add_thread (current_event.dwThreadId,
current_event.u.CreateThread.hThread);
@@ -1323,6 +1330,8 @@ get_win32_debug_event (int pid, struct t
(unsigned) current_event.dwProcessId,
(unsigned) current_event.dwThreadId,
"EXIT_THREAD_DEBUG_EVENT"));
+ if (current_event.dwProcessId != main_process_id)
+ break;
if (current_event.dwThreadId != main_thread_id)
{
win32_delete_thread (current_event.dwThreadId);
@@ -1339,6 +1348,7 @@ get_win32_debug_event (int pid, struct t
if (++saw_create != 1)
break;
+ main_process_id = current_event.dwProcessId;
current_process_handle = current_event.u.CreateProcessInfo.hProcess;
if (main_thread_id)
win32_delete_thread (main_thread_id);
@@ -1354,8 +1364,16 @@ get_win32_debug_event (int pid, struct t
(unsigned) current_event.dwProcessId,
(unsigned) current_event.dwThreadId,
"EXIT_PROCESS_DEBUG_EVENT"));
- if (saw_create != 1)
- break;
+ if (current_event.dwProcessId != main_process_id)
+ {
+ if (saw_create > 1)
+ --saw_create;
+ if (current_event.dwProcessId == shell_process_id)
+ shell_process_id = 0;
+ break;
+ }
+ if (shell_process_id)
+ main_process_id = 0;
ourstatus->kind = TARGET_WAITKIND_EXITED;
ourstatus->value.integer = current_event.u.ExitProcess.dwExitCode;
retval = main_thread_id;
@@ -1367,7 +1385,7 @@ get_win32_debug_event (int pid, struct t
(unsigned) current_event.dwThreadId,
"LOAD_DLL_DEBUG_EVENT"));
CloseHandle (current_event.u.LoadDll.hFile);
- if (saw_create != 1)
+ if (current_event.dwProcessId != main_process_id)
break;
catch_errors (handle_load_dll, NULL, (char *) "", RETURN_MASK_ALL);
ourstatus->kind = TARGET_WAITKIND_LOADED;
@@ -1380,7 +1398,7 @@ get_win32_debug_event (int pid, struct t
(unsigned) current_event.dwProcessId,
(unsigned) current_event.dwThreadId,
"UNLOAD_DLL_DEBUG_EVENT"));
- if (saw_create != 1)
+ if (current_event.dwProcessId != main_process_id)
break;
catch_errors (handle_unload_dll, NULL, (char *) "", RETURN_MASK_ALL);
ourstatus->kind = TARGET_WAITKIND_LOADED;
@@ -1393,7 +1411,7 @@ get_win32_debug_event (int pid, struct t
(unsigned) current_event.dwProcessId,
(unsigned) current_event.dwThreadId,
"EXCEPTION_DEBUG_EVENT"));
- if (saw_create != 1)
+ if (current_event.dwProcessId != main_process_id)
break;
switch (handle_exception (ourstatus))
{
@@ -1415,13 +1433,13 @@ get_win32_debug_event (int pid, struct t
(unsigned) current_event.dwProcessId,
(unsigned) current_event.dwThreadId,
"OUTPUT_DEBUG_STRING_EVENT"));
- if (saw_create != 1)
+ if (current_event.dwProcessId != main_process_id)
break;
retval = handle_output_debug_string (ourstatus);
break;
default:
- if (saw_create != 1)
+ if (current_event.dwProcessId != main_process_id)
break;
printf_unfiltered ("gdb: kernel event for pid=%ld tid=%ld\n",
(DWORD) current_event.dwProcessId,
@@ -1431,7 +1449,7 @@ get_win32_debug_event (int pid, struct t
break;
}
- if (!retval || saw_create != 1)
+ if (!retval || saw_create < 1)
{
if (continue_status == -1)
win32_resume (ptid, 0, 1);
@@ -1486,6 +1504,14 @@ do_initial_win32_stuff (DWORD pid)
extern int stop_after_trap;
int i;
+ main_process_id = 0;
+ main_thread_id = 0;
+ shell_process_id = 0;
+
+ if (saw_create == -1)
+ shell_process_id = pid;
+ else
+ main_process_id = pid;
last_sig = TARGET_SIGNAL_0;
event_count = 0;
exception_count = 0;
@@ -1893,7 +1919,39 @@ win32_create_inferior (char *exec_file,
static void
win32_mourn_inferior (void)
{
+ /* If shell_process_id is set, we need to wait until
+ EXIT_PROCESS_DEBUG_EVENT for the shell process comes. */
+ if (shell_process_id)
+ {
+ for (;;)
+ {
+ if (!win32_continue (DBG_CONTINUE, -1))
+ break;
+ if (!WaitForDebugEvent (¤t_event, INFINITE))
+ break;
+ if (current_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT)
+ {
+ DEBUG_EVENTS (("gdb: kernel event for pid=%d tid=%d
code=%s)\n",
+ (unsigned) current_event.dwProcessId,
+ (unsigned) current_event.dwThreadId,
+ "EXIT_PROCESS_DEBUG_EVENT"));
+ if (current_event.dwProcessId == shell_process_id)
+ shell_process_id = 0;
+ if (current_event.dwProcessId == main_process_id)
+ main_process_id = 0;
+ if (main_process_id == 0 && shell_process_id == 0)
+ break;
+ }
+ else
+ DEBUG_EVENTS (("gdb: kernel event for pid=%d tid=%d code=%d)\n",
+ (unsigned) current_event.dwProcessId,
+ (unsigned) current_event.dwThreadId,
+ (unsigned) current_event.dwDebugEventCode));
+ }
+ };
+
(void) win32_continue (DBG_CONTINUE, -1);
+
i386_cleanup_dregs();
if (open_process_used)
{
@@ -1956,7 +2014,25 @@ win32_kill_inferior (void)
if (!WaitForDebugEvent (¤t_event, INFINITE))
break;
if (current_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT)
- break;
+ {
+ DEBUG_EVENTS (("gdb: kernel event for pid=%d tid=%d code=%s)\n",
+ (unsigned) current_event.dwProcessId,
+ (unsigned) current_event.dwThreadId,
+ "EXIT_PROCESS_DEBUG_EVENT"));
+
+ if (current_event.dwProcessId == shell_process_id)
+ shell_process_id = 0;
+ if (current_event.dwProcessId == main_process_id)
+ main_process_id = 0;
+ if (main_process_id == 0 && shell_process_id == 0)
+ break;
+ }
+ else
+ DEBUG_EVENTS (("gdb: kernel event for pid=%d tid=%d code=%d)\n",
+ (unsigned) current_event.dwProcessId,
+ (unsigned) current_event.dwThreadId,
+ (unsigned) current_event.dwDebugEventCode));
+
}
target_mourn_inferior (); /* or just win32_mourn_inferior? */
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC] win32-nat.c: Improve handling of 'set shell on'
2008-01-09 9:05 [RFC] win32-nat.c: Improve handling of 'set shell on' Pierre Muller
@ 2008-01-09 12:45 ` Daniel Jacobowitz
2008-01-09 18:56 ` Eli Zaretskii
1 sibling, 0 replies; 7+ messages in thread
From: Daniel Jacobowitz @ 2008-01-09 12:45 UTC (permalink / raw)
To: Pierre Muller; +Cc: gdb-patches
On Wed, Jan 09, 2008 at 10:04:35AM +0100, Pierre Muller wrote:
> PS: Is it possible to run the testsuite with a custom
> script added ? This would facilitate testing of
> other such options like 'set new-group'?
> The testsuite uses --nx option which disables
> reading of .gdbinit file, but is it possible to
> add some other default option?
> like "-x MySpecficOptionsFile".
Try runtest GDBFLAGS="-nx -ex 'set new-group 1'".
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] win32-nat.c: Improve handling of 'set shell on'
2008-01-09 9:05 [RFC] win32-nat.c: Improve handling of 'set shell on' Pierre Muller
2008-01-09 12:45 ` Daniel Jacobowitz
@ 2008-01-09 18:56 ` Eli Zaretskii
2008-01-09 20:04 ` Joel Brobecker
2008-01-10 1:53 ` Christopher Faylor
1 sibling, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2008-01-09 18:56 UTC (permalink / raw)
To: Pierre Muller; +Cc: gdb-patches
> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Date: Wed, 9 Jan 2008 10:04:35 +0100
>
> I recently discovered that if you use
> 'set shell on' on cygwin native, there are
> some specific problems that appear.
>
> I ran the testsuite with a single line
> modified:
> -static int useshell = 0; /* use shell for subprocesses */
> +static int useshell = 1; /* use shell for subprocesses */
> Which made the use of shell to start the subprocess
> the default.
Is this really appropriate for the native Windows port of GDB as well
as for Cygwin? If not, we should set this only conditionally, I
think.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] win32-nat.c: Improve handling of 'set shell on'
2008-01-09 18:56 ` Eli Zaretskii
@ 2008-01-09 20:04 ` Joel Brobecker
2008-01-10 8:58 ` Pierre Muller
2008-01-10 1:53 ` Christopher Faylor
1 sibling, 1 reply; 7+ messages in thread
From: Joel Brobecker @ 2008-01-09 20:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Pierre Muller, gdb-patches
> > I ran the testsuite with a single line
> > modified:
> > -static int useshell = 0; /* use shell for subprocesses */
> > +static int useshell = 1; /* use shell for subprocesses */
> > Which made the use of shell to start the subprocess
> > the default.
>
> Is this really appropriate for the native Windows port of GDB as well
> as for Cygwin? If not, we should set this only conditionally, I
> think.
I understood that this part of the patch was NOT to be committed
(from a // comment in the ChangeLog IIRC). After having explained
how the patch was tested, I would have excluded that hunk from
the patch, IMO.
--
Joel
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [RFC] win32-nat.c: Improve handling of 'set shell on'
2008-01-09 20:04 ` Joel Brobecker
@ 2008-01-10 8:58 ` Pierre Muller
0 siblings, 0 replies; 7+ messages in thread
From: Pierre Muller @ 2008-01-10 8:58 UTC (permalink / raw)
To: 'Joel Brobecker', 'Eli Zaretskii'; +Cc: gdb-patches
Joel is right,
I just sent the patch with that line so that
by just applying the patch,
someone could really test the effect of the patch.
If you remove that line, the default stays to
not use shell, and thus running the testsuite
does not show any change, as there are no tests
using 'set shell on'.
In fact, as Daniel explained in his first
answer to this thread, it is possible to
run the testsuite with
make check "RUNTESTFLAGS=GDBFLAGS=\"--nx -ex 'set shell on'\""
which removes the need of changing the default value
to useshell static variable.
Anyhow, this is only a RFC.
Christopher, do you want me to resend another RFC
or will you give your comments on that one?
Pierre
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] win32-nat.c: Improve handling of 'set shell on'
2008-01-09 18:56 ` Eli Zaretskii
2008-01-09 20:04 ` Joel Brobecker
@ 2008-01-10 1:53 ` Christopher Faylor
2008-01-10 4:27 ` Eli Zaretskii
1 sibling, 1 reply; 7+ messages in thread
From: Christopher Faylor @ 2008-01-10 1:53 UTC (permalink / raw)
To: gdb-patches, Pierre Muller, Eli Zaretskii
On Wed, Jan 09, 2008 at 08:54:51PM +0200, Eli Zaretskii wrote:
>> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
>> Date: Wed, 9 Jan 2008 10:04:35 +0100
>>
>> I recently discovered that if you use
>> 'set shell on' on cygwin native, there are
>> some specific problems that appear.
>>
>> I ran the testsuite with a single line
>> modified:
>> -static int useshell = 0; /* use shell for subprocesses */
>> +static int useshell = 1; /* use shell for subprocesses */
>> Which made the use of shell to start the subprocess
>> the default.
>
>Is this really appropriate for the native Windows port of GDB as well
>as for Cygwin?
No. In fact, this really doesn't work all that well at all, AFAIK. The
current code represents my initial attempt to get it working but there
were problems which led me to believe that I needed to add some help in
Cygwin itself. I think that the main reason for wanting to use the
shell would be to interpret redirection and quoting characters and, last
I checked, that was not right. That's why it defaults to false.
cgf
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-01-10 8:58 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-09 9:05 [RFC] win32-nat.c: Improve handling of 'set shell on' Pierre Muller
2008-01-09 12:45 ` Daniel Jacobowitz
2008-01-09 18:56 ` Eli Zaretskii
2008-01-09 20:04 ` Joel Brobecker
2008-01-10 8:58 ` Pierre Muller
2008-01-10 1:53 ` Christopher Faylor
2008-01-10 4:27 ` Eli Zaretskii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox