From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78253 invoked by alias); 17 Aug 2016 18:28:12 -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 78242 invoked by uid 89); 17 Aug 2016 18:28:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=combinations, H*f:sk:06cf338, H*i:sk:06cf338, H*MI:sk:06cf338 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 ESMTP; Wed, 17 Aug 2016 18:28:01 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2E4B361A0D; Wed, 17 Aug 2016 18:28:00 +0000 (UTC) Received: from [10.13.129.231] (dhcp129-231.rdu.redhat.com [10.13.129.231]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7HIRxNf008139; Wed, 17 Aug 2016 14:27:59 -0400 Subject: Re: exercising current aarch64 kprobe support with systemtap To: David Smith , Pratyush Anand References: <0a594132-796b-779d-b473-a06c0f3e8ae8@redhat.com> <20160627141840.GB8139@dhcppc9> <577EA7EE.2070607@linaro.org> <20160803131302.GC18785@localhost.localdomain> <2947a749-a518-d560-f768-60cc2f2c691e@redhat.com> <20160804044230.GB22191@localhost.localdomain> <20160804143549.GF22191@localhost.localdomain> <06cf3384-f909-dce5-b223-c25eb3ee49a9@redhat.com> Cc: David Long , systemtap@sourceware.org, Mark Brown , Jeremy Linton , "Frank Ch. Eigler" From: William Cohen Message-ID: Date: Wed, 17 Aug 2016 18:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <06cf3384-f909-dce5-b223-c25eb3ee49a9@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q3/txt/msg00169.txt.bz2 On 08/17/2016 02:04 PM, David Smith wrote: > On 08/17/2016 09:36 AM, William Cohen wrote: >> Hi, >> >> I was able to locally build uptream_arm64-devel branch of >> https://github.com/pratyushanand/linux.git with the configure >> from fedora rawhide and run the systemtap tests. Pratyush were >> there changes in patches between these versions? The only other >> difference is that the machine above was a fedora 24 machine rather >> than a RHELSA, so there would be differences in the compiler and >> other tools. The results (systemtap.log and systemtap.sum) are at: >> >> http://people.redhat.com/wcohen/aarch64/20160817/ > > ... stuff deleted ... > >> There are also some differences in the syscalls used on aarch64 that >> cause some of the tests to fail. > > I looked a bit at those syscall failures, and I'm not sure what is going > on. Note that the syscall/nd_syscall test cases pass completely on RHEL7 > aarch64. I did see one easy fix - you were getting registration errors > for the sched_[gs]etaffinity syscalls. Commit 619425f makes them fully > optional. The functions are actually there otherwise the error would happen during the earlier passes. The kprobes registration errors are due to the the heuristic that scans backward through the instructions to make sure that the kprobe is not in an atomic region. The heuristic got past the beginning of the function and interprets some of the data before the start of the function as the start of an atomic region. There is a proposed fix for this, but it is not in this particular kernel. There are some syscalls that either are a bit different in implentation or do not fail in the same way as x86 that are causing some of the tests to fail. For example syscall.fork doesn't seem to be implemented on aarch64 and setgroups return 0 rather than an error for some argument combinations. > > I'd need access to that machine to debug the other syscall failures further. > Thanks, -Will