From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75062 invoked by alias); 5 Aug 2015 16:25:58 -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 75053 invoked by uid 89); 5 Aug 2015 16:25:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS,TBC autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 05 Aug 2015 16:25:55 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 344AF2E122E; Wed, 5 Aug 2015 16:25:54 +0000 (UTC) Received: from [10.13.129.131] (dhcp129-131.rdu.redhat.com [10.13.129.131]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t75GPrxP010034; Wed, 5 Aug 2015 12:25:53 -0400 Subject: Re: What about MIPS support? To: Crestez Dan Leonard References: <5036AA9A.2010706@redhat.com> <55C204AC.4080106@redhat.com> Cc: systemtap@sourceware.org From: William Cohen Message-ID: <55C23910.4060707@redhat.com> Date: Wed, 05 Aug 2015 16:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-q3/txt/msg00071.txt.bz2 On 08/05/2015 11:36 AM, Crestez Dan Leonard wrote: > Hello, > > There is a slightly more up-to-date version of mips support for systemtap here: https://github.com/cdleonard/systemtap/commits/mips-2.7 > > That version is based on release 2.7, the email you replied was for some patches against release 1.6. I posted these updates mips patches for review some time ago but they are difficult to integrate properly. > > I only tested my version on my embedded target and never actually attempted to run the actual test suite. > > Regards, > Leonard Hi Leonard, I saw the later patch set from august 2014 emails earlier this week, but haven't really had a chance to try them, they don't apply cleanly to the current systemtap git. How hard would it be to freshen the mips patches to apply to the current systemtap git repo? -Will > > On Wed, Aug 5, 2015 at 3:42 PM, William Cohen > wrote: > > On 10/15/2012 05:21 PM, Victor Kamensky wrote: > > Hi All, > > > > It took us much much longer than originally expected. But it is better late than never. Here is our patches tarbal attached. Inside of tarbal (README file) and copied below I put short description of each patch. Some of patches are Cisco specific and may not be any interest for you. Some like MIPS support, cross compilation improvements, misc general fixes (i.e systemtap issue 6977), I think, could be quite useful to community. Since it is quilt patch series and patches may have patch apply order issues, we are publishing all of them, exactly as we use/apply them, regardless whether we consider them Cisco specific or not. > > > > As it was discussed, for now, I am just dropping our patches as is. Latter as time permits, I can work on cleaning them up, moving to latest systemtap git and try to prepare them for commit into systemtap tree. It would be great if folks could take a look at patches and/or patches description and indicate priorities/interests for specific patches on which I could start working first. > > > > Please advise if you would like me to post the same on different subject line on this mailing list (since it covers more than just mips support). I thought I just post it on original thread to get it proper closure. > > > Hi All, > > Last week I was on vacation, playing around with a MIPS base creator > board (http://www.elinux.org/MIPS_Creator_CI20), and seeing if I could > get systemtap running on it. After locally building the linux-3.0.8 > kernel I was able to massage the systemtap-mips.patch from > https://sourceware.org/ml/systemtap/2012-q4/msg00084.html, so that > current systemtap is buildable and able to run a portion of the > testsuite on MIPS. Attached is the current modified patch. The tests hung in > the ./systemtap.base/limits.stp tests and a number of tests failed > because of issues with utrace functions not being found. The > systemtap.sum is also attached to this email. > > -Will > > > ==== systemtap-1.6-cisco-patches/README start ============================= > > > > This is patches series that Cisco did on top of systemtap-1.6. Some of them are Cisco specific and most likely are not interesting for community. We decided to > > provide them here anyway in order to avoid breakage in applying patches, because > > of patch application order issues. > > > > Other like MIPS support, cross compilation improvements, misc general fixes may > > be some interest for SystemTap community. > > > > Patch description follows order of patches in series file: > > > > systemtap-configure_cross_compile.patch - change in configure logic to make it > > more cross compilation environment friendly (in cross compile environment > > one cannot test presence of /usr/include files; those are from host). We > > don't use nss3 and avahi in our target so for now just introduce option > > that could disable them. Most likely issue is fixed in latest tree. > > > > systemtap-unwind-table-size.patch - IOS code is too big, we are hitting limit > > on unwind symbol table size. Increase the limit for now. In future it would > > be good code to adjust those values dynamically. > > > > systemtap-fde_byte_order_fix.patch - Fix reading fde entry in case of cross > > compilation where target and host have different byte order (i.e x86 host, > > be mips is target). > > > > systemtap-pointer-byte_size.patch - Fix related to ICC (intel compiler). There > > is a difference how DW_AT_byte_size is stored between gcc and icc. Current > > stap code tailored to gcc way. Need to go back and dig out more details > > here. > > > > systemtap-userland_caller.patch - Trying to introduce ucaller_addr and ucaller > > systemtap function. Most likely this code does not work. But currently > > patch is in our series file so keeping it for now. > > > > systemtap-biendian.patch - Support ICC biendian feature. It is described at > > http://software.intel.com/en-us/articles/dwarf-extensions-for-bi-endian-support/. Most > > like this code has no interest to anyone except Cisco. > > > > systemtap-old_compiler-task_finder.patch - Older gcc compiler (like gcc 3.4.x) > > produce compilation warning here, incorrectly assuming that dentry may be > > used uninitialized > > > > systemtap-cross_compile_helper.patch - Cross compilation assist. Actually > > include a lot of different small things. Here is the list of them (may not > > be complete): > > x) target system build may use difference 'gcc' and different 'make'. > > Different values could be specified through SYSTEMTAP_TARGET_CC and > > SYSTEMTAP_MAKE environment variable > > x) -y option introduced. Once specified it will indicate that systemtap > > compiler operates in cross compilation mode and value of option serves > > sysroot path value. Stap compiler supports several such options (details > > below) > > x) if compiler in cross compilation mode it does not use PATH and > > LD_LIBRARY_PATH to search for executables and libraries. Instead it uses > > SYSTEMTAP_CROSS_PATH and SYSTEMTAP_CROSS_LD_LIBRARY_PATH environment > > variables. PATH and LD_LIBRARY_PATH are usually different between host and > > target. Note SYSTEMTAP_CROSS_PATH and SYSTEMTAP_CROSS_LD_LIBRARY_PATH could > > be specified as relative of sysroot values, as well as host absolute > > pathes > > x) if stap compiler is in cross compilation mode it does not try to rebuild > > uprobes. It assumes that uprobes.ko is already built and installed in > > proper location in sysroot > > x) find_executable function is replaced with special sysroot class that > > handles different ways how file path needed during stap compilation (some > > times it needs file path in host terms, sometimes it would need it as it > > would be seen on target). Sysroot supports multiple sysroot. For example > > like in openwrt case one may have target root file system and overlay file > > system. Stap compiler in cross compilation mode can search both. Normally > > look up happens as iteration over sysroots and for each sysroot we iterate > > over list of directories specified in SYSTEMTAP_CROSS_PATH and > > SYSTEMTAP_CROSS_LD_LIBRARY_PATH. Quite normal case when one sysroot is > > specified so executables will be searched by adding sysroot value in front > > of directories specified by SYSTEMTAP_CROSS_PATH and > > SYSTEMTAP_CROSS_LD_LIBRARY_PATH. > > > > It is understood that above description may not be really sufficient to get > > full understanding of this patch. If community is interested I can give > > details explanation and see whether we can rework it. Above I just tried to > > give a taste of what sort of issue we are dealing with when we work in > > cross compiled environment > > > > systemtap-data-in_another_cu.patch - Fix for issue > > 6977 http://sourceware.org/bugzilla/show_bug.cgi?id=6977. We found it is > > very annoying and limiting for script writers, so we fixed it. It deals > > with situation of accessing global variables that are defined in *other* > > compilation units. > > > > systemtap-composed_rootfs_finder.patch - in embedded universe final root file > > system may be composed as link farm to set of files system. Example is > > Openwrt root file system and overlay. Systemtap runtime searches > > executables by canonical name. It won't work for link farm case. For > > link farm case ELF file name compiled into script is used as primary file > > path to check for file in file system or as key in list of file systems > > that participate in composition of final link farm. Outside of Cisco > > patch may have interest to distros like OpenWrt. > > > > systemtap-line_range_issue_fix.patch - memory leak and crash in > > iterate_over_srcfile_lines in case of line ranges. > > > > systemtap-icc_line_number.patch - deal with the way how ICC generates line > > number information. > > > > systemtap-data-in_library.patch - fix issues of accessing global data in > > libraries (opposed to executables) Not sure whether it is applicable to > > latest tree. > > > > systemtap-mips-uprobes.patch - MIPS uprobes kernel module code. > > > > systemtap-mips.patch - MIPS systemtap runtime and and tapset code. > > > > systemtap-ppc32.patch - runtime fixes for powerpc 32bit case. > > > > systemtap-smaller_buffer_size.patch - stap debugfs 1Mb buffer size is too big > > for systems like WRT54GL, where whole box has 16Mb or 32Mb of memory. > > Change 'b' option handling, so smaller buffers could be specified (i.e in > > Kbytes). Patch tries to be backward compatible with previous option usage > > - if no size letter is specified, it is treated like Megabytes > > > > systemtap-incorrect_kernel_buildid_hack.patch - there are idiosyncrasies in > > Cisco build system when kernel rebuilt twice and buildid in target image > > does not correspond to one we left to deal with on the host. This is hack > > to deal with it. Should be ignored by everyone else. > > > > systemtap-ios_keyword.patch - Cisco specific patch. Should be ignored by > > everybody else. Introduces ios keyword (along with 'process' and 'kernel'). > > It deals with the fact that IOS process canonical name changes depending > > on IOS image feature key. 'ios' keyword allows us to have scripts reusable > > across different target images. Real ios process name is passed with -i > > option by higher level wrapper script. > > > > systemtap-no_userland_prologue_search.patch - Add option '-U' that disables > > function prologue searches in user-land processes. Current -P affects only > > kernel probes. > > > > systemtap-kernel_source_tree.patch - Option -T allows to specify location of > > kernel sources. Normally needed only in cross compilation environment. > > > > systemtap-uprobes_in_kernel_as_module.patch - Fix for case when in cross > > compilation environment we may have uprobes built as module in kernel > > build (opposite to built by systemtap). In this case, in order for > > kernel_built_uprobes function to see unregister_uprobe symbol it has to be > > added into kernel_exports even-though it comes from module (not uprobes) > > > > systemtap-remote_hack.patch - allows remote_uris mechanism to work in cross > > compilation environment, where target kernel release won't be the same as > > host kernel release > > > > systemtap-cross_testsuite.patch - Attempt to change testsuite to operate in > > cross compilation environment where access to target happens either through > > dejagnu remote target facilities or through stap --remote mechanism. > > Massive patch, across bunch of test cases, not sure whether community has > > any interest in it. It was used by us to validate systemtap operation on our > > targets. In order to run, it requires stap board specific config (not > > provided here), which would specify things like stap_board_args, and others. > > > > systemtap-enable_vma_tracker.patch - cover corner cases where > > _stp_umodule_relocate is used but vma_tracker is not enabled, while it > > should be, becuase it uses stap_find_vma_map_info_user function. > > > > Thanks, > > Victor > > > > > > On Thu, 23 Aug 2012, Josh Stone wrote: > > > >> On 08/22/2012 01:04 PM, Victor Kamensky wrote: > >>> Hi Per, Josh, > >>> > >>> We (Cisco) have pretty much full systemtap MIPS port. > >> [...] > >>> 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. > >> > >> This is good news, and better that you're spurred now to share it. :) > >> > >>> 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. > >> > >> IMO, it would be good to go ahead and post the 1.6 patches directly > >> after your legal clears it. Then if you're willing and able to rebase > >> that onto the latest git, that's great, but we don't need to hold up > >> everything for that possibility. > >> > >> Thanks, > >> Josh > >> > > > > > -- > -- > Regards, > Leonard