This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 00/13] MIPS64 support


[replying from my Linaro account, since it is the one I
use to subscribe to systemtap mailing list, but my
parent company account @cisco.com still works :)]

Hi Leonard,

Just caught this looking through systemtap mailing list messages.

Thank you for picking it up! As usual swamped by immediate issues
I never found time to follow up on our initial post :(

My parent company focus is drifting from MIPS, but we have bunch
of older MIPS boxes and we have ongoing migration to newer versions
of kernel and systemtap, so these patches are still interesting to us.

I believe now I can find spare some time to work with you on review
and cleaning this up.

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.

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.

More inline.

On 31 July 2014 13:21, Crestez Dan Leonard <cdleonard@gmail.com> wrote:
>
> I've been playing with systemtap on mips64 and finally got most of what I need
> from it to work:
> - kprobe insertion
> - examining structs via dwarf data
> - stack unwinding
>
> 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.

Anyway MIPS support by systemtap could move in phases, first get kernel
tracing only, then see if we have time for uprobes and user land.

> I know about the earlier patches by cisco from the systemtap-1.6-cisco-patches
> branch. Only commit 487cb1bffaf4b5661f42798d2e4047ec986b7438 was actually
> interesting to me, but it's a big one and I split off some small chunks. I
> think only patches 1, 2, 3 are strictly required. I don't particularly care
> about syscall probing or implementing print_regs. Patch 5 could probably be
> dropped off entirely. If it helps I could split this patch further.
>
> I was able to handle cross-compiling by writing a python wrapper which passes
> correct -g and -B CROSS_COMPILE=* arguments to stap itself. Cisco posted some
> "cross-compilation helpers" but I did not use them.
>
> One obvious cross-compiling issue I found is that unwind data is written in the
> translator's byte order. I believe patch 10 applies to all scenarios where the
> host and target have different byte orders.
>
> Some hacks are required because of some unusual behavior of gcc on mips64. I
> believe these hacks are not specific to my local setup but affect a wide range
> of released gcc versions. It's not clear to me why cisco didn't hit these
> issues. Maybe they used mips32 or were not interested in dwarf support?
>
> The first issue is that a 64bit mips kernel is compiled with -msym32 which
> results in 32bit dwarf symbols. These need to be detected and handled
> specially. I think that checking for address_size == 4 from dwarf_diecu on a
> target which is otherwise 64bit is correct. The way I'm checking this (patch 6)
> might slow down translation.
>
> Inside loc2c the CU address_size is used to determine the max_fetch_size, this
> becomes incorrect with -msym32. Handling this (patch 8) requires access to the
> elf header which requires a lot of code churn (patch 7). This could be avoided
> if elfutils exported a dwarf_die_getdwarf but this would be a new elfutils API.
>
> Apparently -msym32 also affects the FDE data for unwind support. It's not clear
> how to detect it cleanly in there. Apparently an "address_size" field can be
> included in the CIE, but I don't have it. Both eu-readelf and binutils readelf
> show corrupt FDEs. Patches 12 and 13 are evil hacks. Presumably I could try to
> interpret initial_address both ways and attempt to lookup the CU?
>
> Another issue is that struct fields are generated with a single DW_OP_constu
> instead of DW_OP_plus_uconst. Handling this is isolated in patch 9.

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.

Thanks,
Victor

> The patches are against systemtap's current HEAD. It would be great if you
> could include this mips support in systemtap upstream. I realize that some
> of the hacks would require some reworking. Suggestions are welcome.
>
> Crestez Dan Leonard (12):
>   mips: Minimal build support
>   mips: Define TIF_32BIT if missing
>   mips: Read _stp_deref and _stp_store_deref support
>   mips: Special get_cycles for cavium octeon
>   Force sign-extend statement addresses on mips64 -msym32
>   loc2c: Add Dwarf pointer to location_context
>   mips: Fix fetching params of type long on mips kernel
>   mips: dwflpp hack for struct fields being DW_OP_constu instead of
>     DW_OP_plus_uconst
>   Create debug_frame_hdr in target byte order
>   mips64: Initial unwind support
>   translator: Hack to interpret mips64 FDEs as 32bit for unwind
>   runtime: Hack to interpret mips64 FDEs as 32bit for unwind
>
> Victor Kamensky (1):
>   mips: runtime and tapset code from cisco
>
>  dwflpp.cxx                    |  62 +++++++++-
>  dwflpp.h                      |   1 +
>  loc2c-test.c                  |  27 +++--
>  loc2c.c                       |  36 ++++--
>  loc2c.h                       |   9 +-
>  runtime/compatdefs.h          |   8 ++
>  runtime/linux/arith.c         |  25 +++-
>  runtime/linux/copy.c          |   2 +-
>  runtime/linux/loc2c-runtime.h |  83 +++++++++++++
>  runtime/linux/runtime.h       |   2 +-
>  runtime/loc2c-runtime.h       |   9 ++
>  runtime/regs.c                | 117 ++++++++++++++++++
>  runtime/regs.h                |   4 +
>  runtime/stack-mips.c          |   7 ++
>  runtime/stack.c               |   2 +
>  runtime/syscall.h             |  49 ++++++++
>  runtime/time.c                |  16 +++
>  runtime/unwind.c              |  13 ++
>  runtime/unwind/mips64.h       |  80 ++++++++++++
>  runtime/unwind/unwind.h       |   2 +
>  tapset/errno.stp              |   2 +
>  tapset/linux/aux_syscalls.stp |   5 +-
>  tapset/linux/scheduler.stp    |   2 +-
>  tapset/linux/syscalls2.stp    |   8 ++
>  tapset/mips/aux_syscalls.stp  |  44 +++++++
>  tapset/mips/registers.stp     | 276 ++++++++++++++++++++++++++++++++++++++++++
>  tapsets.cxx                   |  15 +++
>  translate.cxx                 |  53 ++++++--
>  28 files changed, 917 insertions(+), 42 deletions(-)
>  create mode 100644 runtime/stack-mips.c
>  create mode 100644 runtime/unwind/mips64.h
>  create mode 100644 tapset/mips/aux_syscalls.stp
>  create mode 100644 tapset/mips/registers.stp
>
> --
> 2.0.1
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]