public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: eranian@google.com, Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: perf record: why we used type casting of (uint64_t *) instead of int
Date: Fri, 25 May 2012 10:57:59 +0530	[thread overview]
Message-ID: <4FBF185F.4060007@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FBDFDA6.5010304@linux.vnet.ibm.com>

This code is breaking in powerpc systems.

(1) 'opt->value' gets updated inside the function parse_branch_stack via
    dereferencing a (uint64_t *) type casted pointer.

(2) But the value is not accessible when we again use opt->value via 
    dereferencing a (int *) type casted pointer.

(3) As a result record.opts.branch_stack remains 0 and unchanged by parse_branch_stack

This is caused by bit representation of 'uint64_t' and 'int' in powerpc systems. Bytes update
for the data (when accessed trough (uint64_t *) casting) is no longer available to the
data when accessed through (int *) type casting. Verified this from bit representation of
the data (accessed through both type casting methods).

However this problem does not seem to be present on an Intel box. Integer dereferencing of
the opt->value still gives the value which was updated as (uint64_t).

All this problem would not have been there if we had used (int *) instead of (uint64_t *) in
the first place inside parse_branch_stack function.

On Thursday 24 May 2012 02:51 PM, Anshuman Khandual wrote:

> Hey Stephane,
> 
> Just wondering why we used the type casting of (uint64_t *) on a data 
> which is defined as "int" in the structure of "perf_record_opts".
> 
> struct perf_record_opts {
>         struct perf_target target;
>         bool         call_graph;
>         bool         group;
>         bool         inherit_stat;
>         bool         no_delay;
>         bool         no_inherit;
>         bool         no_samples;
>         bool         pipe_output;
>         bool         raw_samples;
>         bool         sample_address;
>         bool         sample_time;
>         bool         sample_id_all_missing;
>         bool         exclude_guest_missing;
>         bool         period;
>         unsigned int freq;
>         unsigned int mmap_pages;
>         unsigned int user_freq;
>         int          branch_stack;
>         u64          default_interval;
>         u64          user_interval;
> };
> 
> static int
> parse_branch_stack(const struct option *opt, const char *str, int unset)
> {
> #define ONLY_PLM \
>         (PERF_SAMPLE_BRANCH_USER        |\
>          PERF_SAMPLE_BRANCH_KERNEL      |\
>          PERF_SAMPLE_BRANCH_HV)
> 
>         uint64_t *mode = (uint64_t *)opt->value;
> --
> Regards
> Anshuman Khandual
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



  reply	other threads:[~2012-05-25  5:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-24  9:21 perf record: why we used type casting of (uint64_t *) instead of int Anshuman Khandual
2012-05-25  5:27 ` Anshuman Khandual [this message]
2012-05-25  8:03   ` [PATCH] perf record: Fixing record option data type in parse_branch_stack Anshuman Khandual
2012-05-25  8:44     ` Stephane Eranian
2012-05-25 10:32       ` Anshuman Khandual
2012-05-25 14:47         ` Arnaldo Carvalho de Melo
2012-05-25  8:20   ` perf record: why we used type casting of (uint64_t *) instead of int Stephane Eranian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBF185F.4060007@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox