[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Porting DTrace to ARM
I've updated my patch.
The patch now consists of a few files:
$ diffstat dtrace-arm.patch
external/cddl/osnet/dev/dtrace/arm/dtrace_asm.S | 13
external/cddl/osnet/dev/dtrace/arm/dtrace_isa.c | 11
external/cddl/osnet/dev/fbt/fbt.c | 576 ++++++++++++++++++++++-
external/cddl/osnet/dist/uts/common/sys/dtrace.h | 14
sys/arch/arm/arm/undefined.c | 49 +
sys/arch/arm/include/trap.h | 8
6 files changed, 670 insertions(+), 4 deletions(-)
undefined.c and trap.h are already reviewed by matt
and may be ready to merge. (two global variables for
dtrace/fbt modules has been added to undefined.c
since then, although I think it's not a big deal.)
Can I commit them? (or by matt is better?)
dtrace.h just defines some variables and dtrace_asm.S
just hooks up a callback for fbt, which are trivial.
I think these files can be committed once other files
fbt.c is the biggest change in this porting work. It explores
probe points of functions in the kernel, replaces instructions
of the probe points, and emulates the replaced instructions.
I want someone to take a look at it before merging.
The change of dtrace_isa.c is not big and important, but
a bit dirty. It copies macros (yes, FR_* ones) from another
place to make it buildable. I know the workaround is not
awesome, but it makes dtrace work anyway.
Any comments are welcome :-)
On Sat, Mar 8, 2014 at 1:22 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost>
> On Sat, Mar 8, 2014 at 12:51 AM, Matt Thomas
> <matt%3am-software.com@localhost> wrote:
>> On Mar 7, 2014, at 2:27 AM, Ryota Ozaki <ozaki-r%NetBSD.org@localhost> wrote:
>>> Hi Matt,
>>> So my patch for sys/arch/arm is now rather small than
>>> so far (just two files); it's minimum code for the core part
>>> to run DTrace on ARM.
>>> Can you please check it?
>>> The patch for sys/arch/arm is
>>> The full patch is available at the usual place:
>>> Best regards,
>> In undefined_init, the KDTRACE_HOOK should be after und_ev.ev_count++.
> I see. Fixed.
> Any other problem?
>> Digression ahead.
>> I wonder if it wouldn't be better to use a BKPT instruction on armv5t
>> and later and avoid the undefined trap, and use a prefetch abort with
>> a known FSR code. For pre-armv5t, we'd need a undefined handler but
>> we have one of those now. BKPT instructions have either a 16-bit (ARM)
>> or 8-bit (thumb) value encoded within.
>> But that can be tackled later.
> Actually this is not so digression because my next target is armv5t...
> Anyway thanks a lot for checking!
Main Index |
Thread Index |