Re: Porting DTrace to ARM

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jan 22, 11:00am, ozaki-r%iij.ad.jp@localhost (Ryota Ozaki) wrote:
-- Subject: Re: Porting DTrace to ARM

| > 1. there seem to be some whitespace only changes
| 
| Sorry for the messy code. Will fix.

Not a problem :-)
| 
| > 2. what's the STRONG_ALIAS to __ffssi2 about?
| 
| This is needed to modload solaris. Without the fix
| I got the following error:
|   # modload solaris
|   kobj_checksyms, 880: [solaris]: linker error: symbol `__ffssi2' not found
|   WARNING: module error: unable to affix module `solaris', error 8
|   modload: Exec format error
| 
| This problem seems to be not dtrace specific. Other modules,
| e.g., nand, are also encountered the error in the case of
| evbarm/BEAGLEBONE.
| 
| I want someone to confirm the problem on an evbarm/BEAGLEBONE
| machine (and other evbarm/arm machines).
| 
| I think this fix should be a separate patch if the fix is
| correct.

I think it is fine, I was just asking.

| > 3. what about the deleted code in dtrace_debug.c
| 
| The deletion is because of replacing dtrace_cmpset_long
| with atomic_cas_ulong. Please see the reply to 5. for
| more discussion.

Ok, sounds good (and for 5)

| > 4. I am torn about the cpuid -> cpu_id change. In my version of the
| >     changes, I had fixed the arm code instead in sys/arch/arm. It was
| >     used in very few places there.
| 
| Sure. I changed cpuid -> cpu_id because I thought I should
| reduce the changes of the kernel core code. So if the change
| of the arm code is acceptable, I will do it in my next patch.

I think it is; when I compiled dtrace for arm, there were only a handful
of places that cpuid was used. I would check with matt%netbsd.org@localhost 
though,
who I've CC:ed.

Thanks again for all the work,

christos