Thanks for pointing out. Sorry for the false alarm.
On Wed, 09 Dec 2009 19:12:41 +0100, Oleg Nesterov wrote:
while the '.func_name' is the text address.
tried to change the code to
REGS_ACCESS (regs, nip) = (unsigned long) .raise_sigusr2
but gcc doesn't like this ;)
...
Yes, I verified the patch below fixes step-jump-cont.c on
On 12/08, Ananth N Mavinakayanahalli wrote:
On Mon, Dec 07, 2009 at 07:05:40PM +0100, Oleg Nesterov wrote:
On 12/07, Oleg Nesterov wrote:
On 12/07, Jan Kratochvil wrote:
On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote:
But. raise_sigusr2 is not equal to the actual
On Mon, Dec 07, 2009 at 01:43:27PM +0100, Oleg Nesterov wrote:
On 12/06, CAI Qian wrote:
Ananth, could you please confirm once again that step-jump-cont (from
ptrace-tests testsuite) not fail on your machine? If yes, please tell
me the version of glibc/gcc. Is PTRACE_GETREGS defined on your
On Mon, Dec 07, 2009 at 07:05:40PM +0100, Oleg Nesterov wrote:
On 12/07, Oleg Nesterov wrote:
On 12/07, Jan Kratochvil wrote:
On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote:
But. raise_sigusr2 is not equal to the actual address of
raise_sigusr2(),
this value points
I'll try to investigate, but currently I am all confused, and I
suspect we have some user-space issues. If only I knew something about ppc...
Sorry for the confusing.
Ananth, could you please confirm once again that step-jump-cont (from
ptrace-tests testsuite) not fail on your machine? If
On 12/07, caiq...@redhat.com wrote:
Ananth, could you please confirm once again that step-jump-cont (from
ptrace-tests testsuite) not fail on your machine? If yes, please tell
me the version of glibc/gcc. Is PTRACE_GETREGS defined on your
machine?
Funny enough. The above failure only
On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote:
But. raise_sigusr2 is not equal to the actual address of raise_sigusr2(),
this value points to the thunk (I do not know the correct English term)
ppc64 calls it function descriptor (GDB
ppc64_linux_convert_from_func_ptr_addr):
For
On 12/07, Jan Kratochvil wrote:
On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote:
But. raise_sigusr2 is not equal to the actual address of
raise_sigusr2(),
this value points to the thunk (I do not know the correct English term)
ppc64 calls it function descriptor (GDB
On 12/07, Oleg Nesterov wrote:
On 12/07, Jan Kratochvil wrote:
On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote:
But. raise_sigusr2 is not equal to the actual address of
raise_sigusr2(),
this value points to the thunk (I do not know the correct English term)
ppc64 calls
${dir}$tst
FAIL: step-jump-cont
Could you please confirm that if you revert this
[PATCH] utrace: don't set -ops = utrace_detached_ops lockless
change the kernel passes the test? This is just impossible that this
patch could make any difference for this test-case.
You can login
Could you please confirm that if you revert this
[PATCH] utrace: don't set -ops = utrace_detached_ops lockless
change the kernel passes the test? This is just impossible that this
patch could make any difference for this test-case.
No, it is the same. It is true also for kernels
I was going to try again, but noticed you already recompiled and
booted the kernel. I see ./test is running and there is nothing bad
in dmesg ;)
Yes, it looks good so far. Ptrace tests also does not show any regression. I
kicked off a few tests on other platform, so hopefully have more
Yes, it looks good so far. Ptrace tests also does not show any
regression.
I said this too early. Looks like step-jump-count started to fail now.
step-jump-cont: step-jump-cont.c:244: main: Assertion `0' failed.
/bin/sh: line 5: 28212 Aborted ${dir}$tst
FAIL: step-jump-cont
On 12/05, caiq...@redhat.com wrote:
Yes, it looks good so far. Ptrace tests also does not show any
regression.
I said this too early. Looks like step-jump-count started to fail now.
step-jump-cont: step-jump-cont.c:244: main: Assertion `0' failed.
/bin/sh: line 5: 28212 Aborted
agree with the patch?
--
[PATCH] utrace: don't set -ops = utrace_detached_ops lockless
finish_callback_report() changes -ops lockless. Imho this is not
right in general, the state of !EXIT_DEAD tracee must be stable
under
://www.redhat.com/archives/utrace-devel/2009-October/msg00180.html
We already discussed this, but forgot to finish.
Do you agree with the patch?
--
[PATCH] utrace: don't set -ops = utrace_detached_ops lockless
I forgot that there is another issue (iirc a bit discussed too).
finish_callback_report() sets -ops = utrace_detached_ops lockless!
You'll have to remind me why this is a problem.
Re: [PATCH 85] ptrace_attach_task: rely on utrace_barrier(), don't
check -ops
18 matches
Mail list logo
