From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46588 invoked by alias); 7 Jul 2016 19:01:51 -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 46574 invoked by uid 89); 7 Jul 2016 19:01:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*i:sk:822425c, H*MI:sk:822425c, H*f:sk:822425c, staff X-HELO: unimail.uni-dortmund.de Received: from mx1.HRZ.tu-dortmund.de (HELO unimail.uni-dortmund.de) (129.217.128.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 07 Jul 2016 19:01:40 +0000 Received: from [192.168.178.104] (x5d83ed5d.dyn.telefonica.de [93.131.237.93]) (authenticated bits=0) by unimail.uni-dortmund.de (8.16.0.16/8.16.0.16) with ESMTPSA id u67J1Wno004707 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jul 2016 21:01:32 +0200 (CEST) Subject: Re: SystemTap for Android - patchset To: David Smith , Josh Stone , systemtap@sourceware.org References: <56e0c7f4-d317-f76b-5156-3569a6097b62@tu-dortmund.de> <577CF9A2.7050008@tu-dortmund.de> <822425cc-666c-c5dc-04bf-51898919a3b9@redhat.com> From: Alexander Lochmann Message-ID: <577EA70B.9080806@tu-dortmund.de> Date: Thu, 07 Jul 2016 19:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <822425cc-666c-c5dc-04bf-51898919a3b9@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Sf9aeveuShhN9lSnIkA613oVGa6ivetxU" X-IsSubscribed: yes X-SW-Source: 2016-q3/txt/msg00023.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Sf9aeveuShhN9lSnIkA613oVGa6ivetxU Content-Type: multipart/mixed; boundary="9sxMvCQ6E5wLuLxHktdjXpX2Nl4QFoDmU" From: Alexander Lochmann To: David Smith , Josh Stone , systemtap@sourceware.org Message-ID: <577EA70B.9080806@tu-dortmund.de> Subject: Re: SystemTap for Android - patchset References: <56e0c7f4-d317-f76b-5156-3569a6097b62@tu-dortmund.de> <577CF9A2.7050008@tu-dortmund.de> <822425cc-666c-c5dc-04bf-51898919a3b9@redhat.com> In-Reply-To: <822425cc-666c-c5dc-04bf-51898919a3b9@redhat.com> --9sxMvCQ6E5wLuLxHktdjXpX2Nl4QFoDmU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2528 On 07.07.2016 20:47, David Smith wrote: > On 07/06/2016 07:29 AM, Alexander Lochmann wrote: >> So. Let me start. >> First of all, I extracted the patches properly, and attached the files. >> (Btw, I found a third bug. :) ) >> FYI, I just fixed the bugs for the kernel versions I'm dealing with, >> because I don't know which other versions are affected as well. >=20 > The problem you are trying to fix in your patch "[PATCH 1/3] Definition > of cputime_to_usecs in Linux kernel 3.0 is broken" is interesting. I > don't think you've got quite the right solution. Testing for a kernel > version here works for you, but really isn't a general solution - > depending on arch there could be a kernel in that range with a > reasonable cputime_to_usecs(). I see. :-/ Lesson learned. >=20 > =3D=3D=3D=3D > diff --git a/tapset/linux/task_time.stp b/tapset/linux/task_time.stp > index f86f984..f3c276c 100644 > --- a/tapset/linux/task_time.stp > +++ b/tapset/linux/task_time.stp > @@ -27,8 +27,12 @@ > * Yet note some kernels (RHEL6) may already have both... */ > #if defined(cputime_to_usecs) > #if !defined(cputime_to_msecs) > +#if LINUX_VERSION_CODE <=3D KERNEL_VERSION(3,0,200) && LINUX_VERSION_CODE >> =3D KERNEL_VERSION(3,0,0) > +#define cputime_to_msecs(__ct) _stp_div64(NULL, > ({cputime_to_usecs(__ct)}), 1000ULL) > +#else > #define cputime_to_msecs(__ct) _stp_div64(NULL, > cputime_to_usecs(__ct), 1000ULL) > #endif > +#endif >=20 > /* Kernels before 2.6.37 have cputime_to_msecs, but not usecs. */ > #elif defined(cputime_to_msecs) > =3D=3D=3D=3D >=20 > I've got a couple of thoughts here: >=20 > - I wonder if we just couldn't always use your workaround (along with a > comment about why we're doing that). Why not? :) Since the kernel and every module of course is compiled with -O3 (or -O2?), it shouldn't make any difference in the resulting assembler code. >=20 > - Here's an untested workaround idea that might work for all kernels: >=20 > #define cputime_to_msecs(__ct) \ > ({ \ > unsigned long __usecs =3D cputime_to_usecs(__ct); \ > _stp_div64(NULL, __usecs, 1000ULL); \ > }) >=20 And so does this version. The compiler should be smart enough to recognize __usecs is a local variable, and thus could be stored in a register. - Alex --=20 Technische Universit=C3=A4t Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al --9sxMvCQ6E5wLuLxHktdjXpX2Nl4QFoDmU-- --Sf9aeveuShhN9lSnIkA613oVGa6ivetxU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXfqcLAAoJEFk+7QW8Pvb95nYP/A0q2EvUTZaHJIJFmoQBFUVy CF5OoiHMv3p6wt/7xuBynQa1wX8Jb3YthMXzW6x2D+MN98aDd3Z2PZF8U31ilmaD 80JYyvSA0DwgpF0q2pZIScN/ACgeoj6Dtw3UwwFTgj4clx/512cIsR2DJoLnF5CU 0+2QbpQ94Gy3TfM++W7bnFZyh9670wlXehD+pf1I960G7rXYiTvJu42rHznNvFM2 UNcE4AVao3Nds1s6Fj0qrtpXgWaaZ4TOQh1G0D3iPSxm5jRcwig705TtAXLpYwaM +yHFvYWN7Z/vSo+ZQ7b+bx/+C6Rg1vfmry4Uxdt8+rqDvuKEM3R+GX6Nbi9VvcbX Yurw4sj1ia+Go7SXa+6VyhXNkdZFIWbTpnciCCCSSET9Ej2fUQ4kPOGs1LoVdqeX Md1Zpf1d7XlxacBfY6VMNzCT6V8je/GJEcxLBZngKKNtLdzblL2kDGVpOS2dNCJ3 c2c/GfkUHMMNnyF7Iu1AijkclOOBNkqv6bOGyPQu6d8+Uh8bXh/6iHx0moeOoIMx JAelcacRZh7Hvp/IDj4j/FCZsc2QDdAd6LiskaQ6Thmo4gEHQfX/P0IBEx/vRLB0 HuIT6BNHRblv+hhY4FugKQJHEGlbJmgwdZLQG6OURqgCXpPUrN2XcUvWk5cvfr49 sTkD2Gw/5EA/5q98S9V1 =MASD -----END PGP SIGNATURE----- --Sf9aeveuShhN9lSnIkA613oVGa6ivetxU--