Skip to content

Revise syscall wrapper implementation #6

Closed

Description

@joneschrisg

@rocallahan has a WIP at https://github.com/rocallahan/rr/tree/rework-syscall-wrapping, "but it's not complete yet." More details forthcoming.

Activity

  1. joneschrisg commented on Jun 24, 2013

    @joneschrisg
    ContributorAuthor

    We need this to prevent synchronous signals received in the syscall buffer from blowing up the world, and to better handle buffer overflows when we buffer variable-sized output data.

  2. joneschrisg commented on Jun 25, 2013

    @joneschrisg
    ContributorAuthor

    I have the original branch rebased and cleaned up a bit (with some of my own riders) at https://github.com/cgjones/rr/tree/syscall-buffer-cleanup . The change to filtering semantics requires double-checking WRAP_SYSCALLS_CALLSITE_IN_WRAPPER() and its users, which I'll do before merging.

  3. rocallahan commented on Jun 25, 2013

    @rocallahan
    Collaborator

    +#define SYSCALL_BUFFER_LIB_FILENAME "librr_wrap_syscalls.so"

    Change to "buffer"?

    I think signals/context-switches inside the buffer library are still completely broken with this patch (but no worse than the state I had it in). I assume fixing that will be a followup patch.

  4. joneschrisg commented on Jun 25, 2013

    @joneschrisg
    ContributorAuthor

    Change to "buffer"?

    Errm yeah :). I never claimed our test coverage for the buffer was there yet ;).

    I think signals/context-switches inside the buffer library are still completely broken with this patch (but no worse than the state I had it in). I assume fixing that will be a followup patch.

    Well, this code is off by default, and even then all the broken syscalls were already disabled before your patch. There's existing signal brokenness that your patch didn't change. The only "regression" here AFAIK is temporarily disabling futex, which I'd like to un-regress before landing. But since it's effectively dead code atm, I'm not in a huge hurry. But also no big hurry to get on upstream/master.

  5. joneschrisg commented on Jun 25, 2013

    @joneschrisg
    ContributorAuthor

    It turns out that the futex code isn't used, because glibc directly traps to the kernel. So except for the CALLSITE_IN_LIB issue, I think we're back to where we were functionality-wise with a nice cleanup on top. Then the hard work begins :).

  6. joneschrisg commented on Jun 25, 2013

    @joneschrisg
    ContributorAuthor

    We're back to (actually, as opposed to apparently, #145) passing all tests and recording firefox. We fail replaying FF, but so does master. I think we're about ready to merge. Would like to get the lib rename in for 0.0 to reduce future hassle.

  7. joneschrisg commented on Jun 26, 2013

    @joneschrisg
    ContributorAuthor

    Resolved by #148. What landed was mostly a cleanup, lots more work remains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions