Daniel Jacobowitz wrote:
>On Mon, Mar 17, 2003 at 03:24:55PM -0600, Rajesh Rajamani wrote:
>
>
>>Hi All,
>>I'm working on adding a function
>>
>>void debugbreak(void);
>>
>>to glibc. I got the inspiration for this from Windows. Windows has a
>>DebugBreak() function, which when invoked from a process, spawns a
>>debugger, which then attaches to the process. I think this would be
>>invaluable to linux developers in situations where they currently have to
>>put an infinite loop and attach to a running process (say, to stop in a
>>library that has been LD_PRELOADed).
>>
>>To this end, I've been experimenting and found out that gdb can't attach
>>to a process that has been stopped. I'd like to send a SIGSTOP as soon as
>>debugbreak() is invoked, so that all threads are stopped in a state close
>>to the one they were in, when the debugbreak() was invoked.
>>
>>I spoke to Vic Zandy about this and he informed me that he had submitted a patch
>> that would allow ptrace to attach to stopped processes also (the thread of
>>discussion is pasted below). I believe the patch was not accepted at that time.
>> I was wondering what the official line on this is? If there are no serious
>>objections, will the community consider accepting the patch? It would go a long
>>way in helping me accomplish my goal.
>>
>>
>
>The question is, what _should_ happen when yu attach to a stopped
>process? If the tracer receives the same one SIGSTOP that it normally
>would, then it will just resume the program as if it weren't stopped.
>Does that make sense or not?
>
Ideally, a stopped process should not be resumed, until it receives a
SIGCONT. I ran two tests to understand the effect of this patch.
1. Attaching to a stopped process using gdb. This did not cause the
tracee to continue.
2. stracing a stopped process. This caused the stopped process to
continue. On further investigation, I found out that strace calls
ptrace(PTRACE_SYSCALL), which restarts the child, but arranges for the
child to be stopped at the next entry to or exit from a system call.
IMHO, the new ptrace semantics adds a feature to strace. If someone
tries to run strace a stopped process without the patch, it will just
hang, whereas with the patch, it'll let the process continue. Even
without the patch, if a process that sends itself a SIGCONT is straced,
the process will not stop. I do not think this is an issue, considering
that ppl will not get any info by running strace on a stopped process,
until they send a SIGCONT.
In conclusion, the action taken by the tracer depends on the mechanism
it uses for monitoring the system calls. That said, it'll definitely be
useful if the tracer could find out the state of the tracee at the time
of attachment and take appropriate action. Given below, is a port of
Vic's patch to 2.5.xx series -
--------------------------------------------------------------------------------
-- kernel/ptrace.c 2003-03-23 22:15:33.000000000 -0800
+++ kernel/ptrace.c 2003-03-23 22:19:27.000000000 -0800
@@ -115,7 +115,10 @@
__ptrace_link(task, current);
write_unlock_irq(&tasklist_lock);
- force_sig_specific(SIGSTOP, task);
+ if (task->state != TASK_STOPPED)
+ force_sig_specific(SIGSTOP, task);
+ else
+ task->exit_code = SIGSTOP;
return 0;
bad:
--------------------------------------------------------------------
Thanks,
Raj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:14 EST