From: Kapileshwar Singh <kapileshwar.singh@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Namhyung Kim <namhyung@kernel.org>,
Javi Merino <Javi.Merino@arm.com>,
David Ahern <dsahern@gmail.com>, Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH] tools lib traceevent: Mask higher bits of str addresses for 32-bit traces
Date: Thu, 17 Sep 2015 15:58:26 +0100 [thread overview]
Message-ID: <55FAD512.5030206@arm.com> (raw)
In-Reply-To: <20150917091154.575d031f@gandalf.local.home>
Hi Steve,
Thanks for looking into this!
On 17/09/15 14:11, Steven Rostedt wrote:
> On Thu, 17 Sep 2015 12:14:36 +0100
> Kapileshwar Singh <kapileshwar.singh@arm.com> wrote:
>
>> When a trace recorded on a 32-bit device is processed with a 64-bit
>> binary, the higher 32-bits of the address need to be masked.
>>
>> The lack of this results in the output of the 64-bit pointer
>> value to the trace as the 32-bit address lookup fails in find_printk.
>>
>> Before:
>> burn-1778 [003] 548.600305: bputs: 0xc0046db2s: 2cec5c058d98c
>>
>> After:
>> burn-1778 [003] 548.600305: bputs: 0xc0046db2s: RT throttling activated
>>
>> The problem occurs in PRINT_FEILD when the field is recognized as a pointer
>> to a string (of the type const char *)
>
> Actually, there's two bugs here. You only fixed one of them.
>
>>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>> Cc: Namhyung Kim <namhyung@kernel.org>
>> Cc: Javi Merino <javi.merino@arm.com>
>> Cc: David Ahern <dsahern@gmail.com>
>> Cc: Jiri Olsa <jolsa@kernel.org>
>> Reported-by: Juri-Lelli <juri.lelli@arm.com>
>> Signed-off-by: Kapileshwar Singh <kapileshwar.singh@arm.com>
>> ---
>> tools/lib/traceevent/event-parse.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
>> index 4d885934b919..39163ea4a048 100644
>> --- a/tools/lib/traceevent/event-parse.c
>> +++ b/tools/lib/traceevent/event-parse.c
>> @@ -3829,6 +3829,17 @@ static void print_str_arg(struct trace_seq *s, void *data, int size,
>> if (!(field->flags & FIELD_IS_ARRAY) &&
>> field->size == pevent->long_size) {
>> addr = *(unsigned long *)(data + field->offset);
>
> addr is of type unsigned long. That means if we read a 64 bit record on
> a 32 bit machine (which is supported), this will be truncated.
>
> Perhaps we need to make addr into a unsigned long long, and then add:
>
> addr = (pevent->long_size == 8) ?
> *(unsigned long long *)(data + field->offset) :
> (unsigned long long )*(unsigned int *)(data + field->offset);
I agree, we need to handle both cases:
* Traces recorded using 32-bit addresses processed on a 64-bit machine
* Traces recorded using 64-bit addresses processed on a 32-bit machine
The change you suggested fixes both these cases.
Will send a v2 of the patch with the changes.
Regards,
KP
>
>
>
> -- Steve
>
>
>> +
>> + /* In case the long_size is 4. The higher 32bits
>> + * need to be masked for a successful lookup in
>> + * in the printk table. As the pointers are 32-bit
>> + * long. This could happen if a trace recorded on
>> + * 32-bit platform is processed using a 64-bit
>> + * binary
>> + */
>> + if (pevent->long_size == 4)
>> + addr = addr & 0xffffffff;
>> +
>> /* Check if it matches a print format */
>> printk = find_printk(pevent, addr);
>> if (printk)
>
next prev parent reply other threads:[~2015-09-17 14:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 11:14 [PATCH] tools lib traceevent: Mask higher bits of str addresses for 32-bit traces Kapileshwar Singh
2015-09-17 13:11 ` Steven Rostedt
2015-09-17 14:58 ` Kapileshwar Singh [this message]
2015-09-17 15:26 ` Namhyung Kim
2015-09-18 10:55 ` Kapileshwar Singh
2015-09-18 13:45 ` Steven Rostedt
2015-09-18 14:29 ` Kapileshwar Singh
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=55FAD512.5030206@arm.com \
--to=kapileshwar.singh@arm.com \
--cc=Javi.Merino@arm.com \
--cc=acme@redhat.com \
--cc=dsahern@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.