[uml-devel] 2.6.11-rc1 ...

[uml-devel] 2.6.11-rc1 ...

[Gerd Knorr]

  Hi,

Anyone looked at 2.6.11-rc1 for the host?  Some more ptrace cleanups
happened there, and one of the changes conflicts with the sysemu code in
the skas-v7 patch for 2.6.10.  To me it's not clear how to solve that
conflict as I'm not familier with the sysemu stuff and how these tree
trace flags (syscall, sysemu, singlestep) play together ...

The conflicting changeset is attached below for reference.  There are
also some more ptrace changes (for singlestep) which might need fixups
in sysemu.

  Gerd

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/01 12:24:01-08:00 torvalds@evo.osdl.org 
#   x86: common send_sigtrap helper for debug event SIGTRAP's,
#   and use that for system call single-step events.
#   
#   This one also gets the user mode test right, and makes sure
#   the siginfo is not leaking any stack contents.
# 
# include/asm-i386/ptrace.h
#   2005/01/01 12:23:50-08:00 torvalds@evo.osdl.org +2 -0
#   x86: common send_sigtrap helper for debug event SIGTRAP's,
#   and use that for system call single-step events.
#   
#   This one also gets the user mode test right, and makes sure
#   the siginfo is not leaking any stack contents.
# 
# arch/i386/kernel/traps.c
#   2005/01/01 12:23:50-08:00 torvalds@evo.osdl.org +1 -13
#   x86: common send_sigtrap helper for debug event SIGTRAP's,
#   and use that for system call single-step events.
#   
#   This one also gets the user mode test right, and makes sure
#   the siginfo is not leaking any stack contents.
# 
# arch/i386/kernel/ptrace.c
#   2005/01/01 12:23:50-08:00 torvalds@evo.osdl.org +27 -5
#   x86: common send_sigtrap helper for debug event SIGTRAP's,
#   and use that for system call single-step events.
#   
#   This one also gets the user mode test right, and makes sure
#   the siginfo is not leaking any stack contents.
# 
diff -Nru a/arch/i386/kernel/ptrace.c b/arch/i386/kernel/ptrace.c
--- a/arch/i386/kernel/ptrace.c	2005-01-21 12:08:33 +01:00
+++ b/arch/i386/kernel/ptrace.c	2005-01-21 12:08:33 +01:00
@@ -553,6 +553,24 @@
 	return ret;
 }
 
+void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs, int error_code)
+{
+	struct siginfo info;
+
+	tsk->thread.trap_no = 1;
+	tsk->thread.error_code = error_code;
+
+	memset(&info, 0, sizeof(info));
+	info.si_signo = SIGTRAP;
+	info.si_code = TRAP_BRKPT;
+
+	/* User-mode eip? */
+	info.si_addr = user_mode(regs) ? (void __user *) regs->eip : NULL;
+
+	/* Send us the fakey SIGTRAP */
+	force_sig_info(SIGTRAP, &info, tsk);
+}
+
 /* notification of system call entry/exit
  * - triggered by current->work.syscall_trace
  */
@@ -568,15 +586,19 @@
 			audit_syscall_exit(current, regs->eax);
 	}
 
-	if (!test_thread_flag(TIF_SYSCALL_TRACE) &&
-	    !test_thread_flag(TIF_SINGLESTEP))
-		return;
 	if (!(current->ptrace & PT_PTRACED))
 		return;
+
+	/* Fake a debug trap */
+	if (test_thread_flag(TIF_SINGLESTEP))
+		send_sigtrap(current, regs, 0);
+
+	if (!test_thread_flag(TIF_SYSCALL_TRACE))
+		return;
+
 	/* the 0x80 provides a way for the tracing parent to distinguish
 	   between a syscall stop and SIGTRAP delivery */
-	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD) &&
-				 !test_thread_flag(TIF_SINGLESTEP) ? 0x80 : 0));
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
 
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
diff -Nru a/arch/i386/kernel/traps.c b/arch/i386/kernel/traps.c
--- a/arch/i386/kernel/traps.c	2005-01-21 12:08:33 +01:00
+++ b/arch/i386/kernel/traps.c	2005-01-21 12:08:33 +01:00
@@ -682,7 +682,6 @@
 {
 	unsigned int condition;
 	struct task_struct *tsk = current;
-	siginfo_t info;
 
 	__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));
 
@@ -723,18 +722,7 @@
 	}
 
 	/* Ok, finally something we can handle */
