Prev: Removing dead ARCH_GUMSTIX_ORIG
Next: What's the relationship between Linux driver running priority and FIFO policy?
From: Srikar Dronamraju on 9 Jul 2010 01:00

Thanks for trying and informing of the problem. This problem occurs
when compiling perf with elfutils-devel > 0.138 installed. I am
resending the patch 11/12 which was "[PATCHv8 2.6.35-rc4-tip 11/12]
perf: perf interface for uprobes"

I probably messed it up while merging to the latest tip/master.

--
Thanks
Srikar


> I can't actually get perf to build with these patches applied ontop
> of the -tip tree master branch:
>
> CC util/probe-finder.o
> til/probe-finder.c: In function 'alloc_trace_arg_ref':
> util/probe-finder.c:412: error: invalid application of 'sizeof' to incomplete type 'struct kprobe_trace_arg_ref'
> util/probe-finder.c:414: error: dereferencing pointer to incomplete type
> cc1: warnings being treated as errors
> util/probe-finder.c: In function 'convert_variable_location':
> util/probe-finder.c:428: error: initialization from incompatible pointertype
> util/probe-finder.c:444: error: dereferencing pointer to incomplete type
> util/probe-finder.c:445: error: dereferencing pointer to incomplete type
> util/probe-finder.c:447: error: dereferencing pointer to incomplete type
> util/probe-finder.c:448: error: dereferencing pointer to incomplete type
> util/probe-finder.c:449: error: dereferencing pointer to incomplete type
> util/probe-finder.c:489: error: dereferencing pointer to incomplete type
> util/probe-finder.c:490: error: dereferencing pointer to incomplete type
> util/probe-finder.c:494: error: dereferencing pointer to incomplete type
> util/probe-finder.c:495: error: dereferencing pointer to incomplete type
> util/probe-finder.c: At top level:
> util/probe-finder.c:503: error: 'struct kprobe_trace_arg' declared inside parameter list
> util/probe-finder.c:503: error: its scope is only this definition or declaration, which is probably not what you want
> util/probe-finder.c: In function 'convert_variable_type':
> util/probe-finder.c:505: error: dereferencing pointer to incomplete type
> util/probe-finder.c:513: error: dereferencing pointer to incomplete type
> util/probe-finder.c:514: error: dereferencing pointer to incomplete type
> util/probe-finder.c:541: error: dereferencing pointer to incomplete type
> util/probe-finder.c:543: error: invalid application of 'sizeof' to incomplete type 'struct kprobe_trace_arg_ref'
> util/probe-finder.c:556: error: dereferencing pointer to incomplete type
> util/probe-finder.c:557: error: dereferencing pointer to incomplete type
> util/probe-finder.c:579: error: dereferencing pointer to incomplete type
> util/probe-finder.c:580: error: dereferencing pointer to incomplete type
> util/probe-finder.c: In function 'convert_variable_fields':
> util/probe-finder.c:617: error: invalid application of 'sizeof' to incomplete type 'struct kprobe_trace_arg_ref'
> util/probe-finder.c: In function 'convert_variable':
> util/probe-finder.c:718: error: passing argument 2 of 'convert_variable_type' from incompatible pointer type
> util/probe-finder.c:501: note: expected 'struct kprobe_trace_arg *' but
> argument is of type 'struct probe_trace_arg *'
> make: *** [util/probe-finder.o] Error 1
> hch(a)brick:~/work/linux-2.6-tip/tools/perf$
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 20 Jul 2010 00:30
I tried this again and it worked. That is kinda worked becuase I could
use it to trace things in my running bash instance, but haven't really
figured out how to trace something useful using the pid based interface.
The processes I care about really don't run long enough for that.

So thanks for the good work so far, but we'll really need a way to
define the trace points per-file and have a way to invoke a program
with tracing that uses it enabled.

A minor note on perf probe -S output: This seems to include a lot of
T.456 or similar labels, which from my recollection are gcc internal
things. It would be good to filter those out as they aren't quite
useful and just fill up the list.


And I really need to complain about the per-patch changelogs inside
the visible commit message again. I know you disagree, but it's
a real pain to read through it in git-log when you look for information
about the patch (which for some of the patches is rather short anyway)
and all you see is some rather useless patch versioning changelogs.
This is what basically all patches to the kernel do, and what's also
suggested in Documentation/SubmittingPatches.

