Re: linux-next: add utrace tree
Tom Tromey tro...@redhat.com writes: * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb. Internally we're already using a self-pipe to integrate this into gdb's main loop. Relatedly, don't mess with the inferior's parentage. How would having a kernel based solution be better over your user space simulation? BTW there's the new signalfd() system call that might do it (haven't checked if it works for SIGCHLD) * Support displaced stepping in the kernel; I think this would improve performance when debugging in non-stop mode. Not sure what displaced stepping is exactly, but it sounds like the branch tracing extensions that got added a few releases ago? On modern Intel chips they give you a branch buffer in memory. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: linux-next: add utrace tree
The problem is that anything that is based on reparenting and signals is fundamentally a one parent only kind of interface. See? I was actually thinking about that before I wrote the email. But when I did that i couldn't come up with a good scenario where multiple debuggers actually make sense. In a sense being a debugger is really a very intimate thing for process. Do you really want to have multiple of them messing with each other? If yes how would they know what to touch and what not? The only thing I could think of was user space virtualization (like old UML) together with a real debugger, but frankly these solutions all seemed like big race conditions to me anyways and should be better done in the kernel or below it, so I have a hard time taking them seriously. Can you think of any scenario where multiple debuggers on a process make sense? -Andi
Re: linux-next: add utrace tree
Simple example. Try to debug/strace strace ot gdb itself. Not trivial, you can't attach to strace's tracees. Recently I spent 2 days trying to understand why strace -f hangs. I was able to attach to strace, but I wasn't able to see what its tracees do. But what would the semantics be inside the tracees even if you could? And, it was not possible to even trace strace until it hangs, with ptrace the tracee (strace) must stop to report the event and this shadowed the race. Shadowing the race was the second surname of strace I thought anyways @) Basically if you care about races never use strace in the first place. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
Peter Zijlstra pet...@infradead.org writes: With CPL2 or RPL on user segments the protection issue seems to be manageable for running the instructions from kernel space. Nope -- it doesn't work on 64bit and even on 32bit can have large costs on some CPUs. Also designing 32bit only features in 2010 would seem rather unfortunate. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [RFC,PATCH 14/14] utrace core
This is subjective, but personally I disagree. Contrary, imho it is good that tracehook hides the (simple) details. I do not understand why the reader of, say, do_fork() should see the contents of tracehook_report_clone_complete(). This will complicate the understanding. Someone who has to debug or review fork needs to know what's going on. Yes they can find out by going through inlines, but that just costs more time and distracts from the actual problem. Those people who want to understand/change fork() do not care about utrace/ptrace usually. And please note that it is much, much easier to change this code when it lives in tracehooks.h instead of sched.c/signal.c/etc. The problem is that when you have to trace this code when something goes wrong the extra layer just holds you up. For debugging usually abstraction is a bad idea. My experience is also that in general such extra abstraction layers are frowned upon in Linux kernel code style. For example when new vendor drivers are submitted for hardware like NICs etc, they frequently tend to have all kinds of abstraction layers. Typically the first step to linuxify them is to get rid of those. This makes the code more readable, shorter, better to debug and read. Another classic example is: lock_foo() is frowned upon (Linus tends to always complain about that), rather prefer spin_lock(foo_lock) or mutex_lock(foo_lock) that makes it clear what's going on. I don't see why this should be any different for utrace. Less code obfuscation. When it's a utrace call, call it a utrace call, not something else. Why do you think this is obfuscation? Well, we can rename these helpers, s/tracehook_/utrace_/, but I don't see how this can make the code more readable. Because the inlines do not add anything to functionality and actually hide what the code does, that is obfuscation. For you it might be obvious because you've been hacking that code for quite some time, but for someone who is not in your position that's different. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [RFC,PATCH 14/14] utrace core
Oleg Nesterov o...@redhat.com writes: From: Roland McGrath rol...@redhat.com This adds the utrace facility, a new modular interface in the kernel for implementing user thread tracing and debugging. This fits on top of the tracehook_* layer, so the new code is well-isolated. Could we just drop the tracehook layer if this finally merged and call the low level functions directly? It might have been reasonably early on when it was still out of tree, but longer term when it's integrated having strange opaque hooks like that just makes the coder harder to read and maintain. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [RFC,PATCH 14/14] utrace core
On Tue, Nov 24, 2009 at 09:41:52PM +0100, Oleg Nesterov wrote: On 11/24, Andi Kleen wrote: Oleg Nesterov o...@redhat.com writes: From: Roland McGrath rol...@redhat.com This adds the utrace facility, a new modular interface in the kernel for implementing user thread tracing and debugging. This fits on top of the tracehook_* layer, so the new code is well-isolated. Could we just drop the tracehook layer if this finally merged and call the low level functions directly? Not sure I understand. Tracehooks are trivial inline wrappers on top utrace calls, Yes that's the problem -- they are unnecessary obfuscation when you can just call directly. It might have been reasonably early on when it was still out of tree, but longer term when it's integrated having strange opaque hooks like that just makes the coder harder to read and maintain. Well, I don't think the code will be better if we remove tracehooks. For example. tracehook_report_syscall_entry() has a lot of callers in arch/, each callsite should be changed to do if ((task_utrace_flags(current) UTRACE_EVENT(SYSCALL_ENTRY)) utrace_report_syscall_entry(regs)) ret = -1; // this depends on machine instead of simply calling tracehook_report_syscall_entry(). That should be in the utrace code? I don't have a problem with having common code somewhere, just not a whole layer whose only purpose seems to be obfuscation. What is the point? Less code obfuscation. When it's a utrace call, call it a utrace call, not something else. -Andi -- a...@linux.intel.com -- Speaking for myself only.
