probes, and 32-bit system calls on 64-bit kernels.
Module Probes
Due to sillyness on my behalf, the code for enumerating modules on
a kernel was broken, so we had no FBT probes against driver modules.
In fact, the INSTR provider and FBT were clashing such that FBT always
lost out (hash table lookup didnt handle the same address used by
each provider). This now works.
Stumbled upon this when trying to figure out why there were no
floppy or ext3 FBT probes.
32-bit syscalls on 64-bit kernel
Another thing I had not realised (or I did, but totally forgot), was
that we didnt see 32-bit apps executing syscalls, since a 64-bit kernel
has two system call tables. Alas, the code to handle this is slightly
ugly (nearly doubling up some key functions), but this is now resolved.
I have taken the liberty of using the "module" part of a probe to
distinguish the probes, so that the user experience is maintained, but
the user can now elect to trace one or the other or both. Heres
an example:
/home/fox/src/dtrace@vmub10-64: dtrace -n syscall::: -l | head
ID PROVIDER MODULE FUNCTION NAME
268731 syscall x64 read entry
268732 syscall x64 read return
268733 syscall x64 write entry
268734 syscall x64 write return
268735 syscall x64 open entry
268736 syscall x64 open return
268737 syscall x64 close entry
268738 syscall x64 close return
268739 syscall x64 stat entry
/home/fox/src/dtrace@vmub10-64: dtrace -n syscall::: -l | grep -v x64 | head
ID PROVIDER MODULE FUNCTION NAME
269329 syscall x32 restart_syscall entry
269330 syscall x32 restart_syscall return
269331 syscall x32 exit entry
269332 syscall x32 exit return
269333 syscall x32 fork entry
269334 syscall x32 fork return
269335 syscall x32 read entry
269336 syscall x32 read return
269337 syscall x32 write entry
This is actually a nice solution to a problem which dtrace didnt let
you do before, e.g. watch for 32-bit apps running on the
system only.
I still have more annoyances to fix (stack() address lookups give
some records without symbolic names, ability to run from the install
tree whilst being able to access the things defined in the /usr/lib/dtrace
include tree, and more stuff on basic data access for cpuinfo and other
common subsystems).
Have fun.
Post created by CRiSP v10.0.3a-b5937
Another thing I had not realised (or I did, but totally forgot), was
that we didnt see 32-bit apps executing syscalls, since a 64-bit kernel
has two system call tables. Alas, the code to handle this is slightly
ugly (nearly doubling up some key functions), but this is now resolved.
I have taken the liberty of using the "module" part of a probe to
distinguish the probes, so that the user experience is maintained, but
the user can now elect to trace one or the other or both. Heres
an example:
/home/fox/src/dtrace@vmub10-64: dtrace -n syscall::: -l | head
ID PROVIDER MODULE FUNCTION NAME
268731 syscall x64 read entry
268732 syscall x64 read return
268733 syscall x64 write entry
268734 syscall x64 write return
268735 syscall x64 open entry
268736 syscall x64 open return
268737 syscall x64 close entry
268738 syscall x64 close return
268739 syscall x64 stat entry
/home/fox/src/dtrace@vmub10-64: dtrace -n syscall::: -l | grep -v x64 | head
ID PROVIDER MODULE FUNCTION NAME
269329 syscall x32 restart_syscall entry
269330 syscall x32 restart_syscall return
269331 syscall x32 exit entry
269332 syscall x32 exit return
269333 syscall x32 fork entry
269334 syscall x32 fork return
269335 syscall x32 read entry
269336 syscall x32 read return
269337 syscall x32 write entry
This is actually a nice solution to a problem which dtrace didnt let
you do before, e.g. watch for 32-bit apps running on the
system only.
I still have more annoyances to fix (stack() address lookups give
some records without symbolic names, ability to run from the install
tree whilst being able to access the things defined in the /usr/lib/dtrace
include tree, and more stuff on basic data access for cpuinfo and other
common subsystems).
Have fun.
Post created by CRiSP v10.0.3a-b5937
No comments:
Post a Comment