On 01/24/10 13:01, Frank Ch. Eigler wrote:
... all add up to a mere nudge away from entirely "evil". If so, I
wonder if your sort of grossly bimodal view of ethical virtue is going
to foster the right sorts of change in the linux kernel community.
Nothing like a good religious debate to l
Roland,
Is this going to make into F11? Or is it too early to tell that yet?
Roland McGrath wrote:
> Hi, Ananth. Sorry everything has slid so long (again).
> (I have far too many hats and the past month not so many brains!)
>
> Here is my immediate agenda for utrace hacking:
>
Jim Keniston wrote:
>
>>
>> Any chance there's some actual working ubp code I could tinker with?
>>
>
> There is no implementation of ubp yet. We could probably hack together
> an x86 implementation from x86 uprobes in a few days.
>
> But we'd need a client to test it. One approach would b
nto archer.
Backburnered:
* More work on attach_tree().
* Add stuff to limit user control of processes
* Look at incorporating ubp (breakpoints) into froggy.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what y
s:
>
> 1. Provide an API that enables different clients to place probes at
> the same virtual address in the same process. (But what other
> shared-among-clients resources would need to be managed? SSOL slots,
> at least.)
>
> Issues:
> ---
> - SSOL vma wants to be al
uld change
anything about them. And it would probably be a good idea if even
root couldn't screw with init.
* Maybe start looking into incorporating breakpoints into froggy.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you r
various places, and maybe an index, but it
gets the point across.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: PGP signature
eek(s):
* Add more documentation.
* Add syscall entry filtering.
* Add signal reporting and filtering.
* Add an attach_tree capability.
* Add more testcase/demos.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize
talks of froggy being a
> sandbox for utrace.
> (I haven't read the documents that were updated today. Sorry if its
> covered in those docs.)
>
I'll be doing a lot of documentation work over the next few days--no
reason I can't include a tentative roadmap.
>
> which never gets used. Similarly for unsafe_exec and tracer_task.
>
> Can you explain why you would want to attach with
> UTRACE_ATTACH_EXCLUSIVE always? So even if I want to trace the same
> program twice from froggy then I shouldn't be able to do it?
>
>
> --
m froggy then I shouldn't be able to do it?
>
To be honest, I had no good reason for using UTRACE_ATTACH_EXCLUSIVE and
can certainly experiment with removing it.
>
> --
> Thanks and Regards
> Srikar
>
Chris
--
Chris Moller
I know that you believe you understand wha
fork and die.)
* More testcase/demo tinkering.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
Petr Tesarik wrote:
>
>
> All sounds very nice, Chris. But I'm having trouble finding the sources.
> Could you give me a pointer, please?
>
Sorry--you can get the source with cvs -d
:ext:sources.redhat.com:/cvs/systemtap co froggy
cm
> Petr Tesarik
>
>
--
ow yet if it uses
the same underlying mechanism as poll.)
This week:
* Add documentation.
* Add fork/eexec/attach support.
* Add syscall entry filtering.
* Add signal reporting and filtering.
* Hack otherwise as necessary.
--
Chris Moller
I know that you b
ing
any action--quiescing, tinkering with signals, etc.--that
would actually affect the processes.
Comments welcome.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not
are considering holding a task_struct pointer for
> something, let's discuss each on a case by case basis.
>
Much appreciated,
cm
>
> Thanks,
> Roland
>
>
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure
er circumstances
I've used in the past, like accessing user mem via get_user_pages(),
where I needed access to the task struct. Even if I don't need task
struct any more for utrace, I'm kinda trying to plan ahead a bit.
Or are pid_task() and get_pid_task() the new/modern way of doing
but tasklist_lock
is showing up as undefined in module build stage 2 and "Unknown symbol
in module" in insmod. am i balling something up? or can i go on using
rcu_read_(un)?lock?
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure y
something up? or can i go on using
rcu_read_(un)?lock?
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
real code, you should be using syscall_get_nr (asm/syscall.h),
Hmm-- no such thing, apparently, as syscall_get_nr in 2.6.25.6. Is it
supposed to trickle out into the world sometime soon?
Thanks,
Chris
>
>
> Thanks,
> Roland
>
--
Chris Moller
I know that you believe you
-test code
that decodes syscalls, the same hunk of code that's dumping the "[
] got syscall entry..." stuff. Anyone have a clue what that's all
about?
It's real--if I stick
if (-1 == regs->orig_ax) printk (KERN_ALERT "got a syscall -1\n");
into the
e fork()/exec() process needed by -E, which also requires
synchronisation with the client in various places.)
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
ached running
(i.e., it's not quiesced), all syscall entries and exits are
reported.
and that's it. More to come.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
Chris Moller wrote:
BTW, until further notice--tomorrow morning, probably, don't use a
froggy of any later that 2006-07-28 11:20. Somehow a kernel-crasher
snuck in which I'll debug in the morning.
Fixed and committed.
--
Chris Moller
I know that you believe you understan
as long as there are any open fds on the froggy
peeudo-file /sys/kernel/debug/froggy.
BTW, until further notice--tomorrow morning, probably, don't use a
froggy of any later that 2006-07-28 11:20. Somehow a kernel-crasher
snuck in which I'll debug in the morning.
--
Chris Moller
e, what happens if there is a error in a client and
it aborts? What happens if someone does a "rmmod" on the module while
clients are still running?
Both circumstances on the to-do list.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not s
ng synchronised with the queue buffer, and
gracefully respond to the deaths of child processes by detaching and
freeing resources, and asynchronously reporting the death back
to the
app.
Feedback, as usual, welcome.
--
Chris Moller
I know that you believe you understand what
e. So we'd have a quiesce
only example; that in turn would form part of the quiesce test-suite.
It allows newbie developers like me to quickly ascertain code snippets
in a isolated, concrete fashion. It would also be neat to track
regressions across development phases, even this early on.
Phil Muldoon wrote:
Chris Moller wrote:
Try it now (from the sources.r.c repo): I think what was happening
was that the response thread was terminating before the
report_quiesce hit, thereby invalidating the pointer to the buffer.
I rewrote all that code.
Great thanks, can attach
r, be back latr tonight!
[EMAIL PROTECTED] froggy]$ ./froggy-test -t760
sending syscal vecs
sending signal vec
attaching tasks
attach status =
resp buf = "quiescing
"
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you r
g ./froggy-test -t
where is the bash task.you'll get some stuff, but the
important part is where it says "resp buf = "quiescing" That's a round
trip from attach->quiesce->asynchronous response.
--
Chris Moller
I know that you believe you understan
Forgot to mention, BTW, there's a mini-app in utracer/*.[ch] that shows
the utracer API in use in a fake GTK-based debugger.
Phil Muldoon wrote:
Chris Moller wrote:
Phil Muldoon wrote:
Thanks for the description Chris. From an ntrace client
implementation "point of view&quo
Phil Muldoon wrote:
Chris Moller wrote:
Phil Muldoon wrote:
Thanks for the description Chris. From an ntrace client
implementation "point of view", non-ordered replies to asynchronous
requests present an ordering conundrum in the client - especially as
it scales to many many
ould be synchronous. I don't want to get tied up here too much, as
both you and Roland mention this is all fluid. But for the sake of
understanding and documentation, can you give me a use-case where a
synchronous request would be needed/used, and also an asynchronous one?
Regards
Phil
Phil Muldoon wrote:
Chris Moller wrote:
No guarantees, of course--the next-generation stuff may do things
differently--but even as I type this, I'm hacking together a
boilerplate framework that does exactly as described above.
Missed this in the last question, so apologies for the mul
ther a boilerplate
framework that does exactly as described above.
Feedback welcome.
cm
Regards
Phil
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
K.Prasad wrote:
On Tue, Jul 01, 2008 at 03:28:04PM -0400, Chris Moller wrote:
K.Prasad wrote:
Hi All,
Sorry if I have missed out something I need to know before I
respond to this email. But the "trace" infrastructure (lib/trace.c)
already provides such a facility
re already familiar to the systemtap code.
Thanks,
K.Prasad
P.S.: "trace" is currently in -mm tree.
Thought it might be interesting to check this out--the patched
2.6.26-rc5 kernel built fine but panicked when I tried to boot it. So
much for the easy way...
--
Chris Moller
longer than I have--but if you have cool notions about which way to go,
you kinda need to let the rest of us know what they are. (And, reading
ahead, yeah, I know, that's what the rest of this note is...)
I'll commence to hackin'.
cm
--
Chris Moller
I know that you believe yo
Frank Ch. Eigler wrote:
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/utr
he interface/fancy-debugger-module picture.
In the next day or two, I'll start a new thread here about each facet of
the problem as I see it and what I've had in mind; for lack of a better
name, under the heading "ntrace".
Thanks,
Roland
--
Chris Moller
I know that you b
arting over
and accumulating new cruft.
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
Daniel Jacobowitz wrote:
On Wed, Jun 25, 2008 at 12:30:03PM -0400, Chris Moller wrote:
Extending ptrace seems like a sad idea. If Linux is going to grow a
new userspace-accessible debug interface, can't it go in /proc or
something?
Actually, that's exactly what ut
Phil Muldoon wrote:
Chris Moller wrote:
Due to a complete lack of interest, I'm shelving utracer. May it
collect dust in peace.
I was (and still am) interested in it from a direct api point of view.
As a an end-tool not so much.
Systemtap is cool, and, based on tinkering with i
Daniel Jacobowitz wrote:
On Tue, Jun 24, 2008 at 10:49:56PM -0400, Chris Moller wrote:
I've been scratching my head for a bit on some other way to provide
user-space access to utrace. Three things occurred to me:
1. A systemtap-like approach.
2. A whole new syscall, SYS_utra
Adam Jackson wrote:
On Tue, 2008-06-24 at 22:49 -0400, Chris Moller wrote:
Comments, up to and including "What the hell are you smoking?" welcome.
I'd rather phrase this as "what are we not getting out of ptrace that we
really want". Answering that w
. All the
real hacking is in the external fcn.) At least one upside of this, of
course, is that there's no redundancy with ptrace.
Comments, up to and including "What the hell are you smoking?" welcome.
--
Chris Moller
I know that you believe you understand what you think I
directory
utracer.
2. Singlestep is badly broken in the sample app (like" ps -el
"segv's and other bad stuff after you try a ss on an attached
task) and since Roland is about to change the underlying utrace
anyway, I haven't bothered to fix it.
--
Chris
er process to monitor it for a while or until it dies. It
> is nice to avoid maintaining the monitored thread under ptrace during
> the session. Today, perfmon uses its own notification mechanism via
> a message queue to forward the information to use monitoring tool.
> I'd rather use a st
he
interface lib are arch-independent (at least, any arch-dependent bits
are taken care of by the kernel config of the kernel headers).
Have fun; comments welcome,
Chris Moller.
--
Chris Moller
Java: the blunt scissors of programming languages.
-- Dave Thomas
signature.asc
Description: OpenPGP digital signature
50 matches
Mail list logo
