From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4115 invoked by alias); 4 Nov 2013 15:28:01 -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 4104 invoked by uid 89); 4 Nov 2013 15:28:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Nov 2013 15:27:59 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA4FRlAh027475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Nov 2013 10:27:48 -0500 Received: from x201 (vpn-225-76.phx2.redhat.com [10.3.225.76]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rA4FRhvN014223; Mon, 4 Nov 2013 10:27:44 -0500 From: Petr Machata To: William Cohen Cc: Mark Wielaard Subject: Re: [Fwd: Re: Regarding systemtap support for AArch64] References: <1383340682.3850.864.camel@bordewijk.wildebeest.org> CC: Masami Hiramatsu , systemtap@sourceware.org, Deepak Saxena , Krishna Dani , Jakub Pavelek Date: Mon, 04 Nov 2013 15:28:00 -0000 In-Reply-To: <1383340682.3850.864.camel@bordewijk.wildebeest.org> (Mark Wielaard's message of "Fri, 01 Nov 2013 22:18:02 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00150.txt.bz2 Mark Wielaard writes: > According to the call abi the simple integer value should be in > register "x0". It looks in the generated c code for the module that > it is trying to access the return value with: > > { int64_t value = fetch_register (0); STAP_RETVALUE = value; } Is this using ebl_return_value_location? That should be on the branch, and unless I'm interpreting things wrong, it's doing the right thing: $ ./tests/funcretval -e ~/tmp/aarch64-ble () fun_char: return value location: {0x50, 0} () fun_short: return value location: {0x50, 0} () fun_int: return value location: {0x50, 0} () fun_ptr: return value location: {0x50, 0} () fun_iptr: return value location: {0x50, 0} () fun_long: return value location: {0x50, 0} () fun_int128: return value location: {0x50, 0} {0x93, 0x8} {0x51, 0} {0x93, 0x8} [...] I don't think there are any real tests for this in elfutils--such that would really check that yes, the values that we expect are in the registers that ebl_return_value_location claims. An idea that I had was to start a binary that calls a function and crashes (br 0?), and then inspect the coredump to see if the values are in the registers that elfutils expect. But that seems cumbersome. I'm reluctant to use ptrace, but that would obviously work as well. > As a sanity check I ran a "make -s check" on the locally built aarch64 > elfutils to see if there were any issues with it. Yes, I know of the failures. The port isn't finished yet. I had to switch gears for some other work. I'm probably missing a bunch of hooks that need implementing, I'm working through them one at a time. Thanks, PM