jkenisto wrote [untrimmed for forwarding to utrace-devel]:
> [...]
> Uprobes maintains one utrace engine per probed task. When
> instrumentation modules A and B register uprobes at the same address,
> and that probepoint gets hit, uprobes's signal (SIGTRAP) callback gets
> called (once). It cal
Hi -
On Wed, Sep 26, 2007 at 01:42:29AM -0700, Roland McGrath wrote:
> [...] The future non-signal mechanism I described there can have a
> reporting interface [...] The other part of the problem is
> insertion/removal. Naive non-cooperation works if they literally
> nest, but not if removal o
Chris Moller <[EMAIL PROTECTED]> writes:
> [...]
> and than some people have expressed a preference for: The first is
> that it's clumsy. When the utracer module loads, it creates a /proc
> pseudo-directory /proc/utrace and then a pseudo-file
> /proc/utrace/control. [...]
FWIW, it'd make more
Hi -
On Mon, Jun 30, 2008 at 11:21:30AM -0400, Chris Moller wrote:
> [...]
> >FWIW, it'd make more sense to me if such a file was per-process
> >(under the /proc/$pid/) hierarchy.
>
> A single debugger app using utracer could control any number of
> processes and there could be any number of deb
Hi -
On Mon, Jun 30, 2008 at 01:29:13PM +0200, Christoph Hellwig wrote:
> [...] This might be getting a little offtopic for the kernel summit
> discuss list, but let's start anyway, we can move this to a better
> suited list, although I can't think of one except for linux-kernel.
[EMAIL PROTECT
Roland McGrath <[EMAIL PROTECTED]> writes:
> [...]
> What the utrace interface has always said about this is, "So don't do
> that." [...]
> What I overlooked is that not just your data structures, but your
> callbacks too might be going away, i.e. unloading the kernel module.
I don't think the m
David Smith <[EMAIL PROTECTED]> writes:
> [...]
>> 2. Why do we want utrace global tracing?
>> From a systemtap point of view, we'd certainly use global tracing.
I have a somewhat different take on this.
This kind of interface would be nice to have in utrace only if it were
significantly che
Hi -
On Tue, Aug 05, 2008 at 03:32:42PM -0700, Roland McGrath wrote:
> > This kind of interface would be nice to have in utrace only if it were
> > significantly cheaper than doing what we do now: potentially attaching
> > utrace-engines to each thread -- or (in the near future, systemtap
> > bug#
Hi -
> > The alternative I considered is the nonexistence of global tracing
> > support, thus no utrace_global_flags test in the syscall fast path.
>
> It will never be in the fast path. It will always require
> TIF_SYSCALL_TRACE to bet set on each thread, which means the slow path.
> [...]
OK,
Hi -
Please consider switching some of the utrace git trees on
git.kernel.org to merge- rather rebase-based ones. This should make
it somewhat easier to develop stuff on top.
- FChE
nel/trace/trace_process.c
new file mode 100644
index 000..10c2c3c
--- /dev/null
+++ b/kernel/trace/trace_process.c
@@ -0,0 +1,440 @@
+/*
+ * utrace-based process event tracing
+ * Copyright (C) 2009 Red Hat Inc.
+ * By Frank Ch. Eigler
+ */
+
+#define DEBUG 1
+
+#include
+#include
+#include
+
Frederic Weisbecker writes:
> [...]
> Speaking about a global syscall tracer, I made a patch to trace only the
> syscalls
> with the function-graph-tracer.
> http://lkml.org/lkml/2008/12/30/267 This low-level part can easily
> be used by all tracers that would like to inspect syscalls.
> [...]
>
Hi -
On Thu, Jan 29, 2009 at 04:34:46PM +0100, Frédéric Weisbecker wrote:
> 2009/1/29 Ingo Molnar :
> [...]
> >> > sure - how do the minimal bits/callbacks look like which enable syscall
> >> > tracing?
> I know you are talking about the only necessary bits from utrace to
> have the syscalls trac
Renzo Davoli writes:
> [...]
> If the report function returns UTRACE_STOP the traced process stays in a
> quiescent state and the module wakes it up by a
> utrace_control(...,UTRACE_RESUME) call *later*.
> [...]
> If the module wakes the traced process too quickly, utrace has not yet put
> it in
ace_uid_filter # -1: unrestricted
# echo ls > process_trace_taskcomm_filter # empty: unrestricted
4. Start tracing.
# echo process > current_tracer
5. Examine trace.
# cat trace
6. Stop tracing.
# echo nop > current_tracer
Signed-off-By: Frank Ch. Eigler
---
include/linux/processtrac
roland wrote:
> After this change, we now need some fresh testing of things like Frank's
> ftrace widget and stap's utrace-using modes. (Nothing should have
> changed from the utrace API perspective.)
Righto.
> * I've renamed "struct utrace_attached_engine" to "struct utrace_engine".
>
7; of /home/roland/redhat/linux/2.6/
into utrace
are available in the git repository at:
http://web.elastic.org/~fche/git/linux-2.6-utrace.git utrace-ftrace
Frank Ch. Eigler (1):
utrace-based ftrace "process" engine, v2
include/linux/processtrace.h | 41 +++
kernel/tra
Hi -
On Mon, Mar 16, 2009 at 05:45:26PM -0400, Mathieu Desnoyers wrote:
> [...]
> > As far as I know, utrace supports multiple trace-engines on a process.
> > Since ptrace is just an engine of utrace, you can add another engine on
> > utrace.
> >
> > utrace-+-ptrace_engine---owner_process
> >
Hi -
On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> [...]
> > Utrace is very much tracing material - without the ftrace plugin the
> > whole utrace machinery is just something that provides a _ton_ of
> > hooks to something entirely external: SystemTap mainly.
>
> Roland's cha
Hi -
On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> [...]
> > There have been many mixed messages from LKML on the topic - sometimes
> > mentioning systemtap is forbidden, other times necessary. Sorry about
> > that.
>
> heh. We all love systemtap and want it to get better.
G
Hi -
On Sat, Mar 21, 2009 at 04:45:01PM +0100, Ingo Molnar wrote:
> [...]
> To me personally there are two big direct usability issues with
> SystemTap:
>
> 1) It relies on DEBUG_INFO for any reasonable level of utility.
> Yes, it will limp along otherwise as well, but most of the
> act
Hi -
On Sat, Mar 21, 2009 at 02:34:13PM -0700, Andrew Morton wrote:
> [...]
> It would not be good to merge a large kernel feature which kernel
> developers and testers cannot test, and regression test.
It does not. Other kernel self-sufficient utrace clients are on their
way, and of course one
Hi -
On Sat, Mar 21, 2009 at 03:02:59PM -0700, Linus Torvalds wrote:
> [...]
> > The thing is, utrace crashes in Fedora have dominated kerneloops.org
> > for many months [...]
>
> .. and dammit, I agree 100%. If utrace really shows up in _any_ way on
> kerneloops.org, then I think THE ENTIRE DI
Hi -
On Sun, Mar 22, 2009 at 01:37:59AM +0300, Alexey Dobriyan wrote:
> [...]
> struct task_struct::utrace became embedded struct. This is good and
> should remove quite a few of utrace bugs. Better late than never.
Yeah.
> However, "rewrite-ptrace-via-utrace" patch was omitted, so almost
> noon
Denys Vlasenko writes:
> [...]
>> Here's the /debugfs/tracing/process_trace_README:
>> process event tracer mini-HOWTO [...]
>
> A HOWTO text in the kernel binary? Shouldn't it be in
> Documentation/* instead? [...]
It parallels the debugfs/tracing/README file.
- FChE
Hi -
On Mon, Mar 23, 2009 at 12:42:08PM -0400, Mathieu Desnoyers wrote:
> [...]
(Please trim emails you're responding to.)
> [...]
> > > So if the system has, say 3000 threads, then we have 3000 struct
> > > utrace_engine created ? I wonder what effet this could have one
> > > cachelines if this
Hi -
On Sun, Mar 22, 2009 at 01:08:11PM +0100, Ingo Molnar wrote:
> [...]
> > In my own limited kernel-building experience, I find the debuginfo
> > data conveniently and instantly available after every "make". Can
> > you elaborate how is it harder for you to incidentally make it
> > than for
Hi -
On Mon, Mar 30, 2009 at 03:18:44PM -0700, Andrew Morton wrote:
> So we need to work out what to do about utrace and I feel a need to hit
> the reset button on all this. [...]
Thanks.
> [...] The ftrace patch merged about as (un)successfully as one would
A new version against -tip is comi
Hi -
On Tue, Mar 31, 2009 at 11:17:42AM +0200, Peter Zijlstra wrote:
> [...] Right, from my POV something like utrace is desirable, since
> its basically a huge multiplexer for the debugger state, eventually
> allowing us to have multiple debuggers attached to the same process.
> [...]
Right.
ananth wrote:
> Uprobes is implemented only for architectures that have utrace support
> (x86-32, x86_64, powerpc, s390, but not IA64). [...]
(HAVE_ARCH_TRACEHOOK is on for ia64, sparc, sh also, so utrace per se
should work there.)
> [...] For ARM though, the utrace layer needs to be implement
Josh Boyer writes:
> [...] While I would love to believe that systemtap should work
> everywhere, I can't really see it running on an embedded board at
> this point.
FWIW, we have had people running (not compiling) systemtap probe
modules on embedded systems. See "stap -p4" or "stap-server".
Since both the utrace-based ftrace engine and the original
syscall-specific ftrace engine use the syscall pretty-printer, this
initialization function needs to be callable from each of them.
Signed-off-by: Frank Ch. Eigler
---
arch/x86/kernel/ftrace.c |3 +++
1 files changed, 3 insertions
% cat trace
6. Stop tracing.
% echo nop > current_tracer
Signed-off-by: Frank Ch. Eigler
---
include/linux/processtrace.h | 51
kernel/trace/Kconfig |8 +
kernel/trace/Makefile|1 +
kernel/trace/trace.h |9 +
kernel/
e so inclined.
Frank Ch. Eigler (2):
make arch_init_ftrace_syscalls multiply callable
utrace-based ftrace "process" engine, v3
arch/x86/kernel/ftrace.c |3 +
include/linux/processtrace.h | 51
kernel/trace/Kconfig |8 +
kernel/trace/Makefile|1 +
Hi -
In a few contexts, it comes up as to whether it is faster to probe
process syscalls with kprobes or with something higher level such as
utrace. (There are other hypothetical options too (per-syscall
tracepoints) that could be measured this way in the future.)
It was time to check the intu
Hi -
On Tue, Apr 28, 2009 at 11:10:10AM -0700, Roland McGrath wrote:
> [...]
> The microbenchmark makes that seem like more of a sensical comparison than
> it really is. They are really apples and oranges. The TIF_SYSCALL_TRACE
> types (process.syscall) add some overhead to every system call. T
Hi -
I encountered a situation where the regset->get function was called
with a size that didn't match the native register size. This crashed
the kernel.
Details: 2.6.30-rc1, x86-64, NT_PRSTATUS regset, pos=80, count=4
(instead of 8).
I wonder if the problem was in this bit of code in arch/x86/
Hi -
I'm slowly assembling a prototype gdb stub for debugging user-space
programs, based on utrace, for possible eventual inclusion in the
linux kernel. For the moment, it is a toy alternative to ptrace() for
targeting existing processes, and it's not done even for that. But
before too long thou
drow wrote:
>> I'm slowly assembling a prototype gdb stub for debugging user-space
>> programs, based on utrace, for possible eventual inclusion in the
>> linux kernel. [...] But before too long though it should be able
>> to use uprobes (q.v.) as a kernel-side breakpointing facility using
>> th
served.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU General Public License v.2.
+ *
+ * Red Hat Author: Frank Ch. Eigler
+ */
+
+/* #define DEBUG 1 */
+
+#include
+#inc
Hi -
While hacking on the gdb stub thingie, I needed several irc talks with
roland to understand what I was seeing. Some improved kerneldocs may
help matters. Specifically ...
- The report_signal callback's block of description is too dense. It
would be better to discuss the REPORT and HANDLER
Shachar Shemesh writes:
> [...] The best way, as far as I can tell, to do that on Linux is to
> use the PTRACE_GETSIGINFO command. [...] Unfortunately, utrace (at
> least the version integrated into the Fedora Core 9 and Fedore 10
> kernels) totally eliminated this system call. When calling ptra
Hi -
Forwarded from ananth, whose emails are not hitting utrace-devel for
some reason:
Date: Wed, 22 Jul 2009 13:21:43 +0530
From: Ananth N Mavinakayanahalli
To: utrace-devel@redhat.com
Subject: Q: attaching engines to all threads
Roland, Oleg,
What do you think is the best model to attach en
Hi, guys -
I'm running into a recurrent problem on my gdbstub+uprobes prototype.
(git://web.elastic.org/~fche/utrace-ext.git utrace-gdbstub-uprobes)
The gist is that running a unregister_uprobe upon a stopped process
(single-threaded, stoped via a UTRACE_STOP event) appears to hang
indefinitely.
Hi -
On Mon, Aug 03, 2009 at 11:10:00AM -0700, Jim Keniston wrote:
> [...]
> > So as per my analysis, gdb_utrace_report_signal was called, followed by
> > uprobe_report_signal. Since gdb_utrace_report_signal requested for
> > UTRACE_STOP as resume action for SIGTRAP, the thread got stopped.
> > [.
Hi -
> [...] I'm not sure what you mean here about "always correct". It is
> always correct that you should not use UTRACE_SINGLESTEP without
> setting up a callback. [...]
I wonder if utrace could be more helpful here. If an engine just
wants to single-step from some other callback, forcing i
Ali Polatel writes:
> [...] Basically sydbox intercepts some system calls and checks
> their arguments. Using ptrace, however, it's not possible to stop
> the children only at the entry of system calls we are interested in
> but we have to stop them at _every_ system call and check for the
> sys
Hi -
itrace is a utrace engine included in the systemtap runtime that
activates UTRACE_SINGLESTEP / BLOCKSTEP on targeted userspace
processes. It seems to work OK on ppc64, but crashes lots on recent
fedora (inc. rawhide) level utrace on x86/x86-64. (Lately I've been
unable to boot a utrace/mast
Hi -
On Tue, Nov 24, 2009 at 10:26:19PM +0100, Andi Kleen wrote:
> [...]
> > 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_
peterz wrote:
> Hmm,. wouldn't it make much more sense to extend the current kgdb stub
> to include userspace debugging, providing an all-in-one solution?
> I think it would be much more powerful to be able to observe the full
> software stack and not be limited by this user<->kernel barrier.
Th
On Mon, Nov 30, 2009 at 04:16:50PM +0100, Ingo Molnar wrote:
> [...]
> kgdb exists here and today in the kernel and you cannot just build a
> facility that doesnt replace it and doesnt integrate well with it.
Surely you don't mean that: every non-kgdb facility in the kernel
meets that definition,
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
seria
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 the end of the natural "overlap".
> [...]
Hi -
> > Help me out here: by "kgdb extension" do you imagine "something new
> > that an unprivileged user can use to debug his own process"? Or do
> > you imagine a new userspace facility that single-steps the kernel?
>
> Is this a trick question? Single-stepping the kernel on the same syste
Ingo Molnar writes:
> [...] Since the speed of development in this area is truly glacial
> at the moment and the practical advantages that i can experience
> personally (directly as a Linux user and indirectly as a maintainer)
> are miniscule so far, caution is warranted IMO. [...]
If the "cau
Hi -
On Thu, Dec 10, 2009 at 07:16:38PM +0100, Ingo Molnar wrote:
> [...]
> > The gdbstub prototype was constructed for two reasons: to demonstrate
> > utrace usage now, and in the future to be incrementally useful (over
> > ptrace, by moving into fast kernel-space operations like
> > multithre
Frederic Weisbecker writes:
> [...]
> This is much more tricky in the case of uprobes as I see two
> ways to work with it:
> - probing on an already running process
> - probing on a process we are about to run
> [...]
As you might expect, in systemtap we've had to figure out this area
some time
Hi -
> > As you might expect, in systemtap we've had to figure out this area
> > some time ago. We use another utrace consumer called "task finder" [...]
>
> So, could you tell us how the task-finder works and is implemented?
The code may be found at runtime/task_finder* in the systemtap source
Peter Zijlstra writes:
> [...]
> Right, so all that need be done is add the multiple probe stuff to UBP
> and its a sane interface to use on its own, at which point I'd be
> inclined to call that uprobes (UBP really is an crap name).
At one point ubp+uprobes were one piece. They were separated
Hi -
> > > Then we can ditch the whole utrace muck as I see no reason to want to
> > > use that, whereas the ubp (given a sane name) looks interesting.
> >
> > Assuming you meant what you write, perhaps you misunderstand the
> > layering relationship of these pieces. utrace underlies uprobes and
Hi -
On Fri, Jan 15, 2010 at 02:25:30PM +0100, Peter Zijlstra wrote:
> [...]
> > utrace is not a form of punishment inflicted upon the undeserving. It
> > is a service layer that uprobes et alii are built upon. You as a
> > potential uprobes client need not also talk directly to it, if you
> > w
Hi -
On Fri, Jan 15, 2010 at 02:47:56PM +0100, Peter Zijlstra wrote:
> [...]
> > I'm not sure, but it sounds like the part you're complaining about is
> > how utrace ultimately reports the trap to uprobes: i.e.,
> > utrace_get_signal()? Is that the "insane amount of code"?
>
> Well when tracing/
Hi -
> > Well, I'm not in a position to argue line by line about the necessity
> > or the cost of utrace low level guts, but this may represent the most
> > practical engineering balance between functionality / modularity /
> > undesirably intrusive modifications.
>
> How intrusive and non-modul
Jim Keniston writes:
> [...]
> Years ago, we had pre-utrace versions of uprobes where the uprobes
> breakpoint-handler code was dispatched from the die_notifier, before the
> int3 turned into a SIGTRAP. I believe that's what Peter is
> recommending. On my old Pentium M...
> - a pre-utrace upro
Hi -
Having been reviewed a couple of times, and we hope being a good
candidate for merging next time, please start pulling
git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git branch
master
This repo contains frequent merges from Linus' tree. If you'd prefer
a cleaner rebas
Hi -
On Wed, Jan 20, 2010 at 07:28:34AM +0100, Ingo Molnar wrote:
> [...]
> > On the other hand, having ptrace/utrace in the -next tree will give it a
> > lot more testing, while any outstanding technical issues are being
> > addressed.
>
> Including experimental code that is RFC and which is no
Hi -
On Wed, Jan 20, 2010 at 05:59:59PM +1100, Stephen Rothwell wrote:
> [...]
> > Including experimental code that is RFC and which is not certain to go
> > upstream is certainly not the purpose of linux-next though.
>
> Ingo is correct in what he says here. See the boilerplate:
> [...]
> Basi
Hi -
On Thu, Jan 21, 2010 at 04:31:45PM -0800, Andrew Morton wrote:
> [...]
> > Someone please sell this to us.
> Here's what Oleg said last time I asked this: [...]
I wonder if Roland/Oleg are being too modest in their current role as
ptrace maintainers. Considering that *they* think of utrace
Hi -
On Thu, Jan 21, 2010 at 05:05:41PM -0800, Andrew Morton wrote:
> [...] ptrace is a nasty, complex part of the kernel which has a
> long history of problems, but it's all been pretty quiet in there
> for the the past few years. This leads one to expect that a
> rip-out-n-rewrite is a high-r
Hi -
On Thu, Jan 21, 2010 at 05:32:47PM -0800, Linus Torvalds wrote:
> [...]
> > To the extent the discussion is colored by the new features enabled
> > from this refactoring, well, there is Oleg's list which may or may not
> > have mentioned enabling systemtap's user-space probing.
>
> Let's fac
Hi -
oleg wrote:
> [...]
>> I'm personally very dubious that there are any merits to utrace that
>> outweigh the very clear disadvantages: just another layer that adds a new
>> level of abstraction to the only interface that people actually _use_,
>> namely ptrace.
>
> Of course they can't use ot
Hi -
On Fri, Jan 22, 2010 at 09:16:16PM +0100, Peter Zijlstra wrote:
> [...]
> > So then there's uprobes, which is another potential utrace "killer
> > app"
> That's bollocks, uprobes is an utter and total mis-match for utrace.
> Probing userspace is primarily about DSOs which is files and vma's,
Hi -
On Fri, Jan 22, 2010 at 01:59:11PM -0800, Linus Torvalds wrote:
> [...]
> > Finally, I don't know how to address the logic of "if a feature
> > requires utrace, that's a bad argument for utrace" and at the same
> > time "you need to show a killer app for utrace". What could possibly
> > sati
Hi -
mingo wrote:
> [...]
> > Now how do we get from here to a moderately portable API for interrogating,
> > controlling, and intercepting process state? Essentially it would need to
> > support all of the things that a powerful debugger would want to do,
> > including modifying registers and
Hi -
On Sat, Jan 23, 2010 at 11:01:21AM +, Alan Cox wrote:
> [...]
> What I don't understand is why [libgdb?] doesn't solve 99% of your problem.
> ptrace is not perfect but most of the real ptrace limitations actually
> come about because either the CPU can't do something or because the
> supp
Hi -
On Sat, Jan 23, 2010 at 07:04:01AM +0100, Ingo Molnar wrote:
> [...] Also, if any systemtap person is interested in helping us
> create a more generic filter engine out of the current ftrace filter
> engine (which is really a precursor of a safe, sandboxed in-kernel
> script engine), that w
Hi -
On Sun, Jan 24, 2010 at 05:25:13AM -0500, ty...@mit.edu wrote:
> [...]
> > > The killer app for this will be the ability to delete thousands of
> > > lines of code from GDB, strace, and all the various other tools that
> > > have to painfully work around the major interface gotchas of ptrace(
Hi -
tytso wrote:
> [...]
Let me see if I can paraphrase those of your concerns that were substantive:
1) That if utrace is merged, and systemtap keeps on using it, there may be
some sort of chilling effect on kernel developers that would impede
utrace's future development.
This might sou
Hi -
On Mon, Jan 25, 2010 at 08:52:41AM -0800, Linus Torvalds wrote:
> [...] If somebody extended ptrace in good ways, that's a totally
> different thing. But I think utrace has been over-designed, possibly
> as a result of others coming in and saying "hey, I'd like to use
> that too for xyz". [
Hi -
On Mon, Jan 25, 2010 at 02:05:54PM -0700, Tom Tromey wrote:
> [...]
> Nevertheless, if the Linux kernel were to present a new user-space API,
> and if it had an advantage over ptrace, then we would port GDB to use
> it. There are other platforms where, IIRC, we now use some /proc thing
> ins
tromey wrote:
> [...]
> In non-stop mode (where you can stop one thread but leave the others
> running), gdb wants to have the breakpoints always inserted. So,
> something must emulate the displaced instruction.
This sounds like the sort of thing that kernel kprobes do, which the
uprobes patch
Ingo Molnar writes:
> [...] So, to sum it up: utrace XOL, which is rather complex already,
> needs even more complexity (which is not yet implemented) than the
> much simpler common-case emulator approach i outlined, just to break
> even with the performance of the much simpler approach. [...]
I
Oleg Nesterov writes:
> [...]
> - ugdb.c
>
> The kernel module which implements the basic
> user-space API on top of utrace. Of course,
> this API should be discussed.
> - gdbstub
>
> The simple user-space gdbserver written in
>
Hi, Oleg -
> [...]
> But I do not see how in-kernel gdbstub can help even to prototype
> things. In my opinion it only complicates this. If nothing else,
> it is not easy to test even the simple things. Just imagine the
> simple tests like ptrace-tests rewritten to work via remote
> protocol.
(O
oleg wrote:
> [...]
> - It doesn't support all-stop mode.
> Please tell me if this is needed. I hope not, this needs
> a lot of nasty complications :/
> [...]
As opposed to non-stop mode? I'm pretty sure all-stop will be needed
as that is the common & default gdb usage mod
Oleg Nesterov writes:
> [...] To the point, I had to add printk's to utrace.c to understand
> what is wrong. Hopefully tomorrow.
You might wish to try out systemtap for such purposes. It's easy to
insert printk-like tracing at almost any point; monitor variables for
changes, pretty-print struc
Oleg Nesterov writes:
> [...]
>> Therefore until you track some ugdb-specific software(*)
>> breakpoints ugdb does not need to support Z0 IMO. I guess ugdb
>> will never have to support these: thread-related(?) and tracepoint
>> ones.
> Good! I thought ugdb should somehow handle this all "tran
Oleg Nesterov writes:
> [...]
> But, Jan. Implementing the memory writes does not mean breakpoints
> automatically start to work!
It approximately should though.
> Yes, gdb writes cc, and yes the tracee reports SIGTRAP. But after
> that "continue" does nothing except "$c", and the tracee natura
Hi -
On Thu, Sep 09, 2010 at 05:50:47PM +0200, Oleg Nesterov wrote:
> Probably I need to implement G/P first, otherwise gdb can't change ip.
Perhaps.
> Still, I'd appreciate if someone can explain me what gdb needs/expects
> to handle breakpoints before I start to read the sources.
It'd be sim
oleg wrote:
> [...] Honestly, I don't really know how do the "right thing" here.
> Anyway, most probably this code will be changed. Like ptrace, ugdb
> uses ->report_syscall_exit() to synthesize a trap. Unlike ptrace,
> ugdb_report_signal() doesn't send SIGTRAP to itself but reports
> SIGTRAP u
Hi -
On Thu, Sep 23, 2010 at 01:14:51AM +0200, Oleg Nesterov wrote:
> > (It seems to me that a pure gdb report, without a synthetic
> > self-injected SIGTRAP, should be fine.)
>
> What do you mean?
(Never mind, I'm probably just confused about what you were asking.)
> > > Next: fully implement
Hi -
On Thu, Sep 23, 2010 at 02:21:38PM -0700, Roland McGrath wrote:
> > > The ones I'm talking about are Z2/Z3 for (data) watchpoints.
> > Ah, OK, thanks. I'll try to understand how this works.
>
> In theory these will map to uses of the hw_breakpoint interface.
Not quite. The hw_breakpoint wi
f-turgis wrote:
> [...]
> So I am interested in this kind of status:
>
> * utrace has not been accepted upstream. Does it mean it may lose
> traction ? Is "community" pushing for something else or happy with
> what they have ? [...]
There are many communities. I am not anticipating additional u
93 matches
Mail list logo