-	tsk->thread.trap_no = 1;
-	tsk->thread.error_code = error_code;
-	info.si_signo = SIGTRAP;
-	info.si_errno = 0;
-	info.si_code = TRAP_BRKPT;
-	
-	/* If this is a kernel mode trap, save the user PC on entry to 
-	 * the kernel, that's what the debugger can make sense of.
-	 */
-	info.si_addr = ((regs->xcs & 3) == 0) ? (void __user *)tsk->thread.eip
-	                                      : (void __user *)regs->eip;
-	force_sig_info(SIGTRAP, &info, tsk);
+	send_sigtrap(tsk, regs, error_code);
 
 	/* Disable additional traps. They'll be re-enabled when
 	 * the signal is delivered.
diff -Nru a/include/asm-i386/ptrace.h b/include/asm-i386/ptrace.h
--- a/include/asm-i386/ptrace.h	2005-01-21 12:08:33 +01:00
+++ b/include/asm-i386/ptrace.h	2005-01-21 12:08:33 +01:00
@@ -55,6 +55,8 @@
 #define PTRACE_SET_THREAD_AREA    26
 
 #ifdef __KERNEL__
+struct task_struct;
+extern void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs, int error_code);
 #define user_mode(regs) ((VM_MASK & (regs)->eflags) || (3 & (regs)->xcs))
 #define instruction_pointer(regs) ((regs)->eip)
 #if defined(CONFIG_SMP) && defined(CONFIG_FRAME_POINTER)


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] 2.6.11-rc1 ...

[Blaisorblade]

On Friday 21 January 2005 13:15, Gerd Knorr wrote:
>   Hi,
>
> Anyone looked at 2.6.11-rc1 for the host?  Some more ptrace cleanups
> happened there, and one of the changes conflicts with the sysemu code in
> the skas-v7 patch for 2.6.10.  To me it's not clear how to solve that
> conflict as I'm not familier with the sysemu stuff and how these tree
> trace flags (syscall, sysemu, singlestep) play together ...

> The conflicting changeset is attached below for reference.  There are
> also some more ptrace changes (for singlestep) which might need fixups
> in sysemu.

>   Gerd

I've already solved those conflict earlier on -rc1 (not tested) but I didn't 
polish it out yet... if you are in a hurry, I can finish it and post the 
result today on the ML. If not, I'll publish it later.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

RE: [uml-devel] 2.6.11-rc1 ...

[Anthony Brock]

Blaisorblade wrote:
> On Friday 21 January 2005 13:15, Gerd Knorr wrote:
>>   Hi,
>>
>> Anyone looked at 2.6.11-rc1 for the host?  Some more ptrace cleanups
>> happened there, and one of the changes conflicts with the sysemu code in
>> the skas-v7 patch for 2.6.10.  To me it's not clear how to solve that
>> conflict as I'm not familier with the sysemu stuff and how these tree
>> trace flags (syscall, sysemu, singlestep) play together ...
>
>> The conflicting changeset is attached below for reference.  There are
>> also some more ptrace changes (for singlestep) which might need fixups
>> in sysemu.
>
>>   Gerd
>
> I've already solved those conflict earlier on -rc1 (not tested) but I
didn't
> polish it out yet... if you are in a hurry, I can finish it and post the
> result today on the ML. If not, I'll publish it later.

Blaisor,

Have you published your solution to the skas-v7 conflicts with the
2.6.11-rc1 kernel? Even better, I would like to try the 2.6.11-rc2 or
2.6.11-rc2-bk7 kernels as a skas-enabled host. Thanks!

Tony



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Ported SKAS3-v7 (and partially -V8) for 2.6.11. Uncleanness about SYSEMU_SINGLESTEP

[Blaisorblade]

On Wednesday 09 February 2005 18:33, Gerd Knorr wrote:
> > > Anyone looked at 2.6.11-rc1 for the host?  Some more ptrace cleanups
> >
> > I've already solved those conflict earlier on -rc1 (not tested) but I
> > didn't polish it out yet... if you are in a hurry, I can finish it and
> > post the result today on the ML. If not, I'll publish it later.
>
> Was busy with other stuff recently, but next days I plan to look at this
> again.  I've seen you released skas v8 meanwhile, but for 2.6.9 only.
> If you have a 2.6.11-rc patch as well already that would be very nice.
I've just done a -V7 for -rc3-bk6... I've called it -V7-rc1 because 
potentially something could go wrong (in general, and for this special 
kernel).

I've also added three patches from the V8-rc1 for 2.6.9 (so it's actually a 
-V7a: versioning is fscking up). I've not yet added the SYSEMU_SINGLESTEP 
support, because it seemed me a bit unclean even in 2.6.9, so even porting it 
cleanly to 2.6.10 is a bit hard (C. Aker did the porting, and , but in that 
form it is not up-to-date with the introduction of the set/clear_singlestep 
accessors).

The problem is that PTRACE_SYSEMU_SINGLESTEP is put together with 
PTRACE_SYSCALL, not with PTRACE_SINGLESTEP... I understand in 2.6.7 it maybe 
made sense (SINGLESTEP had a different behaviour then, problems when 
singlestepping syscalls) but it's unclean in 2.6.9 and does not port well to 
2.6.10, as said (... unless I miss something, I'm going to cleanup this for 
2.6.9 and for 2.6.10.

For 2.6.7 I would rawly use your version, unless I discovered any bugs during 
the cleanup (backporting cleanups is useless IMHO, unless for other reasons 
like keeping things in sync).
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel