Re: [RFC 00/13] MIPS64 support

[Crestez Dan Leonard <cdleonard at gmail dot com>]

Hello,

It's not clear exactly what it takes to add a new architecture to
systemtap. Could somebody from the core systemtap team explain what it
would take to merge these patches?

Right now there is no upstream elfutils support for mips and the
patches were only tested in an cross-compilation setup internal to my
company. It's not clear if this is OK.

I pushed an updated version of the mips patches to github:
https://github.com/cdleonard/systemtap/commits/mips . The patches are
ordered roughly by hackiness. The first 7 (up to and including
b0c93e569acca2db978c7c557ad929fa041b8669) should be mostly
uncontroversial and add basic mips support. Maybe we could get those
in and then discuss the rest? I would very much like to merge this, I
have no desire to maintain these patches separately.

More replies inline:

On Fri, Aug 15, 2014 at 4:27 AM, Victor Kamensky
<victor.kamensky@linaro.org> wrote:
> I looked that patches briefly. First couple things to notice:
>
> o posted patches are in unusual form: all diffs are in attachments (I
> hope it is not my mailer glitch). It is difficult to comment inline in
> such case. Could you please repost it using with 'git send-mail'.
> Also for patches posted by "git send-mail" I can pick them up into
> my git and test it. If you need help with it please let me know
> of the list.

I did use git send-email but with format.attach = true. I will remove
that setting when sending to the systemtap list if it helps.

> o commit messages are a bit terse or absent. For pieces that came
> from 487cb1bffaf4b56 I can help you to write those messages. I think
> proper commit message would be needed if we want it to be included
> in mainline systemtap tree.

Are you refering the later patches for backtracing suport? They are
clearly labeled as hacks and I am looking for better solutions.

> On 31 July 2014 13:21, Crestez Dan Leonard <cdleonard@gmail.com> wrote:
> > I did not test userspace support at all.
>
> Above would be quite noticeable endeavor - MIPS kernel does not have uprobes
> support. Previous uprobes patches that we posted were on top of previous version
> of uprobes that was included in systemtap tree and was relying on utrace patch.
> Linux kernel moved to newer uprobes and gradually and support for different CPU
> types appears in the kernel. My  colleague at Linaro, Dave Long, recently added
> ARM v7 uprobes kernel to mainline tree.
>
> I was mulling idea of moving our old MIPS uprobes patches to newer in kernel
> uprobes layer, but it seems to be not a small task. Anyone one this mailing list
> if you aware about any MIPS uprobes work please let me know.
I did not investigate uprobes support at all. But if you post even old
patches somewhere they might be useful to somebody some day. Probably
not soon.

> I just looked at our tree, we do have patches in elfutils that deal
> with at least
> with some if not all of above problems  ... the issue is that I need
> to go through
> my parent company open source process approval for elfutils contributions.
> Even if I start now it will take time :(.
>
> I agree with opinion expressed on this or similar thread above problems are
> better to be solved in elfutils layer.
The new release of elfutils 0.160 adds an API which can be used to
avoid patch 7 "loc2c: Add Dwarf pointer to location_context". I'll
rewrite that part, if it helps to get the patch into upstream. Other
than that it's not clear that it's elfutils job to fix the other
issues. I chose to restrict my patches to one project.

In particular the systemtap runtime has it's own code which parses
FDEs for backtracing, outside of elfutils. As far as I can tell it
works on the raw content of the .debug_frame/.eh_frame sections.

--
Regards,
Leonard