rr refactorings

Robert O'Callahan robert at ocallahan.org
Mon May 5 21:09:34 PDT 2014

I'd like to do some of this work when I get some free time. In particular
I'd like to lock down the format of syscall_defs.h to something reasonably
architecture-neutral so we can go ahead and add all the "easy" syscalls
without having to rewrite it all later.

One thing I'd like to do as part of that is derive the syscall numbers from
syscall_defs.h. We'll need this for x86-64 since I don't think we should
try to #include <bits/unistd_32.h> and <bits_unistd_64.h> directly to get
their definitions (and the numbers, and even set of supported syscalls, are
totally different!). I was thinking of this approach:
-- order the definitions in syscall_defs.h roughly by syscall number order
-- introduce new macros to control syscall numbering:
SYSCALLNO_X86(N) --- the next syscall's number is N on x86
SYSCALLNO_X64(N) --- the next syscall's number is N on x86-64
By default, the next syscall's number is one plus the previous syscall's
We can then use macro tricks to define an enum of syscall names with their
syscall numbers.
-- #define SYSCALL_ARCH_X86 or SYSCALL_ARCH_X64 macros while #including
syscall_defs.h, and use #ifdefs in that file to conditionally define the
syscalls for that architecture
-- define a new macro SYSCALL_UNSUPPORTED(name) for syscalls rr doesn't
support yet, and add every known syscall to syscall_defs.h. When we hit
those with rr we can print the syscall name when we exit. For every other
executed syscall we simply assert that the kernel returns ENOSYS and carry

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/20140506/7c586913/attachment.html>

More information about the rr-dev mailing list