Re: What about MIPS support?

[Victor Kamensky <kamensky@cisco.com>]

Hi Per, Josh,

We (Cisco) have pretty much full systemtap MIPS port. It works fine on 
Cavium Octeon cpus (mips64). We did very limited testing on OpenWrt 
Broadcom 4710 (in order to cover mips32 variant).

All parts, kernel and user land, are covered and we have almost all CPU 
specific systemtap functions implemented.

Also we had faced bunch of cross compilation related issues and we have
quite extensive patch addressing those.

Maneesh Soni developed mips uprobes and I did all other pieces (mips 
run-time, mips .stp files, cross compile, etc).

We always meant to publish all of it, but never get our hands on it. I 
hope this thread would be final push :). We will do it. Unfortunately, I 
cannot publish our patch series right away. I need to get permission from 
our company legal. It should not be a problem, but it may take two or 
three weeks.

Our latest series of patches is based on systemtap-1.6. I'll see whether I
can find time and move them to latest git ... In worst case scenario we 
just publish what we have.

Wrt of MIPS kprobes, it should be there already, somewhere in latest 
kernel. Most of support was there for a while. Maneesh and I contributed 
patch that let probe be inserted into jump instructions (that was 
limitation of original implementation, which we quickly discovered when we 
used for real cases). We worked on top 2.6.32 kernel. As understand there 
is current gradual departure from uprobes .. so our mips uprobes part may 
need rework a bit.

Thanks,
Victor

On 08/17/2012 Josh Stone wrote:

> On 08/17/2012 09:32 AM, Hallsmark, Per wrote:
> > Dear systemtap gurus,
> > 
> > Are there any plans in near future for a MIPS port?
> 
> I don't know of any plans, but we'll welcome patches. :)
> 
> > I've also tried a bit with release 1.7 (latest release possible that 
> > didn't require a lot of changes in our build environment, like 
> > upgrading elfutils etc). Unfortunately our kernel didn't have
> > support for kprobes so that had to be backported.
> 
> We'll of course prefer that any patches are on git master. Perhaps you
> can configure --with-elfutils=/path/to/new/elfutils to build stap with
> its own copy.  Anything else in your build environment holding you back?
> 
> > So I obviously now need to add more mips support in systemtap 
> > (started with this in tapsets/mips etc)
> > 
> > Any guidance on what is needed todo for a new arch?
> 
> Right, there will need to be tapset/$arch for specific functions, and
> now some of that is split into tapset/linux/$arch too.
> 
> Then runtime/loc2c-runtime.h also has a lot of arch-specific code that
> you'll need to fill in for mips, in order to do any register or memory
> access in your probes.
> 
> Those are the biggies I can think of, but smaller stuff may also be
> sprinkled about.  For instance, if you want process.mark probes (SDT),
> there's a tiny bit of arch #ifdefs in sdt.h, and then tapsets.cxx
> sdt_uprobe_var_expanding_visitor::visit_target_symbol_arg() will need to
> learn mips too.
> 
> Wade Farnsworth might be able to identify more points, as he's been
> working to get ARM support in shape.  It would be nice to start a
> porting guide on our wiki for these things.
> 
> > Anyone started already with mips?
> 
> Just you, afaik. ;)
> 
> 
> Josh