This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SystemTap for Android - patchset


On 07/07/2016 02:01 PM, Alexander Lochmann wrote:
> 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.
>>
>> 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.
>>
>> ====
>> 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 <= KERNEL_VERSION(3,0,200) && LINUX_VERSION_CODE
>>> = 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
>>
>>  /* Kernels before 2.6.37 have cputime_to_msecs, but not usecs. */
>>  #elif defined(cputime_to_msecs)
>> ====
>>
>> I've got a couple of thoughts here:
>>
>> - 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.

Right. So, I checked in your fix as commit 2cc20af.

Thanks.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]