rr refactorings

Robert O'Callahan robert at ocallahan.org
Mon Apr 21 18:32:40 PDT 2014

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.
* Then we can have a Task::record_remote(TaskPtr<T> p) variant that records
sizeof(T) bytes.
* read_mem can type-check its TaskPtr parameter by taking (TaskPtr<T>, T*).
* We can also have a read_mem(TaskPtr<T>) variant that returns T directly,
replacing read_word.

3) Similar to
create a Registers class with argN() getters and set_argN() setters. Add
argN_ptr<T>() getters returning TaskPtr<T>. Change the SYSCALL_DEF macros
to take syscall arg indices instead of register names.

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:
* Create ArchX86 and ArchX86_64 classes, each containing typedefs for
architecture-dependent types like "long" and pointers (e.g.
ArchX86(_64)::Long, ArchX86(_64)::Ptr<T>).
* Create a header file kernel_ABI.h with templated definitions for kernel
ABI structs, in the rr namespace, e.g.
template <class Arch>
struct iovec : public Arch
  Ptr<void> iov_base;
  SizeT iov_len;
* Introduce implicit conversions from Arch::Ptr<T> to TaskPtr<T>
* Make some functions like rec_process_syscall wrappers around templatized
helper functions taking Arch as a template parameter. Then in
syscall_defs.h we can write
SYSCALL_DEF1(getrusage, EMU, rusage<Arch>, 2 /* 2nd syscall arg */)

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...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20140422/2e5ac2d7/attachment.html>

More information about the rr-dev mailing list