jones.chris.g at gmail.com
Mon Apr 21 20:20:52 PDT 2014
Do you mind if I add these to the x86-64 wiki?
On Mon, Apr 21, 2014 at 6:32 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
> I've got a few ideas about things I'd like to do, to clean up the code a
> bit and work towards x86-64 support. Not planning to do it all right away,
> but I'd like some feedback.
> 1) Currently pointers to tracee memory have the same type as pointers to
> rr memory. I find this makes code harder to read. I suggest introducing a
> TaskPtr<T> type which is a pointer to T in tracee memory. This would be a
> struct wrapping a uintptr_t. We'd use it for all tracee pointers.
Sounds fine to me as long as it's easily convertible to and constructible
from T* / void*. (I might bikeshed |remote<T>| for brevity and avoiding
potential ambiguity around "task".)
> * Then we can have a Task::record_remote(TaskPtr<T> p) variant that
> records sizeof(T) bytes.
(Or |record(remote<T>)| and |record(const T&)|. "_remote" and "TaskPtr<"
Was there a "2)"?
4) Many kernel ABI structs have different layouts for 32-bit vs 64-bit,
> e.g. iovec, stat64, getrusage. I don't think we can pull the definitions of
> these structs from #include files in a way that makes both the 32-bit
> definition and the 64-bit definition visible to rr. It would also be a
> little painful to use two separate definitions. So how about:
If I follow correctly, you're proposing to have rr declare local versions
of the "common-case" arch-varying structs like iovec? And you want both
the 32-bit and 64-bit variants to be explicitly name-able to support
mixed-arch tracee trees in the future?
That sounds fine, but one issue I'd point out is that even for the same
arch, both 32-bit and 64-bit variants of structs can be used. For example,
on x86, |fcntl64(GETLK, struct flock)| works, and so does
|fcntl64(GETLK64(, struct flock64)|. There's really not an elegant
solution for that, but it feels a little awkward to name those variants by
architecture when they're just different off_t widths. I'm not proposing
anything, just pointing that out :).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev