RFC: releasing version 0.1
jones.chris.g at gmail.com
Wed Sep 18 21:15:51 PDT 2013
(Apologies for missed reply-all, I'm just out of practice ;) .)
On Wed, Sep 18, 2013 at 7:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
> On Thu, Sep 19, 2013 at 12:12 PM, Chris Jones <jones.chris.g at gmail.com>wrote:
>> Right. The question I was trying to ask is, there's a universe U = S ∪
>> M of bugs rr can help with, where S are the single-process ones and M
>> multiprocess. There's a utility to Moz devs for both S and M. There's an
>> rr cost to adding multiprocess support. Unfortunately, while multi-process
>> support is enabled in FF and not fully supported in rr, there's also an
>> opportunity cost to Moz devs on missed utility(S). But there's also a cost
>> to Moz devs in disabling multiprocess when using rr. So the relevant data
>> to making a decision wrt Moz devs are
>> utility(S) cmp utility(M)
>> Like I said, my guess is that (i) utility(S) > utility(M); (ii)
>> cost(disabling-multiprocess) << utility(S), so it probably makes sense to
>> go forward with the original 0.1 plan. I would love to have that
>> confirmed, and I think you did below.
> Yes, I agree.
> My highest priority for utilizing rr is still nondeterministic test
> failures, and they mostly don't require multiprocess at this point.
Cool, that's what I had in mind.
I guess as a last resort, or if we moved seccomp-bpf support back to
>> opt-in. Fwiw, my thought was to keep a non-filtered "template" process and
>> fork that when needed, plus emulating whatever we need of the POSIX
>> parent-process API. Fingers crossed about TRACE'ing the exec() calls
>> though! :)
> I believe it's also possible to fully emulate exec(), although it would
> really suck to have to implement that!
*shiver* *shiver* :)
>>> Would it be easy to provide a way to select which process gets debugged?
>>> That would be more than enough for now, I think. But your followup seems to
>>> suggest this would not be easy?
>> We don't currently have a way. gdb doesn't tell which rr which
>> executable image it loaded. If there were a way to query that information
>> from gdb (I didn't find one, as silly as that sounds), then we could (i)
>> add code to track which tasks are in which address spaces (easy); (ii)
>> "hide" tasks from gdb that don't match the executable image under debugging
>> (relatively easy).
> If we can do those two things, why don't we just ask the user to pass a
> PID to rr replay, and enable debugging for just that PID? Making the user
> jump through a hoop here is not a problem.
I guess. Once we have the filtering in place the UI is just, well, UI.
One thing that came to mind was popping up a "debug this fork() child?
[yn]" dialog each time we see an exec() or fork() that matches the spec.
But not a big deal either way.
> My long term plans do not involve gdb anyway.
Right, I just thought it would have gotten us further in the short term
:/. But we'll see how things look in newer OSes.
> Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
> stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
> 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
> waanndt wyeonut thoo mken.o w *
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev