Re: [RFC 00/13] MIPS64 support

[Josh Stone <jistone at redhat dot com>]

On 09/01/2014 06:47 AM, Crestez Dan Leonard wrote:
> 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?

We don't have a formal process.  I've been meaning to review your
patches, just haven't got around to it, sorry.

> 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 think we can accept that, as long as we document the steps to get mips
working.  A page on the wiki is probably enough.

> 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.

Ok, I'll review from there when I can, hopefully next week sometime.  I
definitely understand not wanting to carry patches separately.  But even
when it's merged, please understand that most of us Red Hat folks don't
work with mips machines, so we'll still have to rely on interested
parties like yourself to make sure it doesn't regress.

>>> 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.

Just from the perspective of merging, we don't have to have complete
feature coverage.  It would be great for the kernel to get mips uprobes
support, but in stap we'll just work with what's available now.

>> 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.

I think the 0.160 API is a better way to go, especially since the main
Dwarf may not even be the right container for a given DIE when things
like .gnu_debugaltlink are considered.  That shouldn't be an issue for
is_elf_mips64(), but might matter if we ever want loc2c to make other
queries on the Dwarf structure.

But do guard that with _ELFUTILS_PREREQ please, so we don't force the
new minimum elfutils on everyone.  Whatever mips-stap documentation you
write can explain under what circumstances this is really necessary.


Josh