Hi Mathieu,
Since we have no other options currently (see LD_AUDIT discussion) we
really should get this merged into master. As said, it's thoroughly
tested and should not cause any ill side-effects.
Many Thanks,
Paul
On 07/04/2014 02:21 PM, Paul Woegerer wrote:
Since (at least) in the short
On 07/10/2014 03:24 PM, Mathieu Desnoyers wrote:
- Original Message -
From: Paul Woegerer paul_woege...@mentor.com
To: lttng-dev@lists.lttng.org, mathieu desnoyers
mathieu.desnoy...@efficios.com
Sent: Thursday, July 10, 2014 8:49:37 AM
Subject: Ping: Re: [PATCH lttng-ust] Bugfix for
On 07/09/2014 12:55 PM, Martin Townsend wrote:
Hi,
Using the instructions from
http://lists.lttng.org/pipermail/lttng-dev/2013-October/021540.html
I have added my own kernel module to lttng-modules and can successfully
trace my own custom events. I have to manually modprobe lttng_probe_xxx
Thanks for your feedback.
You made me think again how to address this issue from a different
angle. I found a nice practical solution.
Suppose you have a tracepoint provider:
ackermann_tracepoint.c + ackermann_tracepoint.h
To make the tracepoint provider robust against -finstrument-functions
On 07/08/2014 11:06 AM, Woegerer, Paul wrote:
If you don't mind using _Pragma (C99)
(see: https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html)
we should be able to make this happen automatically (#ifdef
TRACEPOINT_CREATE_PROBES _Pragma ... )
No need for _Pragma here. It's just:
diff --git
On 07/07/2014 04:57 PM, Mathieu Desnoyers wrote:
Merged into master and stable-2.4, thanks!
Thanks !
Hmmm ... but what to do about static inline function cds_list_empty
(included via lttng/ust-tracepoint-event.h - urcu/rculist.h -
urcu/list.h). Would you accept a patch that introduces
On 07/01/2014 07:14 PM, Alexander Monakov wrote:
On Tue, 1 Jul 2014, Woegerer, Paul wrote:
Unfortunately the current approach of delaying execution of main until
lttng-ust is available has several drawbacks. E.g. the dynamic linker
lock is taken during the execution the static ctor. Using
Hi Alexander,
The idea of this patch is to prevent deadlocks in the initialization
phase of lttng-ust when forks (e.g. for daemons) are happening in the
traced application.
lttng-ust uses a semaphore to block further execution of the program
until lttng-ust is fully initialized (see
?
Thank you again for your patience,
Gerlando
On 05/27/2014 04:58 PM, Woegerer, Paul wrote:
On 05/27/2014 04:41 PM, Gerlando Falauto wrote:
Hi Paul,
thank you very much for sharing this.
I had in the meantime run into the same suggestion
On 05/28/2014 12:38 PM, Woegerer, Paul wrote:
It would be interesting if
this treatment of hidden symbols is standardized or if this is just an
implementation-specific behavior of GNU ld.
Maybe this link contains the answer to that question:
http://docs.oracle.com/cd/E19683-01/816-7529
On 05/28/2014 03:04 PM, Gerlando Falauto wrote:
So the hidden symbols are *NOT* weak at all (at least with my buggy
compiler). They are just automagically defined by the linker.
I wrote weak, in the sense that it can be linked without providing a
definition somewhere.
See:
On 05/28/2014 04:30 PM, Gerlando Falauto wrote:
Hi Paul,
On 05/28/2014 04:14 PM, Woegerer, Paul wrote:
On 05/28/2014 03:04 PM, Gerlando Falauto wrote:
So the hidden symbols are *NOT* weak at all (at least with my buggy
compiler). They are just automagically defined by the linker.
I wrote
Hi Martin, Hi Gerlando,
this sounds a lot like the compiler bug I found recently in Yocto 1.6
(reproducible on ARM, x86 and PPC)
The problem in my case is that the Yocto generated GCC cross-compiler
translates:
extern struct tracepoint * const __start___tracepoints_ptrs[]
defined in
tracepoint.h
HTH,
Paul
Thank you,
Gerlando
On 05/27/2014 04:32 PM, Woegerer, Paul wrote:
Hi Martin, Hi Gerlando,
this sounds a lot like the compiler bug I found recently in Yocto 1.6
(reproducible on ARM, x86 and PPC)
The problem in my case is that the Yocto generated GCC cross
Hi Mathieu,
We use this feature in the new Codebench 2014.05 release (for
cyg-profile symbol resolution and ust-tracepoint source line lookup).
We will do what we can to make it stable and turn it into a fully
supported feature.
I'm currently busy finding out why LTTng 2.4 userspace tracing with
On 03/13/2014 09:12 AM, Lars Persson wrote:
It is useful when unpacking the distribution tarballs into another revision
control system that doesn't preserve timestamps. If we retrigger autoconf,
then some developer workstations will fail on the builds because they have
outdated autoconf
Hi David,
On 03/03/2014 11:24 PM, David OShea wrote:
Hi all,
Apologies if this is a stupid question, but is the “ip” context meant to
be used with LTTng-UST? I tried it out, and the address in the field
pointed to the TRACEPOINT_EVENT definition in my header file, i.e. not
to the
Hi Mathieu,
this is very unfortunate. I tested forks as well but couldn’t find any
issues on x86_64. Ironically, last week we found an issue that matches
your description on PowerPC but since we could not reproduce it on x86 I
blamed it on the peculiarities of that platform and worked on
I have looked a bit into the issue...
The ust_locking inside the dl_iterate_phdr triggers the deadlock.
If I just collect the base address info inside dl_iterate_phdr and dump
the collected data with trace_baddr afterwards (outside the
dl_iterate_phdr iteration) the deadlock will be prevented.
Hi Santiago,
it looks like uClibc does not have proper support for dlinfo().
You have two options:
Switch to a different C library suitable for embedded systems that does
have proper support for dlinfo(): http://www.eglibc.org/home
Build without liblttng-ust-dl (simply remove it from the list
On 02/14/2014 11:30 AM, Alexander Monakov wrote:
On Thu, 13 Feb 2014, Stefan Seefeld wrote:
Our compilation unit defines a bunch of functions with external linkage,
which access cur_alloc. And since gcc has no way to rule out that the
call to dlsym() will not cause any of these functions to be
That's excellent !
Thanks,
Paul
On 02/14/2014 03:23 PM, Alexander Monakov wrote:
On Fri, 14 Feb 2014, Paul Woegerer wrote:
As explained by Alexander Monakov, dlsym() is defined to be pure, thus the
compiler is allowed to assume that there is no need to write the changes
performed by
On 02/13/2014 05:40 PM, Mathieu Desnoyers wrote:
(adding back lttng-dev, and CC Paul E. McKenney. He may have
some interesting insight in this compiler reordering of store
vs function call.)
- Original Message -
From: Paul Woegerer paul_woege...@mentor.com
To: Mathieu Desnoyers
:52
To: Woegerer, Paul
Cc: Seefeld, Stefan; Paul E. McKenney; lttng-dev
Subject: Re: [lttng-dev] RFC: Fix crash in dlerror()
- Original Message -
From: Paul Woegerer paul_woege...@mentor.com
To: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Cc: Stefan Seefeld stefan_seef...@mentor.com
= dlsym(RTLD_NEXT, calloc, cur_alloc);
then (because of the aliasing of cur_alloc (caused by cur_alloc) the compiler
would be forced to store the effects done on cur_alloc into memory prior to
calling dlsym.
--
Thanks,
Paul
From: Woegerer, Paul
Sent
Good Morning Stefan,
On 02/13/2014 11:44 PM, Stefan Seefeld wrote:
On 02/13/2014 05:06 PM, Woegerer, Paul wrote:
Let me put it this way ...
If (hypothetically, just for the sake of the argument) we would have dlsym
with the following signature:
void *dlsym(void *handle, const char *symbol
Hi Simon,
On 02/06/2014 02:32 PM, Simon Marchi wrote:
script) is easier than XML, but it's still not bulletproof. Consider
this eventual yaml structure I just made up for the output of the
session list.
sessions:
- name: my_session
domain: kernel
events:
- name:
On 02/06/2014 03:42 AM, Jonathan Rajotte wrote:
Hello all,
After speaking with Michel Dagenais, Geneviève Bastien, folks over at EfficiOs
and Ericsson, a machine interface for lttng-tool would be a nice feature
to have. Olivier Cotte and me will be working on MI for the
next few weeks.
The
Works as expected.
Thanks,
Paul
On 12/16/2013 02:39 PM, Mathieu Desnoyers wrote:
Hi Paul,
I rewrote the patch to use a reference counting approach instead.
The effect should be the same. Here is the commit:
commit f0cc794d37abf59b4b8079612c7aa03dc305d92f
Author: Mathieu Desnoyers
Hi Jérémie,
On 12/04/2013 10:33 PM, Jérémie Galarneau wrote:
Session Configuration File Format
This is great news. Providing the ability to specify the specifics of a
session as data will benefit command line users as well as IDEs (talking
to lttng).
...
...
XML seems like a better option
Hi Mathieu,
Hi David,
thanks for putting this together.
I'm now able to reproduce the problem and I'm investigating options to
circumvent the deadlock.
I will keep you informed on any progress made.
For the time being I will send a patch to prevent
lttng_ust_baddr_statedump if
On 11/18/2013 08:59 AM, Amit Margalit wrote:
Hi,
I understand, and I see two issue with this -
1. The application will still perform all the tracking, but when the
event is to be generated, it will be checked and since it is
disabled, will not be emitted.
While the overhead of
Hi David,
Please also create a v2.3.1 for lttng-tools stable-2.3 so that I can
update all the lttng recipes for yocto/oe-core:
(see:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/lttng)
Many Thanks,
Paul
On 11/12/2013 06:29 PM, Mathieu Desnoyers wrote:
- Original
Hi Matthew,
I have a working solution for that (also based on LD_PRELOADing) as part
of my base address tracing stuff.
I'm going submit the whole patch series next week (hopefully).
Best,
Paul
On 11/04/2013 05:55 PM, Matthew Khouzam wrote:
Hello tracing arch-wizards,
I was working a bit on a
On 10/08/2013 01:03 PM, Michael Lausch wrote:
Hi,
I've developed a kernel module which defines TRACE_EVENTS. These events
are shown in /sys/kernel/debug/tracing/events and i can read them
from /sys/kernel/debug/tracing/trace if they are enabled.
But i want to use these events in lttng.
#
ling On 10/02/2013 04:35 PM, Thibault, Daniel wrote:
-Message d'origine-
De : Woegerer, Paul [mailto:paul_woege...@mentor.com]
Envoyé : 2 octobre 2013 03:38
The 64-bit version of lttng-tools works just fine with both, 32-bit and
64-bit userspace applications. No need to compile
Hi Alexandre,
For trivial examples you can go with 'nm -CS' (or the like), but when
you start to use liblttng-ust-cyg-profile.so in combination with shared
objects you will need to record base address information as well (to
allow you map a virtual memory address at a given point in time to
Hi Mathieu,
I recently created a high-level document to explain the prototype to my
colleagues. Maybe it is also useful to have that here on the mailinglist
(attached pdf).
Best,
Paul
On 08/27/2013 11:55 AM, Woegerer, Paul wrote:
...sorry, KMail was sending my draft without asking me first
On 09/10/2013 05:37 PM, Matthew Khouzam wrote:
On 13-09-10 03:00 AM, Woegerer, Paul wrote:
Hi Alexandre,
For trivial examples you can go with 'nm -CS' (or the like), but when
you start to use liblttng-ust-cyg-profile.so in combination with shared
objects you will need to record base address
On 08/27/2013 11:53 AM, Amit Margalit wrote:
Absolutely wonderful idea, IMHO.
Thanks!
The solution I suggest is based a previous solution (that was never
designed to get upstreamed). Semantic and payload structure of the
events haven't changed as they have proven sound. I agree that seeking
to
, Paul
Cc: lttng-dev@lists.lttng.org
Subject: Re: [lttng-dev] How to disable an event that's been enabled by a
wildcard selection or -a?
* Woegerer, Paul (paul_woege...@mentor.com) wrote:
On 05/02/2013 03:40 PM, Mathieu Desnoyers wrote:
Hi Paul,
I would be interested to see this feature
Hi Mathieu,
it would be great if your patch 'callsite: add ip context'
from branch ust/callsite could get merged to master.
(I fixed the conflicts, so it should apply without issues)
Your patch is the first step to enable lttng users to easily
look up the place in source that emitted a given
This follow-up patch provides the necessary bits to allow
specifying context ip for the add-context command.
Thanks,
Paul
--
Paul Woegerer, SW Development Engineer
Sourcery Analyzer http://go.mentor.com/sourceryanalyzer
Mentor Graphics, Embedded Software Division
From
On 05/03/2013 08:35 PM, Mathieu Desnoyers wrote:
* Woegerer, Paul (paul_woege...@mentor.com) wrote:
Without this change the user simply cannot make sure its own
constructor gets invoked after the trace provider constructors.
If we try to support tracing constructors, I'm concerned
On 05/02/2013 03:40 PM, Mathieu Desnoyers wrote:
Hi Paul,
I would be interested to see this feature upstream. Previously was not a
good timing to pull it in, because we were adding the concept of event
enablers within lttng-ust.
Sounds great. I will port our patch to master.
One thing
I ran some tests with the new function entry/exit instrumentations.
The tracepoint provider for lttng_ust_cyg_profile:func_entry and
func_exit does not properly forward the call_site argument to the
call_site field. The patch below fixes the problem.
From
As promised...
From acba8cd14abc7e61cf1346b5649972bac3ea0d53 Mon Sep 17 00:00:00 2001
From: Paul Woegerer paul_woege...@mentor.com
Date: Wed, 27 Mar 2013 17:02:27 +0100
Subject: [PATCH] Add man page for lttng-ust-cyg-profile
---
doc/Makefile.am |3 +-
On 03/04/2013 12:51 AM, David Bryant wrote:
Hello,
I'm trying to decide whether to use static or dynamic tracepoint probe
linkage. What are the factors that I should consider?
IMHO, whenever you are about to emit tracepoints from shared objects
it's desirable to have the tracepoint provider
Hi David,
On 02/14/2013 05:52 AM, David OShea wrote:
Hi,
My understanding (hopefully someone will correct me if I'm wrong) is that
each time you invoke 'lttng enable-event', your specification for the events
you want enabled is stored and applied, and/or potentially applied later if a
On 11/28/2012 06:16 PM, Gabbasov, Andrew wrote:
The code was verified to compile with latest versions in all stable
branches from 2.6.38.x to 3.6.x and 3.7-rc7.
I get this build failure on 3.5 with this patch:
CC [M] /home/compudj/work/lttng-modules/probes/lttng-probe-ext3.o
On 11/16/2012 04:54 PM, Julien Desfossez wrote:
Does that mean that the live tracing feature that currently lives in the
lttngtop-live branch will go into lttng-tools and babeltrace any time soon ?
The main change of lttng-tools 2.2 is the live tracing feature.
The way it is implemented in
I recently stumbled over the following lttng-ust limitation:
I tried to emit events from a shared objects constructor function:
__attribute__((constructor))
void func_constructor()
{
tracepoint( foo, bar );
}
Unfortunately this doesn't work because the constructor functions of LTTng
itself
On 11/22/2012 04:39 PM, Mathieu Desnoyers wrote:
* Woegerer, Paul (paul_woege...@mentor.com) wrote:
I recently stumbled over the following lttng-ust limitation:
I tried to emit events from a shared objects constructor function:
__attribute__((constructor))
void func_constructor
Thanks,
Mathieu
Cheers!
David
Woegerer, Paul:
Hi,
embedded users sometimes have to trace to tmpfs (e.g. streaming in not
an option due to missing network connectivity).
Ramdisks of 16M to 128M size are created and as long as the ram disk
does not get full, tracing works fine
On 10/11/2012 06:07 PM, Mathieu Desnoyers wrote:
* Woegerer, Paul (paul_woege...@mentor.com) wrote:
On 10/11/2012 04:58 PM, Mathieu Desnoyers wrote:
A couple a details to fix before I can merge this patch though:
Please also update instrumentation/events/mainline/sched.h to add the
original
On 10/11/2012 04:58 PM, Mathieu Desnoyers wrote:
A couple a details to fix before I can merge this patch though:
Please also update instrumentation/events/mainline/sched.h to add the
original mainline TRACE_EVENT, so we can keep the files in sync.
Ok, reconfigured Thunderbird, removed
On 09/10/2012 05:39 PM, Woegerer, Paul wrote:
On 09/10/2012 05:00 PM, David Goulet wrote:
With more options here to set either a custom destination or live
trace. What's the default? (no opts given). I would personally go for
a default one being to record in the session default trace files
As much as I like the lttng command line tool (that we have since
LTTng2) I still see people (who are not yet familiar with lttng)
struggle with the simple fact that it takes more than one command to
actually get something traced.
Issuing a sequence of commands like:
lttng create
lttng
On 09/10/2012 05:00 PM, David Goulet wrote:
Issuing a sequence of commands like:
lttng create lttng enable-event -u -a lttng start
my_foobar_traced_application 1 2 3 lttng stop lttng destroy
Small note here that the destroy is not needed. The stop forces a
subbuffer switch meaning that the
On Mon, Jul 30, 2012 at 3:28 AM, Woegerer, Paul paul_woege...@mentor.comwrote:
On 07/29/2012 10:26 PM, Rui Han wrote:
Hi,
I used lttng last week and didn't touch it ever since. I am trying to
use it again. I use lttng list -k, it give me error messages:
FATAL: Module lttng_tracer not found
On 07/20/2012 04:10 AM, bingfeng.z...@emc.com wrote:
Anyone can answer our questions? Mathieu?
*From:*bingfeng.z...@emc.com [mailto:bingfeng.z...@emc.com]
*Sent:* Wednesday, July 18, 2012 5:54 PM
*To:* lttng-dev@lists.lttng.org
*Subject:* [lttng-dev] some questions on lttng
Hello the dev
On 06/17/2012 05:08 PM, Lars wrote:
Hello,
I have recently started to use LTTng-UST and am using LD_PRELOAD
to make it possilbe to execute instrumented code on systems without
LTTng-UST installed.
To define LD_PRELOAD however affects too much. For instance all
forked processes also get the
On 07/17/2012 04:13 PM, Mathieu Desnoyers wrote:
I think we want to make the notrace always active. I don't see the point
in letting UST lib be compiled with those tracing stubs in place.
OK, I'll remove that ...
We should create a include/lttng/ust-compiler.h with:
#define
On 06/27/2012 08:33 PM, Mathieu Desnoyers wrote:
hrm, although possibly interesting, I don't think this semantic follows
the lttng UI event enabling semantic. There are a few use-cases to
cover:
1) enable tracepoints, start tracing, run app.
2) enable some tracepoints, start tracing, run app,
Hi,
In order to support situations where a user wants generally all
tracepoints enabled but specific tracepoints to be suppressed during a
trace session, I created a small patch that allows us to do the following:
...
lttng enable-event -u -c met_tools -a
lttng enable-event -u -c met_tools
Sorry that’s an old message I sent before I subscribed the lttng-dev
mailing list.
Please ignore.
--
Paul
On 04/24/2012 11:20 AM, Woegerer, Paul wrote:
Is there some way to make the userspace application block if the
buffer is full ?
I'm thinking about something like:
lttng enable-channel
Is there some way to make the userspace application block if the buffer
is full ?
I'm thinking about something like:
lttng enable-channel myblockingchannel --block
I know I can increase the subbuf-size but sometimes this is not an
option (embedded targets with less RAM).
--block would be a
On 04/30/2012 04:20 PM, Mathieu Desnoyers wrote:
* Woegerer, Paul (paul_woege...@mentor.com) wrote:
On 04/27/2012 02:43 PM, Mathieu Desnoyers wrote:
* Woegerer, Paul (paul_woege...@mentor.com) wrote:
On 04/27/2012 01:33 PM, Mathieu Desnoyers wrote:
A core difference between ulimit and user
On 04/26/2012 11:16 PM, Mathieu Desnoyers wrote:
I already thought about permitting this, but we currently don't. The
first thing I must say about this is that I prefer to wait a bit
before we add this feature, and think about its impact thoroughly,
because allowing the tracer to block
On 04/27/2012 01:33 PM, Mathieu Desnoyers wrote:
A core difference between ulimit and user-space tracing is that ulimit
can only be set within the environment (and access right) of the user
running the application. System-wide tracing sessions can be initiated
by users member of the tracing
On 04/27/2012 02:43 PM, Mathieu Desnoyers wrote:
* Woegerer, Paul (paul_woege...@mentor.com) wrote:
On 04/27/2012 01:33 PM, Mathieu Desnoyers wrote:
A core difference between ulimit and user-space tracing is that ulimit
can only be set within the environment (and access right) of the user
71 matches
Mail list logo
