Re: Porting DTrace to ARM

[Ryota Ozaki <ozaki-r%NetBSD.org@localhost>]

On Thu, Mar 6, 2014 at 1:39 AM, Matt Thomas <matt%3am-software.com@localhost> 
wrote:
>
> On Mar 5, 2014, at 3:12 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>
>> - Replace cpu_id with cpuid in sys/arch/arm
>>  - Can I commit the change?
>
> Why?  It's just churn for no reason I can see.

The background is that cpu_id in sys/arch/arm conflicts with
the code in cddl and we have to change either one. I and christos
(he already replied in another mail) decided to change
sys/arch/arm, which seems less pain.

>
>> - Move INKERNEL and FR_* macros from arm/arm/db_trace.c
>>  to arm/include/db_machdep.h to refer them in
>>  external/cddl/osnet/dev/dtrace/arm/dtrace_isa.c
>>  - Is this change appropriate?
>
> Well, we don't use APCS anymore.  AAPCS is the new ABI.
> My question is how useful they'll be.

My answer is that it's useful for dtrace for now; the move makes
current dtrace work anyway. Of course, we also have to support
(or migrate to) AAPCS as well at some point.

Nonetheless, we have an option is to copy them in dtrace_isa.c
at this point until we support AAPCS if the move is not appropriate.

BTW, so db_stack_trace_print of arm is irrelevant to EABI?

>
>> - Create arch/evbarm/include/cpufunc.h
>>  - It just includes arm/cpufunc.h, then
>>    #include <machine/cpufunc.h> for evbarm properly
>>    as well as i386/amd64
>>  - Is this change appropriate?
>
> No.  This makes an assumption that isn't valid, most ports
> don't have <machine/cpufunc.h>.
> #ifdef __arm__
> #include <arm/cpufunc.h>
> #endif

I see. Will do so.

>
>> - Have cond_ok in arm/include/armreg.h
>>  - Is this appropriate?
>
> I added arm_cond_ok_p

Okay, I drop mine and use yours.

Thank you for your kind response,
  ozaki-r