While talking about changelogs: your patches duplicate the patch
subject line inside the mail body, leading to rather funny git
commit messages after a git-am:

commit c32a1b63db113bb1508dbf01af34d29f6cda747a
Author: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com>
Date: Mon Jul 12 16:04:42 2010 +0530

perf: show functions in a file without using pid

[RFC] perf: show functions in a file without using pid

...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Srikar Dronamraju on 20 Jul 2010 02:40

> I tried this again and it worked. That is kinda worked becuase I could

Thanks for trying.

> use it to trace things in my running bash instance, but haven't really
> figured out how to trace something useful using the pid based interface.
> The processes I care about really don't run long enough for that.

I am working/(continue to work) on file based probes. But
currently spending some of my time merging the current patchset to
latest tip. Once this patchset gets pushed to tip, I should be able to
speed up the file based probing.

>
> So thanks for the good work so far, but we'll really need a way to
> define the trace points per-file and have a way to invoke a program
> with tracing that uses it enabled.
>
> A minor note on perf probe -S output: This seems to include a lot of
> T.456 or similar labels, which from my recollection are gcc internal
> things. It would be good to filter those out as they aren't quite
> useful and just fill up the list.

Okay .. will take a look. Offhand I dont know about the T.456
labels, so I will google and see if its possible for us to identify if
its a t.456 label. However if you know how to identify a t456 label
from normal functions, then it would be great.

>
>
> And I really need to complain about the per-patch changelogs inside
> the visible commit message again. I know you disagree, but it's
> a real pain to read through it in git-log when you look for information
> about the patch (which for some of the patches is rather short anyway)
> and all you see is some rather useless patch versioning changelogs.

I am okay with dropping the Changelog or moving the Changelog under the
--- section. However I had retained it because Stephen Rostedt
replied to your post saying he found Changelog to be useful.

Assuming, he is fine dropping the changelog, I will move the
Changelog to the --- section as suggested by you.

> This is what basically all patches to the kernel do, and what's also
> suggested in Documentation/SubmittingPatches.

Agree.

>
> While talking about changelogs: your patches duplicate the patch
> subject line inside the mail body, leading to rather funny git
> commit messages after a git-am:
>
> commit c32a1b63db113bb1508dbf01af34d29f6cda747a
> Author: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com>
> Date: Mon Jul 12 16:04:42 2010 +0530
>
> perf: show functions in a file without using pid
>
> [RFC] perf: show functions in a file without using pid

Okay, I shall drop the Subject from the body of the patch next time I
send the patchset.

--
Thanks and Regards
Srikar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 20 Jul 2010 17:10
Em Tue, Jul 20, 2010 at 12:08:05PM +0530, Srikar Dronamraju escreveu:
> > A minor note on perf probe -S output: This seems to include a lot of
> > T.456 or similar labels, which from my recollection are gcc internal
> > things. It would be good to filter those out as they aren't quite
> > useful and just fill up the list.
>
> Okay .. will take a look. Offhand I dont know about the T.456
> labels, so I will google and see if its possible for us to identify if
> its a t.456 label. However if you know how to identify a t456 label
> from normal functions, then it would be great.

We may have some hint on the symtab, having access to one of those files
to look at its symtab will help.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Srikar Dronamraju on 20 Jul 2010 22:50

> Em Tue, Jul 20, 2010 at 12:08:05PM +0530, Srikar Dronamraju escreveu:
> > > A minor note on perf probe -S output: This seems to include a lot of
> > > T.456 or similar labels, which from my recollection are gcc internal
> > > things. It would be good to filter those out as they aren't quite
> > > useful and just fill up the list.
> >
> > Okay .. will take a look. Offhand I dont know about the T.456
> > labels, so I will google and see if its possible for us to identify if
> > its a t.456 label. However if you know how to identify a t456 label
> > from normal functions, then it would be great.
>
> We may have some hint on the symtab, having access to one of those files
> to look at its symtab will help.

I tried searching for t.456 gcc labels in google. I dont think I found
anything interesting. Are we looking at not listing symbols that end
with @plt? Can you please list an example t.456 label. Also any pointers to
where I can find more information on the same would be very useful.

-Srikar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Removing dead ARCH_GUMSTIX_ORIG
Next: What's the relationship between Linux driver running priority and FIFO policy?