On Thu, 2013-10-31 at 11:57 +0100, Ingo Molnar wrote:
> * Mark Wielaard wrote:
> > On Wed, 2013-10-30 at 13:51 +0200, Pekka Enberg wrote:
> > > On 10/30/13 12:05 PM, Masami Hiramatsu wrote:
> > > > To find all system libraries, we can use ldconfig.
> > > >
> > > > $ ldconfig --print-cache
> > > >
On Thu, Oct 31, 2013 at 11:57:59AM +0100, Ingo Molnar wrote:
> I suppose those Java libraries ought to show up in
> /etc/prelink.cache though, right?
I just checked, none of my systems have prelinking enabled by default;
so its not something you can rely on.
ISTR prelinking defeated ASLR and thu
* Mark Wielaard wrote:
> On Wed, 2013-10-30 at 13:51 +0200, Pekka Enberg wrote:
> > On 10/30/13 12:05 PM, Masami Hiramatsu wrote:
> > > To find all system libraries, we can use ldconfig.
> > >
> > > $ ldconfig --print-cache
> > >
> > > shows what dynamic libraries will be loaded. On my own lapto
On Wed, 2013-10-30 at 13:51 +0200, Pekka Enberg wrote:
> On 10/30/13 12:05 PM, Masami Hiramatsu wrote:
> > To find all system libraries, we can use ldconfig.
> >
> > $ ldconfig --print-cache
> >
> > shows what dynamic libraries will be loaded. On my own laptop (running
> > ubuntu13.04) shows ~1000
* Pekka Enberg wrote:
> On 10/30/13 12:05 PM, Masami Hiramatsu wrote:
> >To find all system libraries, we can use ldconfig.
> >
> >$ ldconfig --print-cache
> >
> >shows what dynamic libraries will be loaded. On my own laptop (running
> >ubuntu13.04) shows ~1000 libs.
>
> Good point. That defini
On 10/30/2013 03:35 PM, Masami Hiramatsu wrote:
(2013/10/26 20:16), Frank Ch. Eigler wrote:
Note that a $PATH search excludes shared libraries, which can also
carry markers. Adding /usr/lib* in more than doubles the
work, then there's /usr/libexec etc.
To find all system libraries, we can use
On 10/30/13 12:05 PM, Masami Hiramatsu wrote:
To find all system libraries, we can use ldconfig.
$ ldconfig --print-cache
shows what dynamic libraries will be loaded. On my own laptop (running
ubuntu13.04) shows ~1000 libs.
Good point. That definitely narrows down the scanned set.
(2013/10/29 3:45), Pekka Enberg wrote:
> On 10/28/13 6:59 PM, David Ahern wrote:
> > I often use perf-list to lookup an exact event name, and I do not want
> > to see it taking many seconds to minutes to run (not everyone is
> > running on an SSD). I also run perf on many different OS versions w
(2013/10/26 20:16), Frank Ch. Eigler wrote:
> Pekka Enberg writes:
>
>> Is there a technical reason why 'perf list' could not show all the
>> available SDT markers on a system and that the 'mark to event'
>> mapping cannot happen automatically? [...]
>
> A quick experiment with:
>
> find `ech
On Tue, Oct 29, 2013 at 4:51 PM, Mark Wielaard wrote:
> A nice user case to think about when designing this interface might be
> the java hotspot jvm (libjvm.so). It has SDT markers with the same name
> that might occur at multiple addresses depending on code path taken or
> compiler optimization.
On 10/29/2013 07:35 PM, Pekka Enberg wrote:
On 10/29/2013 11:55 AM, Hemant Kumar wrote:
1. Where this cache should be? Keeping it in tracing directory inside
the debugfs
directory should seem more feasible. And, shall this cache be shareable?
You can't share all of the cache because otherwise
On Tue, 2013-10-29 at 12:19 +0900, Masami Hiramatsu wrote:
> (2013/10/29 2:48), Pekka Enberg wrote:
> > For the 32-bit and 64-bit libc case, why cannot 'perf list'
> > by default print out something like:
> >
> > $ perf list
> >
> >libc:setjmp [SDT marker group]
> >
> > and provide a '--full
On 10/29/2013 11:55 AM, Hemant Kumar wrote:
1. Where this cache should be? Keeping it in tracing directory inside
the debugfs
directory should seem more feasible. And, shall this cache be shareable?
You can't share all of the cache because otherwise you'll expose details
on binaries that not
On 10/29/2013 12:15 AM, Pekka Enberg wrote:
[...]
If you build a cache of DSOs and executables that have SDT makers (with a
SHA1 hash), the cache size bound by SDT marker annotated files. You
probably can then unconditionally scan the cached filenames for SDT
markers for 'perf list'. And once you
Hi Ingo,
On Sat, 26 Oct 2013 11:50:23 +0200, Ingo Molnar wrote:
> * Srikar Dronamraju wrote:
>
>> Hi Pekka,
>>
>> > >
>> > > You can now use it in all perf tools, such as:
>> > >
>> > > perf record -e libc:my_event -aR sleep 1
>> >
>> > Is there a technical reason why 'perf list' could not
Hi Masami,
On Tue, 29 Oct 2013 12:19:37 +0900, Masami Hiramatsu wrote:
> (2013/10/29 2:48), Pekka Enberg wrote:
>> For the 32-bit and 64-bit libc case, why cannot 'perf list'
>> by default print out something like:
>>
>> $ perf list
>>
>>libc:setjmp [SDT marker group]
>>
>> and provide a '-
(2013/10/29 2:48), Pekka Enberg wrote:
> On 10/28/13 7:31 PM, Srikar Dronamraju wrote:
But what if a system has both 32 bit libc and 64 bit libc?
Wont we could end up with 2 libc:setjmp?
Should we give some more intelligence into perf to choose the 64 bit
libc over 32 bit one?
>
(2013/10/29 2:31), Srikar Dronamraju wrote:
>>>
>>> But what if a system has both 32 bit libc and 64 bit libc?
>>> Wont we could end up with 2 libc:setjmp?
>>> Should we give some more intelligence into perf to choose the 64 bit
>>> libc over 32 bit one?
>>
>> You can just trace both of them by def
On 10/28/13 6:59 PM, David Ahern wrote:
> I often use perf-list to lookup an exact event name, and I do not want
> to see it taking many seconds to minutes to run (not everyone is
> running on an SSD). I also run perf on many different OS versions with
> an NFS home directory, and do not want to s
On 10/28/13 7:31 PM, Srikar Dronamraju wrote:
But what if a system has both 32 bit libc and 64 bit libc?
Wont we could end up with 2 libc:setjmp?
Should we give some more intelligence into perf to choose the 64 bit
libc over 32 bit one?
You can just trace both of them by default, no?
There has
> >
> >But what if a system has both 32 bit libc and 64 bit libc?
> >Wont we could end up with 2 libc:setjmp?
> >Should we give some more intelligence into perf to choose the 64 bit
> >libc over 32 bit one?
>
> You can just trace both of them by default, no?
>
There has to be a one to one associ
On 10/28/13 2:48 AM, Pekka Enberg wrote:
So I really hope this SDT effort and the ktap effort at least
make some effort in unifying all the nice functionality that's
simple to use and easy to discover. I really, really would
at the end of the day, just 'perf trace' like I 'perf stat' or
'perf rec
* Pekka Enberg [2013-10-28 14:42:13]:
> >So, it still needs a concrete binary path to list or, we should
> >support a syntax which specify actual binary, as like as below.
> >
> > perf probe 'my_event=%libc:setjmp@/lib64/libc.so.6'
> >
> >And perf list may show the marker as in same syntax (for
On 10/28/2013 04:11 PM, Srikar Dronamraju wrote:
But what if a system has both 32 bit libc and 64 bit libc?
Wont we could end up with 2 libc:setjmp?
Should we give some more intelligence into perf to choose the 64 bit
libc over 32 bit one?
You can just trace both of them by default, no?
On 10/28/13 1:23 PM, Masami Hiramatsu wrote:
By the way, what happens if multiple binaries has same SDT marker?
Yeah, perf list shows just one and ignores others. However, if we
probe one, and run binary which use the other one, user will never
see the marker.
So, it still needs a concrete binar
(2013/10/25 21:38), Pekka Enberg wrote:
> Hello Hemant,
>
> On Wed, Oct 23, 2013 at 7:05 AM, Hemant Kumar
> wrote:
>> This allows perf to probe into the sdt markers/notes present in
>> the libraries and executables. We try to find the associated location
>> and handle prelinking (since, stapsdt
(2013/10/26 18:50), Ingo Molnar wrote:
>
> * Srikar Dronamraju wrote:
>
>> Hi Pekka,
>>
You can now use it in all perf tools, such as:
perf record -e libc:my_event -aR sleep 1
>>>
>>> Is there a technical reason why 'perf list' could not show all the
>>> available SDT mar
* Pekka Enberg wrote:
> On 10/26/2013 02:16 PM, Frank Ch. Eigler wrote:
> >Pekka Enberg writes:
> >
> >>Is there a technical reason why 'perf list' could not show all the
> >>available SDT markers on a system and that the 'mark to event'
> >>mapping cannot happen automatically? [...]
> >A quick
On 10/26/2013 12:50 PM, Ingo Molnar wrote:
I think in 99% of the usecases people will either use pre-built
markers that come with their distro, or will be intimately aware of
the markers because they are in the very app they are developing.
So I wouldn't worry about 'user has a weird binary' cas
Hi David,
On 10/25/2013 06:20 PM, David Ahern wrote:
On 10/25/13 8:20 AM, Pekka Enberg wrote:
Technically feasible. But then we would have to parse each of the
libraries and executables to list them. Right? I am not sure if such a
delay is acceptable.
You could do it at 'perf list' time or ev
On 10/26/2013 02:16 PM, Frank Ch. Eigler wrote:
Pekka Enberg writes:
Is there a technical reason why 'perf list' could not show all the
available SDT markers on a system and that the 'mark to event'
mapping cannot happen automatically? [...]
A quick experiment with:
find `echo $PATH | tr
Pekka Enberg writes:
> Is there a technical reason why 'perf list' could not show all the
> available SDT markers on a system and that the 'mark to event'
> mapping cannot happen automatically? [...]
A quick experiment with:
find `echo $PATH | tr : ' '` -type f -perm -555 |
xargs read
* Srikar Dronamraju wrote:
> Hi Pekka,
>
> > >
> > > You can now use it in all perf tools, such as:
> > >
> > > perf record -e libc:my_event -aR sleep 1
> >
> > Is there a technical reason why 'perf list' could not show all the
> > available SDT markers on a system and that the 'market to
On 10/25/13 8:20 AM, Pekka Enberg wrote:
Technically feasible. But then we would have to parse each of the
libraries and executables to list them. Right? I am not sure if such a
delay is acceptable.
You could do it at 'perf list' time or even build time and cache it. And add
lazy discovery to
> Technically feasible. But then we would have to parse each of the
> libraries and executables to list them. Right? I am not sure if such a
> delay is acceptable.
You could do it at 'perf list' time or even build time and cache it. And add
lazy discovery to 'perf record' and friends.
> Also if
Hi Pekka,
> >
> > You can now use it in all perf tools, such as:
> >
> > perf record -e libc:my_event -aR sleep 1
>
> Is there a technical reason why 'perf list' could not show all the
> available SDT markers on a system and that the 'market to event'
> mapping cannot happen automatically?
>
Hello Hemant,
On Wed, Oct 23, 2013 at 7:05 AM, Hemant Kumar wrote:
> This allows perf to probe into the sdt markers/notes present in
> the libraries and executables. We try to find the associated location
> and handle prelinking (since, stapsdt notes section is not allocated
> during runtime). Pr
Hi,
On 10/24/2013 11:15 AM, Masami Hiramatsu wrote:
(2013/10/23 14:05), Hemant Kumar wrote:
This allows perf to probe into the sdt markers/notes present in
the libraries and executables. We try to find the associated location
and handle prelinking (since, stapsdt notes section is not allocated
(2013/10/23 14:05), Hemant Kumar wrote:
> This allows perf to probe into the sdt markers/notes present in
> the libraries and executables. We try to find the associated location
> and handle prelinking (since, stapsdt notes section is not allocated
> during runtime). Prelinking is handled with the
39 matches
Mail list logo
