Instead of using fork(), call syscall(__NR_fork) in step-fork.c
to avoid looping on powerpc arch in libc.
Signed-off-by: Veaceslav Falico vfal...@redhat.com
---
--- ptrace-tests/tests/step-fork.c 2009-12-01 17:17:14.0 +0100
+++ ptrace-tests/tests/step-fork.c 2009-12-01
Hi -
On Tue, Dec 01, 2009 at 05:11:32PM +0100, Ingo Molnar wrote:
Those facilities are not overlapping with kgdb though so my point doesnt
apply to them. An in-kernel gdb server sure overlaps/extends kgdb
though.
Only in name. One is highly invasive, for debugging the kernel across
serial
On 11/30, Oleg Nesterov wrote:
On 11/29, Roland McGrath wrote:
Please file this test case on bugzilla.redhat.com for Fedora 12 glibc.
https://bugzilla.redhat.com/show_bug.cgi?id=542731
It was closed as NOTABUG, Andreas Schwab wrote:
If you call clone directly you are responsible for
On Tue, Dec 01, 2009 at 05:37:48PM +0100, Veaceslav Falico wrote:
- if (fork () == 0)
+
+ /*
+ * We can't use fork() directly because on powerpc it loops inside libc
on
+ * ptrace over utrace. See http://lkml.org/lkml/2009/11/28/11
+ */
+ if (syscall(__NR_fork)
Instead of using fork(), call syscall(__NR_fork) in step-fork.c
to avoid looping on powerpc arch in libc.
Signed-off-by: Veaceslav Falico vfal...@redhat.com
---
--- a/ptrace-tests/tests/step-fork.c2009-12-01 17:17:14.0 +0100
+++ b/ptrace-tests/tests/step-fork.c2009-12-01
We don't really intend to impose any new requirements on the arch behavior
here. It's up to the arch folks to decide. It does simplify life somewhat
on x86 that you can change the registers at the syscall-entry stop and then
after skipping the syscall, those registers will be unchanged from what
So. Any ptrace test which uses clone() is broken, at least on x86_64.
If you use clone() directly then you need to have the code run in that
child be purely under your control. You can't use miscellaneous libc
calls nor any libpthread calls, only ones you are sure do not require
any thread
On Tue, 2009-11-24 at 21:02 +0100, Oleg Nesterov wrote:
+ sect2 id=reaptitleFinal callbacks/title
+ para
+The functionreport_reap/function callback is always the final event
+in the life cycle of a traced thread. Tracing engines can use this as
+the trigger to clean up their
On Tue, 2009-12-01 at 11:27 -0800, Roland McGrath wrote:
If the powerpc maintainers want to change the behavior here, that is fine
by me. But there is no need for that just to satisfy general ptrace
cleanups (or utrace). Normal concerns require that no such change break
the ptrace behavior
* Frank Ch. Eigler f...@redhat.com wrote:
Hi -
Only in name. One is highly invasive, for debugging the kernel across
serial consoles. The other is highly noninvasive, for debugging user
processes across normal userspace channels. They both happen to talk
to gdb, but that's
On 12/01, Peter Zijlstra wrote:
On Tue, 2009-11-24 at 21:02 +0100, Oleg Nesterov wrote:
+ para
+There is nothing a kernel module can do to keep a structnamestruct
+task_struct/structname alive outside of
+functionrcu_read_lock/function.
Sure there is, get_task_struct()
Could we just drop the tracehook layer if this finally merged
and call the low level functions directly?
We can certainly do appropriate streamlining cleanups later, by all
means. The original purpose of the tracehook layer is simply this:
A person hacking on core kernel code or arch code
Note to all: I'm on the road this week (having had a holiday last week)
and will be somewhat slow in replying on these threads, but I will be
sure to get to them all.
Yes, nobody likes 2 implementations. I guess Roland and me hate
CONFIG_UTRACE much more than anybody else.
:-) We both hate
This above text seems inconsistent. First you say report_reap() is the
final callback and should be used for cleanup, then you say
report_death() is the penultimate callback but might not always happen
and people would normally use that as cleanup.
If we cannot rely on report_death() then I
14 matches
Mail list logo
