From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6702 invoked by alias); 31 Jul 2014 20:21:42 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 6676 invoked by uid 89); 31 Jul 2014 20:21:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f51.google.com Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 31 Jul 2014 20:21:33 +0000 Received: by mail-wg0-f51.google.com with SMTP id b13so3272902wgh.22 for ; Thu, 31 Jul 2014 13:21:29 -0700 (PDT) X-Received: by 10.180.210.167 with SMTP id mv7mr122768wic.72.1406838089355; Thu, 31 Jul 2014 13:21:29 -0700 (PDT) Received: from ixro-lcrestez-lin.ixiacom.com ([109.100.41.154]) by mx.google.com with ESMTPSA id lk7sm15678895wjb.24.2014.07.31.13.21.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Jul 2014 13:21:28 -0700 (PDT) From: Crestez Dan Leonard To: systemtap@sourceware.org Subject: [RFC 00/13] MIPS64 support Date: Thu, 31 Jul 2014 20:21:00 -0000 Message-Id: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------true" X-IsSubscribed: yes X-SW-Source: 2014-q3/txt/msg00098.txt.bz2 This is a multi-part message in MIME format. --------------true Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit Content-length: 4960 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. 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. 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 --------------true--