From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Some questions about Lttng Date: Mon, 18 Jun 2012 23:50:04 -0400 Message-ID: <6539770C71C3814BB0BFC2DBEBD105087948C2__32350.9197020487$1340077860$gmane$org@CORPUSMX30B.corp.emc.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1409930861==" Return-path: Received: from hop-nat-141.emc.com ([168.159.213.141] helo=mexforward.lss.emc.com) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1SgpSW-0005Jp-Ad for lttng-dev@lists.lttng.org; Mon, 18 Jun 2012 23:50:28 -0400 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5J3oMYC022740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jun 2012 23:50:22 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Mon, 18 Jun 2012 23:50:09 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5J3o7h8032613 for ; Mon, 18 Jun 2012 23:50:08 -0400 Content-class: urn:content-classes:message List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org This is a multi-part message in MIME format. --===============1409930861== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4DCE.9DD35F95" This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4DCE.9DD35F95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, =20 I'm studying how to use Lttng now. I built a kernel which version is 2.6.38 and ran with lttng 2.0. I got some confused when I started to use it. Here are my questions: =20 1. I didn't see kernel patches for kernel 3.x. Does it mean kernel 3.x support it already?=20 2. I tried to do something like, dump the arguments of system call, or dump a backtrace in a specified function. But the output of lttng is very limited. Is there a way to do that with lttng? 3. I looked into some UST examples and found here are three header files: tracepoint.h, tracepoint-event.h and ust-tracepoint-event.h. They have some duplicated macro definitions like TRACEPOINT_EVENT. And the examples includes all of these three header files despite no conflict here. Could someone help to explain the intention? 4. Once I defined a tracepoint in my code, seems some initializations would register default probe into the hook point. How to disable the default probe and register my self-defined probes? 5. Does lttng-ust support dynamic traceing like kprobe? =20 I'm a newbie of lttng. Any help will be appreciated. =20 Thanks Zheng =20 =20 ------_=_NextPart_001_01CD4DCE.9DD35F95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = folks,

 

I’m studying how to use Lttng now. I built a = kernel which version is 2.6.38 and ran with lttng 2.0.

I got some confused when I started to use it. Here are = my questions:

 

1. I didn’t see kernel patches for kernel 3.x. = Does it mean kernel 3.x support it already?

2. I tried to do something like, dump the arguments of = system call, or dump a backtrace in a specified function. But the output = of lttng is very limited. Is there a way to do that with = lttng?

3. I looked into some UST = examples and found here are three header files:  tracepoint.h, = tracepoint-event.h and ust-tracepoint-event.h. They have some duplicated = macro definitions like TRACEPOINT_EVENT.

And the examples includes all of these three header = files despite no conflict here. Could someone help to explain the = intention?

4. Once I defined a = tracepoint in my code, seems some initializations would register default = probe into the hook point.  How to disable the default probe = and  register my self-defined probes?

5. Does lttng-ust support dynamic traceing like = kprobe?

 

I’m a newbie of lttng. Any help will be = appreciated.

 

Thanks

Zheng

 

 

------_=_NextPart_001_01CD4DCE.9DD35F95-- --===============1409930861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev --===============1409930861==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francis Giraldeau Subject: Re: Some questions about Lttng Date: Tue, 19 Jun 2012 11:28:01 +0200 Message-ID: <4FE04621.3070806__33867.8794717$1340098146$gmane$org@gmail.com> References: <6539770C71C3814BB0BFC2DBEBD105087948C2@CORPUSMX30B.corp.emc.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1143269404==" Return-path: Received: from mail-lb0-f176.google.com ([209.85.217.176]) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1SgujM-0007zO-Uf for lttng-dev@lists.lttng.org; Tue, 19 Jun 2012 05:28:14 -0400 Received: by lboj14 with SMTP id j14so6775669lbo.35 for ; Tue, 19 Jun 2012 02:28:06 -0700 (PDT) In-Reply-To: <6539770C71C3814BB0BFC2DBEBD105087948C2@CORPUSMX30B.corp.emc.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: "lttng-dev@lists.lttng.org" List-Id: lttng-dev@lists.lttng.org Ceci est un message signC) cryptographiquement au format MIME. --===============1143269404== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080506030307040101090503" Ceci est un message signé cryptographiquement au format MIME. --------------ms080506030307040101090503 Content-Type: multipart/alternative; boundary="------------060507010207030605060807" This is a multi-part message in MIME format. --------------060507010207030605060807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 2012-06-19 05:50, Zheng.Chang@emc.com a =E9crit : > > Hi folks, > > =20 > > I'm studying how to use Lttng now. I built a kernel which version is > 2.6.38 and ran with lttng 2.0. > > I got some confused when I started to use it. Here are my questions: > > =20 > > 1. I didn't see kernel patches for kernel 3.x. Does it mean kernel 3.x > support it already? > You don't need a kernel patch with lttng 2.0, only modules are required. It uses the tracepoints already present in the kernel, and trace system calls, and uses perf performance counters and kprobes. > 2. I tried to do something like, dump the arguments of system call, or > dump a backtrace in a specified function. But the output of lttng is > very limited. Is there a way to do that with lttng? > If system calls are enabled, arguments are supposed to be dumped (option --syscall to lttng enable-event). If it's not the case, then are you sure you are using lttng 2.0 and not 0.12? ;) Because the older version has a different behavior. One additional note: few system calls do not have all their arguments decoded in lttng 2, but there are only a few. > 3. I looked into some UST examples and found here are three header > files: tracepoint.h, tracepoint-event.h and ust-tracepoint-event.h. > They have some duplicated macro definitions like TRACEPOINT_EVENT. > The macros are quite complicated. Some includes files are included more than once to generate various portion of the tracepoint code. So, my advice here is to take a working example and adapt it to your needs. > And the examples includes all of these three header files despite no > conflict here. Could someone help to explain the intention? > > 4. Once I defined a tracepoint in my code, seems some initializations > would register default probe into the hook point. How to disable the > default probe and register my self-defined probes? > You mean, call a custom function when tracepoint is executed? Maybe somebody else has an answer, but AFAIK this is not possible. But you could make a wrapper to your tracepoint and then call your additional function there. > 5. Does lttng-ust support dynamic traceing like kprobe? > AFAIK, the kernel tracer supports kprobe, but not UST. Maybe somebody else can confirm/infirm the dynamic tracepoint feature in user-space? You can use a feature of GCC to regiter callback on function entry and exit, but since it executes for all functions, then the overhead is very high. You can have a look here: https://github.com/giraldeau/workload-kit/blob/master/ust/cyg.c Cheers, Francis --------------060507010207030605060807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 2012-06-19 05:50, Zheng.Chang@emc.com a écrit :

Hi folks,

 

I’m studying how to use Lttng now. I= built a kernel which version is 2.6.38 and ran with lttng 2.0.

I got some confused when I started to use it. Here are my questions:

 

1. I didn’t see kernel patches for k= ernel 3.x. Does it mean kernel 3.x support it already?


You don't need a kernel patch with lttng 2.0, only modules are required. It uses the tracepoints already present in the kernel, and trace system calls, and uses perf performance counters and kprobes.

2. I tried to do something like, dump the arguments of system call, or dump a backtrace in a specified function. But the output of lttng is very limited. Is there a way to do that with lttng?


If system calls are enabled, arguments are supposed to be dumped (option --syscall to lttng enable-event). If it's not the case, then are you sure you are using lttng 2.0 and not 0.12? ;) Because the older version has a different behavior. One additional note: few system calls do not have all their arguments decoded in lttng 2, but there are only a few.

3. I looked into some UST examples and found here are three header files:  tracepoint.h, tracepoint-event.h and ust-tracepoint-event.h. They have some duplicated macro definitions like TRACEPOINT_EVENT.


The macros are quite complicated. Some includes files are included more than once to generate various portion of the tracepoint code. So, my advice here is to take a working example and adapt it to your needs.

And the examples includes all of these three header files despite no conflict here. Could someone help to explain the intention?

4. Once I defined a tracepoint in my code,= seems some initializations would register default probe into the hook point.  How to disable the default probe and = ; register my self-defined probes?


You mean, call a custom function when tracepoint is executed? Maybe somebody else has an answer, but AFAIK this is not possible. But you could make a wrapper to your tracepoint and then call your additional function there.

5. Does lttng-ust support dynamic traceing= like kprobe?


AFAIK, the kernel tracer supports kprobe, but not UST. Maybe somebody else can confirm/infirm the dynamic tracepoint feature in user-space?

You can use a feature of GCC to regiter callback on function entry and exit, but since it executes for all functions, then the overhead is very high. You can have a look here:

https://github.com/giraldeau/workload-kit/blob/master/ust/cyg.c=

Cheers,

Francis
--------------060507010207030605060807-- --------------ms080506030307040101090503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUjCC BVwwggREoAMCAQICEGWn7N/yOaERpG8kZX1Cua0wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjA1MjgwMDAwMDBaFw0xMzA1MjgyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRowGAYDVQQDFBFGcmFuY2lzIEdp cmFsZGVhdTEqMCgGCSqGSIb3DQEJARYbZnJhbmNpcy5naXJhbGRlYXVAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqiOFH8B8262aBX5FMSzvA38NY4ekw6W+ zThHjeI46j7VFPXJbK0BM7yAMu4DmybyE8b5IB4oKcjRGdGC8GaMZdx0+Je0CxR/+M4hMB9s g3JhgXLQ9RYDJKn9k0JZ59pbYsh6OMtYPX3WDCyEXBg3xkd2JQ9YiY46IJSEhfbHHE9CwaYa f3Pbl3Bp5oi5PUADYu76ItNdHBHzBGBrkkYFaGoI5Mh27oBABvDW6QNuGvrTkkWOmFeJPNAu AS52izUNriCmkMGNbGON3dMM7cNk1uoNXyV7vnIP0pwTm+xA5CLkvjt+/sxynJYWXqexwcer X0VCw5Hbaqa3IxzJKB8BYwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg hkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkw RzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5k QzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAMYnv8qG3qSGJYAn+PhjGx lbmbaxqYyD0QVRq6g8tXrZtBUqNO29mce+olKu7lHsrEHpIKwMfArh3BpxPYVhKMAP6GaCAn jdr8LJ6TZHTLeVo4BLU7ZEPR6qCGxUhIodqzzWoet0cardf6Ub0OknxxAymgQ8+pIGJmxOOr ypWp+3ba6dPmY/MJeXIWq08V+P6912vL6I+cwrS6e7rud0XeR9KEEqn/EpuqDpp1mNj5QeRo 73zkl8G1nBnYbr42r2jSzqxRvefsfimWm6XX2L2K9WKp6TvJhFejZ7aP234pRDx9Ep0unSH4 LR2o5p6Ik5RQaG0xu1c74KgDTyzZVn2+MIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT 3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6 ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f 0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Iba k2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+ wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBn MGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNV HQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0 LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHm oYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSo WufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6 jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvi d+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5l UkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaM xmgD5yKocwuxvKDaUljdCg5/wYIxggTsMIIE6AIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBlp+zf8jmhEaRv JGV9QrmtMAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMDYxOTA5MjgwMVowIwYJKoZIhvcNAQkEMRYEFBJyUht0q3mAaru+Ns31 3KAg7C9qMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCCAQMG CSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBlp+zf8jmhEaRvJGV9QrmtMIIBBQYLKoZIhvcN AQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMwIQZafs3/I5oRGkbyRlfUK5rTANBgkqhkiG9w0BAQEFAASC AQAqhhqKso5lSaBzy3a017Y72T/ti/LXe6RwzZZLrGik1qurPhQLigleu/DLv38vS9YZpck6 /Pl7Zqe4W35vFzuxb6lmWUweVHN3ehd4V/Nk0HwGQrOFkaPa5PYPa2Va56kLbWd6bnC4C0T6 a+6SjzxN4/E3iRr929BmGbDlhw5da783xn16NoG3bNjcaoQG9uMqzv1UfSKm+gtmQkt/Drj0 PAypE0OJSfzwQdndWm5kr+gxHWSxsFSs8qFA1HCIVNG1H6beU51iLiQSLlC1Vu7Ftny0+t/N lGrIMslzyc2tvTPOM7eXqfRzx/rf8zT86IgqnTu3gy3gQGnDDGTUHkH4AAAAAAAA --------------ms080506030307040101090503-- --===============1143269404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev --===============1143269404==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: Some questions about Lttng Date: Tue, 19 Jun 2012 12:36:55 -0400 Message-ID: <20120619163655.GC6743__29772.060577716$1340123864$gmane$org@Krystal> References: <6539770C71C3814BB0BFC2DBEBD105087948C2@CORPUSMX30B.corp.emc.com> <4FE04621.3070806@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail.openrapids.net ([64.15.138.104] helo=blackscsi.openrapids.net) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1Sh1QG-00037G-Uo for lttng-dev@lists.lttng.org; Tue, 19 Jun 2012 12:36:56 -0400 Content-Disposition: inline In-Reply-To: <4FE04621.3070806@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: Francis Giraldeau Cc: "lttng-dev@lists.lttng.org" List-Id: lttng-dev@lists.lttng.org * Francis Giraldeau (francis.giraldeau@gmail.com) wrote: > Le 2012-06-19 05:50, Zheng.Chang@emc.com a =E9crit : > > > > Hi folks, > > > > = > > > > I'm studying how to use Lttng now. I built a kernel which version is > > 2.6.38 and ran with lttng 2.0. > > > > I got some confused when I started to use it. Here are my questions: > > > > = > > > > 1. I didn't see kernel patches for kernel 3.x. Does it mean kernel 3.x > > support it already? > > > = > You don't need a kernel patch with lttng 2.0, only modules are required. > It uses the tracepoints already present in the kernel, and trace system > calls, and uses perf performance counters and kprobes. > = > > 2. I tried to do something like, dump the arguments of system call, or > > dump a backtrace in a specified function. But the output of lttng is > > very limited. Is there a way to do that with lttng? > > > = > If system calls are enabled, arguments are supposed to be dumped (option > --syscall to lttng enable-event). If it's not the case, then are you > sure you are using lttng 2.0 and not 0.12? ;) Because the older version > has a different behavior. One additional note: few system calls do not > have all their arguments decoded in lttng 2, but there are only a few. There is no backtrace dump feature in lttng 2.0. Arguments of system calls are almost all there on x86 32/64 and ARM. What architecture are you using ? > = > > 3. I looked into some UST examples and found here are three header > > files: tracepoint.h, tracepoint-event.h and ust-tracepoint-event.h. > > They have some duplicated macro definitions like TRACEPOINT_EVENT. > > > = > The macros are quite complicated. Some includes files are included more > than once to generate various portion of the tracepoint code. So, my > advice here is to take a working example and adapt it to your needs. Good advice. > = > > And the examples includes all of these three header files despite no > > conflict here. Could someone help to explain the intention? > > > > 4. Once I defined a tracepoint in my code, seems some initializations > > would register default probe into the hook point. How to disable the > > default probe and register my self-defined probes? > > > = > You mean, call a custom function when tracepoint is executed? Maybe > somebody else has an answer, but AFAIK this is not possible. But you > could make a wrapper to your tracepoint and then call your additional > function there. Yep, not possible. You'd have to wrap the tracepoint. > = > > 5. Does lttng-ust support dynamic traceing like kprobe? > > > = > AFAIK, the kernel tracer supports kprobe, but not UST. Maybe somebody > else can confirm/infirm the dynamic tracepoint feature in user-space? This is correct. Thanks, Mathieu > = > You can use a feature of GCC to regiter callback on function entry and > exit, but since it executes for all functions, then the overhead is very > high. You can have a look here: > = > https://github.com/giraldeau/workload-kit/blob/master/ust/cyg.c > = > Cheers, > = > Francis > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- = Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Re: Some questions about Lttng Date: Wed, 20 Jun 2012 01:30:56 -0400 Message-ID: <6539770C71C3814BB0BFC2DBEBD105087FC418__17355.0872518264$1340170330$gmane$org@CORPUSMX30B.corp.emc.com> References: <6539770C71C3814BB0BFC2DBEBD105087948C2@CORPUSMX30B.corp.emc.com><4FE04621.3070806@gmail.com> <20120619163655.GC6743@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from hop-nat-141.emc.com ([168.159.213.141] helo=mexforward.lss.emc.com) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1ShDW1-0000a8-1R for lttng-dev@lists.lttng.org; Wed, 20 Jun 2012 01:31:41 -0400 Content-class: urn:content-classes:message In-Reply-To: <20120619163655.GC6743@Krystal> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: mathieu.desnoyers@efficios.com, francis.giraldeau@gmail.com Cc: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org > -----Original Message----- > From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com] = > Sent: Wednesday, June 20, 2012 0:37 AM > To: Francis Giraldeau > Cc: lttng-dev@lists.lttng.org > Subject: Re: [lttng-dev] Some questions about Lttng > * Francis Giraldeau (francis.giraldeau@gmail.com) wrote: > > Le 2012-06-19 05:50, Zheng.Chang@emc.com a =E9crit : > > > > > > Hi folks, > > > > > > = > > > > > > I'm studying how to use Lttng now. I built a kernel which version is > > > 2.6.38 and ran with lttng 2.0. > > > > > > I got some confused when I started to use it. Here are my questions: > > > > > > = > > > > > > 1. I didn't see kernel patches for kernel 3.x. Does it mean kernel 3.x > > > support it already? > > > > > = > > You don't need a kernel patch with lttng 2.0, only modules are required. > > It uses the tracepoints already present in the kernel, and trace system > > calls, and uses perf performance counters and kprobes. > > = > > > 2. I tried to do something like, dump the arguments of system call, or > > > dump a backtrace in a specified function. But the output of lttng is > > > very limited. Is there a way to do that with lttng? > > > > > = > > If system calls are enabled, arguments are supposed to be dumped (option > > --syscall to lttng enable-event). If it's not the case, then are you > > sure you are using lttng 2.0 and not 0.12? ;) Because the older version > > has a different behavior. One additional note: few system calls do not > > have all their arguments decoded in lttng 2, but there are only a few. > There is no backtrace dump feature in lttng 2.0. > Arguments of system calls are almost all there on x86 32/64 and ARM. > What architecture are you using ? My tsetbed is x86 32bit and lttng's version is 2.0.1. You're right. I can s= ee the arguments now. > > = > > > 3. I looked into some UST examples and found here are three header > > > files: tracepoint.h, tracepoint-event.h and ust-tracepoint-event.h. > > > They have some duplicated macro definitions like TRACEPOINT_EVENT. > > > > > = > > The macros are quite complicated. Some includes files are included more > > than once to generate various portion of the tracepoint code. So, my > > advice here is to take a working example and adapt it to your needs. > Good advice. > > = > > > And the examples includes all of these three header files despite no > > > conflict here. Could someone help to explain the intention? > > > > > > 4. Once I defined a tracepoint in my code, seems some initializations > > > would register default probe into the hook point. How to disable the > > > default probe and register my self-defined probes? > > > > > = > > You mean, call a custom function when tracepoint is executed? Maybe > > somebody else has an answer, but AFAIK this is not possible. But you > > could make a wrapper to your tracepoint and then call your additional > > function there. > Yep, not possible. You'd have to wrap the tracepoint. > > = > > > 5. Does lttng-ust support dynamic traceing like kprobe? > > > > > = > > AFAIK, the kernel tracer supports kprobe, but not UST. Maybe somebody > > else can confirm/infirm the dynamic tracepoint feature in user-space? > This is correct. > Thanks, > Mathieu > > = > > You can use a feature of GCC to regiter callback on function entry and > > exit, but since it executes for all functions, then the overhead is very > > high. You can have a look here: > > = > > https://github.com/giraldeau/workload-kit/blob/master/ust/cyg.c > > = > > Cheers, > > = > > Francis And here are some subsequent questions about lttng: 6. Does lttng-ust support marker? Marker is easier to be compatible with th= e APIs like printf if we don't care its performance issue. 7. What's supposed to show with 'lttng list -u'? It's empty now. Is that po= ssible to show the events defined in an application? 8. What does disable-event command of lttng do? With the example(hello) pro= vided by lttng-ust, I enabled all events with '-a -u' and then disabled the= m again. I launched the example with gdb and dumped the tracepoint's struc= ture and then found its state was active. It's supposed to be inactive here= , right? BTW: I didn't see any trace generated here with view command. Thanks all for your useful info! Best regards Zheng > > _______________________________________________ > > lttng-dev mailing list > > lttng-dev@lists.lttng.org > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > -- = > Mathieu Desnoyers > Operating System Efficiency R&D Consultant > EfficiOS Inc. > http://www.efficios.com > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: Some questions about Lttng Date: Wed, 20 Jun 2012 09:03:38 -0400 Message-ID: <20120620130338.GA25746__8285.39019353247$1340197772$gmane$org@Krystal> References: <20120619163655.GC6743@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC418@CORPUSMX30B.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail.openrapids.net ([64.15.138.104] helo=blackscsi.openrapids.net) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1ShKZQ-0004Gd-OU for lttng-dev@lists.lttng.org; Wed, 20 Jun 2012 09:03:40 -0400 Content-Disposition: inline In-Reply-To: <6539770C71C3814BB0BFC2DBEBD105087FC418@CORPUSMX30B.corp.emc.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: Zheng.Chang@emc.com Cc: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org * Zheng.Chang@emc.com (Zheng.Chang@emc.com) wrote: > = > > -----Original Message----- > > From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com] = > > Sent: Wednesday, June 20, 2012 0:37 AM > > To: Francis Giraldeau > > Cc: lttng-dev@lists.lttng.org > > Subject: Re: [lttng-dev] Some questions about Lttng > = > > * Francis Giraldeau (francis.giraldeau@gmail.com) wrote: > > > Le 2012-06-19 05:50, Zheng.Chang@emc.com a =E9crit : > > > > > > > > Hi folks, > > > > > > > > = > > > > > > > > I'm studying how to use Lttng now. I built a kernel which version is > > > > 2.6.38 and ran with lttng 2.0. > > > > > > > > I got some confused when I started to use it. Here are my questions: > > > > > > > > = > > > > > > > > 1. I didn't see kernel patches for kernel 3.x. Does it mean kernel = 3.x > > > > support it already? > > > > > > > = > > > You don't need a kernel patch with lttng 2.0, only modules are requir= ed. > > > It uses the tracepoints already present in the kernel, and trace syst= em > > > calls, and uses perf performance counters and kprobes. > > > = > > > > 2. I tried to do something like, dump the arguments of system call,= or > > > > dump a backtrace in a specified function. But the output of lttng is > > > > very limited. Is there a way to do that with lttng? > > > > > > > = > > > If system calls are enabled, arguments are supposed to be dumped (opt= ion > > > --syscall to lttng enable-event). If it's not the case, then are you > > > sure you are using lttng 2.0 and not 0.12? ;) Because the older versi= on > > > has a different behavior. One additional note: few system calls do not > > > have all their arguments decoded in lttng 2, but there are only a few. > = > > There is no backtrace dump feature in lttng 2.0. > = > > Arguments of system calls are almost all there on x86 32/64 and ARM. > > What architecture are you using ? > = > = > My tsetbed is x86 32bit and lttng's version is 2.0.1. You're right. I can= see the arguments now. > = > = > > > = > > > > 3. I looked into some UST examples and found here are three header > > > > files: tracepoint.h, tracepoint-event.h and ust-tracepoint-event.h. > > > > They have some duplicated macro definitions like TRACEPOINT_EVENT. > > > > > > > = > > > The macros are quite complicated. Some includes files are included mo= re > > > than once to generate various portion of the tracepoint code. So, my > > > advice here is to take a working example and adapt it to your needs. > = > > Good advice. > = > > > = > > > > And the examples includes all of these three header files despite no > > > > conflict here. Could someone help to explain the intention? > > > > > > > > 4. Once I defined a tracepoint in my code, seems some initializatio= ns > > > > would register default probe into the hook point. How to disable t= he > > > > default probe and register my self-defined probes? > > > > > > > = > > > You mean, call a custom function when tracepoint is executed? Maybe > > > somebody else has an answer, but AFAIK this is not possible. But you > > > could make a wrapper to your tracepoint and then call your additional > > > function there. > = > > Yep, not possible. You'd have to wrap the tracepoint. > = > > > = > > > > 5. Does lttng-ust support dynamic traceing like kprobe? > > > > > > > = > > > AFAIK, the kernel tracer supports kprobe, but not UST. Maybe somebody > > > else can confirm/infirm the dynamic tracepoint feature in user-space? > = > > This is correct. > = > > Thanks, > = > > Mathieu > = > > > = > > > You can use a feature of GCC to regiter callback on function entry and > > > exit, but since it executes for all functions, then the overhead is v= ery > > > high. You can have a look here: > > > = > > > https://github.com/giraldeau/workload-kit/blob/master/ust/cyg.c > > > = > > > Cheers, > > > = > > > Francis > = > = > And here are some subsequent questions about lttng: > = > 6. Does lttng-ust support marker? Marker is easier to be compatible > with the APIs like printf if we don't care its performance issue. Not currently. We plan to implement a "tracepoint_printf" (or trace_printf, not sure yet) that will behave similarly to the Linux Kernel Markers (back in the early lttng 0.x days). This will definitely fulfill your use-case, but it's just not there yet. > 7. What's supposed to show with 'lttng list -u'? It's empty now. Is > that possible to show the events defined in an application? List of tracepoints in _currently running_ _registered_ applications only. An application registers when linked with liblttng-ust. > 8. What does disable-event command of lttng do? With the > example(hello) provided by lttng-ust, I enabled all events with '-a > -u' and then disabled them again. I launched the example with gdb and > dumped the tracepoint's structure and then found its state was active. > It's supposed to be inactive here, right? Can you provide the detail of commands you launched, and the result of gdb printout ? Please run "hello" with LTTNG_UST_DEBUG=3D1 env. var set. > BTW: I didn't see any trace generated here with view command. That is after the disable, right ? Also, did you do a lttng start at some point in your test ? Thanks, Mathieu > = > Thanks all for your useful info! > = > Best regards > Zheng > = > > > _______________________________________________ > > > lttng-dev mailing list > > > lttng-dev@lists.lttng.org > > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > = > = > > -- = > > Mathieu Desnoyers > > Operating System Efficiency R&D Consultant > > EfficiOS Inc. > > http://www.efficios.com > = > > _______________________________________________ > > lttng-dev mailing list > > lttng-dev@lists.lttng.org > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > = -- = Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Re: Some questions about Lttng Date: Thu, 21 Jun 2012 00:59:20 -0400 Message-ID: <6539770C71C3814BB0BFC2DBEBD105087FC8FC__24927.1399960437$1340254814$gmane$org@CORPUSMX30B.corp.emc.com> References: <20120619163655.GC6743@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC418@CORPUSMX30B.corp.emc.com> <20120620130338.GA25746@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from hop-nat-141.emc.com ([168.159.213.141] helo=mexforward.lss.emc.com) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1ShZUg-0002lG-Ox for lttng-dev@lists.lttng.org; Thu, 21 Jun 2012 00:59:46 -0400 Content-class: urn:content-classes:message In-Reply-To: <20120620130338.GA25746@Krystal> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: mathieu.desnoyers@efficios.com Cc: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org > -----Original Message----- > From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com] = > Sent: Wednesday, June 20, 2012 21:04 PM > To: Chang, Zheng > Cc: francis.giraldeau@gmail.com; lttng-dev@lists.lttng.org > Subject: Re: [lttng-dev] Some questions about Lttng > > * Zheng.Chang@emc.com (Zheng.Chang@emc.com) wrote: > > = > > > -----Original Message----- > > > From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com] = > > > Sent: Wednesday, June 20, 2012 0:37 AM > > > To: Francis Giraldeau > > > Cc: lttng-dev@lists.lttng.org > > > Subject: Re: [lttng-dev] Some questions about Lttng > > = > > > * Francis Giraldeau (francis.giraldeau@gmail.com) wrote: > > > > Le 2012-06-19 05:50, Zheng.Chang@emc.com a =E9crit : > > > > > > > > > > Hi folks, > > > > > > > > > > = > > > > > > > > > > I'm studying how to use Lttng now. I built a kernel which version= is > > > > > 2.6.38 and ran with lttng 2.0. > > > > > > > > > > I got some confused when I started to use it. Here are my questio= ns: > > > > > > > > > > = > > > > > > > > > > 1. I didn't see kernel patches for kernel 3.x. Does it mean kerne= l 3.x > > > > > support it already? > > > > > > > > > = > > > > You don't need a kernel patch with lttng 2.0, only modules are requ= ired. > > > > It uses the tracepoints already present in the kernel, and trace sy= stem > > > > calls, and uses perf performance counters and kprobes. > > > > = > > > > > 2. I tried to do something like, dump the arguments of system cal= l, or > > > > > dump a backtrace in a specified function. But the output of lttng= is > > > > > very limited. Is there a way to do that with lttng? > > > > > > > > > = > > > > If system calls are enabled, arguments are supposed to be dumped (o= ption > > > > --syscall to lttng enable-event). If it's not the case, then are you > > > > sure you are using lttng 2.0 and not 0.12? ;) Because the older ver= sion > > > > has a different behavior. One additional note: few system calls do = not > > > > have all their arguments decoded in lttng 2, but there are only a f= ew. > > = > > > There is no backtrace dump feature in lttng 2.0. > > = > > > Arguments of system calls are almost all there on x86 32/64 and ARM. > > > What architecture are you using ? > > = > > = > > My tsetbed is x86 32bit and lttng's version is 2.0.1. You're right. I c= an see the arguments now. > > = > > = > > > > = > > > > > 3. I looked into some UST examples and found here are three header > > > > > files: tracepoint.h, tracepoint-event.h and ust-tracepoint-event= .h. > > > > > They have some duplicated macro definitions like TRACEPOINT_EVENT. > > > > > > > > > = > > > > The macros are quite complicated. Some includes files are included = more > > > > than once to generate various portion of the tracepoint code. So, my > > > > advice here is to take a working example and adapt it to your needs. > > = > > > Good advice. > > = > > > > = > > > > > And the examples includes all of these three header files despite= no > > > > > conflict here. Could someone help to explain the intention? > > > > > > > > > > 4. Once I defined a tracepoint in my code, seems some initializat= ions > > > > > would register default probe into the hook point. How to disable= the > > > > > default probe and register my self-defined probes? > > > > > > > > > = > > > > You mean, call a custom function when tracepoint is executed? Maybe > > > > somebody else has an answer, but AFAIK this is not possible. But you > > > > could make a wrapper to your tracepoint and then call your addition= al > > > > function there. > > = > > > Yep, not possible. You'd have to wrap the tracepoint. > > = > > > > = > > > > > 5. Does lttng-ust support dynamic traceing like kprobe? > > > > > > > > > = > > > > AFAIK, the kernel tracer supports kprobe, but not UST. Maybe somebo= dy > > > > else can confirm/infirm the dynamic tracepoint feature in user-spac= e? > > = > > > This is correct. > > = > > > Thanks, > > = > > > Mathieu > > = > > > > = > > > > You can use a feature of GCC to regiter callback on function entry = and > > > > exit, but since it executes for all functions, then the overhead is= very > > > > high. You can have a look here: > > > > = > > > > https://github.com/giraldeau/workload-kit/blob/master/ust/cyg.c > > > > = > > > > Cheers, > > > > = > > > > Francis > > = > > = > > And here are some subsequent questions about lttng: > > = > > 6. Does lttng-ust support marker? Marker is easier to be compatible > > with the APIs like printf if we don't care its performance issue. > > Not currently. We plan to implement a "tracepoint_printf" (or > trace_printf, not sure yet) that will behave similarly to the Linux > Kernel Markers (back in the early lttng 0.x days). This will definitely > fulfill your use-case, but it's just not there yet. > > > 7. What's supposed to show with 'lttng list -u'? It's empty now. Is > > that possible to show the events defined in an application? > > List of tracepoints in _currently running_ _registered_ applications > only. An application registers when linked with liblttng-ust. > > > 8. What does disable-event command of lttng do? With the > > example(hello) provided by lttng-ust, I enabled all events with '-a > > -u' and then disabled them again. I launched the example with gdb and > > dumped the tracepoint's structure and then found its state was active. > > It's supposed to be inactive here, right? > > Can you provide the detail of commands you launched, and the result of > gdb printout ? Please run "hello" with LTTNG_UST_DEBUG=3D1 env. var set. > > > BTW: I didn't see any trace generated here with view command. > > That is after the disable, right ? Yes > Also, did you do a lttng start at some point in your test ? Yes. Following three examples(A/B/C) provide the testing info for question = 8: Example A: None event = lttng create hello lttng list hello Tracing session hello: [active] Trace path: /root/lttng-traces/hello-20120621-071913 = lttng start gdb ./hello (gdb) file .libs/hello (gdb) set env LTTNG_UST_DEBUG=3D1 (gdb) show env ... LTTNG_UST_DEBUG=3D1 (gdb) br main Breakpoint 1 at 0x80489b9: file hello.c, line 84. (gdb) r Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hel= lo = [Thread debugging using libthread_db enabled] liblttng_ust_tracepoint[3341/3341]: just registered a tracepoints section f= rom 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tr= acepoint.c:638) liblttng_ust_tracepoint[3341/3341]: registered tracepoint: lttng_ust:metada= ta (in tracepoint_register_lib() at tracepoint.c:643) libust[3341/3341]: just registered probe lttng_ust containing 1 events (in = ltt_probe_register() at ltt-probes.c:109) libust[3341/3341]: Registered event probe "lttng_ust:metadata" with signatu= re "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) libust[3341/3341]: LTT : ltt ring buffer client init (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-cli= ent.h:334) libust[3341/3341]: LTT : ltt ring buffer client init (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:58= 4) libust[3341/3341]: LTT : ltt ring buffer client init (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) [New Thread 0xb7dddb70 (LWP 3344)] [New Thread 0xb75dcb70 (LWP 3345)] libust[3341/3344]: Info: sessiond not accepting connections to local apps s= ocket (in ust_listener_thread() at lttng-ust-comm.c:699) libust[3341/3344]: Waiting for local apps sessiond (in wait_for_sessiond() = at lttng-ust-comm.c:621) libust[3341/3344]: Linux kernels 2.6.33 to 3.0 (with the exception of stabl= e versions) do not support FUTEX_WAKE on read-only memory mappings correctl= y. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269= d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallb= ack. (in wait_for_sessiond() at lttng-ust-comm.c:634) libust[3341/3344]: Error: futex: Bad address (in wait_for_sessiond() at ltt= ng-ust-comm.c:636) libust[3341/3344]: Info: sessiond not accepting connections to local apps s= ocket (in ust_listener_thread() at lttng-ust-comm.c:699) libust[3341/3345]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3341/3345]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3341/3345]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3341/3345]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3341/3341]: just registered probe ust_tests_hello containing 2 event= s (in ltt_probe_register() at ltt-probes.c:109) libust[3341/3341]: Registered event probe "ust_tests_hello:tptest" with sig= nature "int, anint, int, netint, long *, values, char *, text, size_t, text= len, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-pr= obes.c:118) libust[3341/3341]: Registered event probe "ust_tests_hello:tptest_sighandle= r" with signature "" (in ltt_probe_register() at ltt-probes.c:118) liblttng_ust_tracepoint[3341/3341]: just registered a tracepoints section f= rom 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tra= cepoint.c:638) liblttng_ust_tracepoint[3341/3341]: registered tracepoint: ust_tests_hello:= tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) liblttng_ust_tracepoint[3341/3341]: registered tracepoint: ust_tests_hello:= tptest (in tracepoint_register_lib() at tracepoint.c:643) Breakpoint 1, main (argc=3D1, argv=3D0xbffff754) at hello.c:84 84 if (argc =3D=3D 2) Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.1= 2.i686 libuuid-2.17.2-12.4.el6.i686 (gdb) p __tracepoint_ust_tests_hello___tptest $1 =3D {name =3D 0x804a380 "ust_tests_hello:tptest", state =3D 0, probes = =3D 0x0, tracepoint_provider_ref =3D 0x804b724, = signature =3D 0x8049240 "int, anint, int, netint, long *, values, char *,= text, size_t, textlen, double, doublearg, float, floatarg", padding =3D '\= 000' } Notice here the __tracepoint_ust_tests_hello___tptest.state and __tracepoin= t_ust_tests_hello___tptest.probes both are 0, which means no register and A= PI tracepoint doesn't invoke probe. = Example B: enable event ust_tests_hello:tptest lttng create hello lttng enable-event ust_tests_hello:tptest -u lttng list hello Tracing session hello: [inactive] Trace path: /root/lttng-traces/hello-20120621-073315 =3D=3D=3D Domain: UST global =3D=3D=3D Channels: ------------- - channel0: [enabled] Attributes: overwrite mode: 0 subbufers size: 4096 number of subbufers: 4 switch timer interval: 0 read timer interval: 200 output: mmap() Events: ust_tests_hello:tptest (type: tracepoint) [enabled] lttng start gdb ./hello (gdb) file .libs/hello (gdb) set env LTTNG_UST_DEBUG=3D1 (gdb) show env ... LTTNG_UST_DEBUG=3D1 (gdb) br main Breakpoint 1 at 0x80489b9: file hello.c, line 84. (gdb) r Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hel= lo = [Thread debugging using libthread_db enabled] liblttng_ust_tracepoint[3365/3365]: just registered a tracepoints section f= rom 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tr= acepoint.c:638) liblttng_ust_tracepoint[3365/3365]: registered tracepoint: lttng_ust:metada= ta (in tracepoint_register_lib() at tracepoint.c:643) libust[3365/3365]: just registered probe lttng_ust containing 1 events (in = ltt_probe_register() at ltt-probes.c:109) libust[3365/3365]: Registered event probe "lttng_ust:metadata" with signatu= re "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) libust[3365/3365]: LTT : ltt ring buffer client init (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-cli= ent.h:334) libust[3365/3365]: LTT : ltt ring buffer client init (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:58= 4) libust[3365/3365]: LTT : ltt ring buffer client init (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) [New Thread 0xb7dddb70 (LWP 3368)] libust[3365/3368]: Info: sessiond not accepting connections to local apps s= ocket (in ust_listener_thread() at lttng-ust-comm.c:699) [New Thread 0xb75dcb70 (LWP 3369)] libust[3365/3368]: Waiting for local apps sessiond (in wait_for_sessiond() = at lttng-ust-comm.c:621) libust[3365/3368]: Linux kernels 2.6.33 to 3.0 (with the exception of stabl= e versions) do not support FUTEX_WAKE on read-only memory mappings correctl= y. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269= d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallb= ack. (in wait_for_sessiond() at lttng-ust-comm.c:634) libust[3365/3368]: Error: futex: Bad address (in wait_for_sessiond() at ltt= ng-ust-comm.c:636) libust[3365/3368]: Info: sessiond not accepting connections to local apps s= ocket (in ust_listener_thread() at lttng-ust-comm.c:699) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) liblttng_ust_tracepoint[3365/3369]: Registering probe to tracepoint lttng_u= st:metadata (in __tracepoint_probe_register() at tracepoint.c:426) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3369]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3365/3365]: just registered probe ust_tests_hello containing 2 event= s (in ltt_probe_register() at ltt-probes.c:109) libust[3365/3365]: Registered event probe "ust_tests_hello:tptest" with sig= nature "int, anint, int, netint, long *, values, char *, text, size_t, text= len, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-pr= obes.c:118) liblttng_ust_tracepoint[3365/3365]: Registering probe to tracepoint ust_tes= ts_hello:tptest (in __tracepoint_probe_register() at tracepoint.c:426) libust[3365/3365]: Registered event probe "ust_tests_hello:tptest_sighandle= r" with signature "" (in ltt_probe_register() at ltt-probes.c:118) liblttng_ust_tracepoint[3365/3365]: just registered a tracepoints section f= rom 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tra= cepoint.c:638) liblttng_ust_tracepoint[3365/3365]: registered tracepoint: ust_tests_hello:= tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) liblttng_ust_tracepoint[3365/3365]: registered tracepoint: ust_tests_hello:= tptest (in tracepoint_register_lib() at tracepoint.c:643) Breakpoint 1, main (argc=3D1, argv=3D0xbffff754) at hello.c:84 84 if (argc =3D=3D 2) Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.1= 2.i686 libuuid-2.17.2-12.4.el6.i686 (gdb) p __tracepoint_ust_tests_hello___tptest $1 =3D {name =3D 0x804a380 "ust_tests_hello:tptest", state =3D 1, probes = =3D 0x804c258, tracepoint_provider_ref =3D 0x804b724, = signature =3D 0x8049240 "int, anint, int, netint, long *, values, char *,= text, size_t, textlen, double, doublearg, float, floatarg", padding =3D '\= 000' } We can see __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust= _tests_hello___tptest.probes have been set, which means API tracepoint can = invoke probe callback function and generate trace info. Example C: enable event and then disable it lttng create hello Session hello created. Traces will be written in /root/lttng-traces/hello-20120621-074221 lttng enable-event ust_tests_hello:tptest -u UST event ust_tests_hello:tptest created in channel channel0 lttng disable-event ust_tests_hello:tptest -u UST event ust_tests_hello:tptest disabled in channel channel0 for session h= ello lttng list hello Tracing session hello: [inactive] Trace path: /root/lttng-traces/hello-20120621-074221 =3D=3D=3D Domain: UST global =3D=3D=3D Channels: ------------- - channel0: [enabled] Attributes: overwrite mode: 0 subbufers size: 4096 number of subbufers: 4 switch timer interval: 0 read timer interval: 200 output: mmap() Events: ust_tests_hello:tptest (type: tracepoint) [disabled] lttng start gdb ./hello (gdb) file .libs/hello (gdb) set env LTTNG_UST_DEBUG=3D1 (gdb) show env ... LTTNG_UST_DEBUG=3D1 (gdb) br main Breakpoint 1 at 0x80489b9: file hello.c, line 84. (gdb) r Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hel= lo = [Thread debugging using libthread_db enabled] liblttng_ust_tracepoint[3384/3384]: just registered a tracepoints section f= rom 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tr= acepoint.c:638) liblttng_ust_tracepoint[3384/3384]: registered tracepoint: lttng_ust:metada= ta (in tracepoint_register_lib() at tracepoint.c:643) libust[3384/3384]: just registered probe lttng_ust containing 1 events (in = ltt_probe_register() at ltt-probes.c:109) libust[3384/3384]: Registered event probe "lttng_ust:metadata" with signatu= re "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) libust[3384/3384]: LTT : ltt ring buffer client init (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-cli= ent.h:334) libust[3384/3384]: LTT : ltt ring buffer client init (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:58= 4) libust[3384/3384]: LTT : ltt ring buffer client init (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) [New Thread 0xb7dddb70 (LWP 3387)] [New Thread 0xb75dcb70 (LWP 3388)] libust[3384/3387]: Info: sessiond not accepting connections to local apps s= ocket (in ust_listener_thread() at lttng-ust-comm.c:699) libust[3384/3387]: Waiting for local apps sessiond (in wait_for_sessiond() = at lttng-ust-comm.c:621) libust[3384/3387]: Linux kernels 2.6.33 to 3.0 (with the exception of stabl= e versions) do not support FUTEX_WAKE on read-only memory mappings correctl= y. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269= d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallb= ack. (in wait_for_sessiond() at lttng-ust-comm.c:634) libust[3384/3387]: Error: futex: Bad address (in wait_for_sessiond() at ltt= ng-ust-comm.c:636) libust[3384/3387]: Info: sessiond not accepting connections to local apps s= ocket (in ust_listener_thread() at lttng-ust-comm.c:699) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) liblttng_ust_tracepoint[3384/3388]: Registering probe to tracepoint lttng_u= st:metadata (in __tracepoint_probe_register() at tracepoint.c:426) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3388]: message received (in ust_listener_thread() at lttng-ust-comm.c:766) libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-= comm.c:202) libust[3384/3384]: just registered probe ust_tests_hello containing 2 event= s (in ltt_probe_register() at ltt-probes.c:109) libust[3384/3384]: Registered event probe "ust_tests_hello:tptest" with sig= nature "int, anint, int, netint, long *, values, char *, text, size_t, text= len, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-pr= obes.c:118) liblttng_ust_tracepoint[3384/3384]: Registering probe to tracepoint ust_tes= ts_hello:tptest (in __tracepoint_probe_register() at tracepoint.c:426) libust[3384/3384]: Registered event probe "ust_tests_hello:tptest_sighandle= r" with signature "" (in ltt_probe_register() at ltt-probes.c:118) liblttng_ust_tracepoint[3384/3384]: just registered a tracepoints section f= rom 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tra= cepoint.c:638) liblttng_ust_tracepoint[3384/3384]: registered tracepoint: ust_tests_hello:= tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) liblttng_ust_tracepoint[3384/3384]: registered tracepoint: ust_tests_hello:= tptest (in tracepoint_register_lib() at tracepoint.c:643) Breakpoint 1, main (argc=3D1, argv=3D0xbffff754) at hello.c:84 84 if (argc =3D=3D 2) Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.1= 2.i686 libuuid-2.17.2-12.4.el6.i686 (gdb) p __tracepoint_ust_tests_hello___tptest $1 =3D {name =3D 0x804a380 "ust_tests_hello:tptest", state =3D 1, probes = =3D 0x804c258, tracepoint_provider_ref =3D 0x804b724, = signature =3D 0x8049240 "int, anint, int, netint, long *, values, char *,= text, size_t, textlen, double, doublearg, float, floatarg", padding =3D '\= 000' } Here __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust_tests= _hello___tptest.probes have been set, which means probe callback function w= iil be called by API tracepoint. But the event has been disabled, is this n= ecessary to call into the probe again? If this behavior is normal, what's s= uppoed to do with disable-event command? = Any misunderstanding please fix me. Thanks Best Regards Zheng > Thanks, > Mathieu > = > Thanks all for your useful info! > = > Best regards > Zheng > = > > > _______________________________________________ > > > lttng-dev mailing list > > > lttng-dev@lists.lttng.org > > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > = > = > > -- = > > Mathieu Desnoyers > > Operating System Efficiency R&D Consultant > > EfficiOS Inc. > > http://www.efficios.com > = > > _______________________________________________ > > lttng-dev mailing list > > lttng-dev@lists.lttng.org > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > = > -- = > Mathieu Desnoyers > Operating System Efficiency R&D Consultant > EfficiOS Inc. > http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: Some questions about Lttng Date: Thu, 21 Jun 2012 08:45:32 -0400 Message-ID: <20120621124532.GA7255__45437.8129485578$1340282770$gmane$org@Krystal> References: <20120619163655.GC6743@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC418@CORPUSMX30B.corp.emc.com> <20120620130338.GA25746@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC8FC@CORPUSMX30B.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.openrapids.net ([64.15.138.104] helo=blackscsi.openrapids.net) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1ShglT-0006YI-PP for lttng-dev@lists.lttng.org; Thu, 21 Jun 2012 08:45:36 -0400 Content-Disposition: inline In-Reply-To: <6539770C71C3814BB0BFC2DBEBD105087FC8FC@CORPUSMX30B.corp.emc.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: Zheng.Chang@emc.com Cc: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org * Zheng.Chang@emc.com (Zheng.Chang@emc.com) wrote: > > -----Original Message----- > > From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com] [...] > > > 8. What does disable-event command of lttng do? With the > > > example(hello) provided by lttng-ust, I enabled all events with '-a > > > -u' and then disabled them again. I launched the example with gdb and > > > dumped the tracepoint's structure and then found its state was active. > > > It's supposed to be inactive here, right? > > > > Can you provide the detail of commands you launched, and the result of > > gdb printout ? Please run "hello" with LTTNG_UST_DEBUG=1 env. var set. > > > > > BTW: I didn't see any trace generated here with view command. > > > > That is after the disable, right ? > > Yes > > > Also, did you do a lttng start at some point in your test ? > > > Yes. Following three examples(A/B/C) provide the testing info for question 8: > > Example A: None event > lttng create hello > lttng list hello > Tracing session hello: [active] > Trace path: /root/lttng-traces/hello-20120621-071913 > > lttng start > > gdb ./hello > (gdb) file .libs/hello > (gdb) set env LTTNG_UST_DEBUG=1 > (gdb) show env > ... > LTTNG_UST_DEBUG=1 > (gdb) br main > Breakpoint 1 at 0x80489b9: file hello.c, line 84. > (gdb) r > Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hello > [Thread debugging using libthread_db enabled] > liblttng_ust_tracepoint[3341/3341]: just registered a tracepoints section from 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) > liblttng_ust_tracepoint[3341/3341]: registered tracepoint: lttng_ust:metadata (in tracepoint_register_lib() at tracepoint.c:643) > libust[3341/3341]: just registered probe lttng_ust containing 1 events (in ltt_probe_register() at ltt-probes.c:109) > libust[3341/3341]: Registered event probe "lttng_ust:metadata" with signature "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) > libust[3341/3341]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-client.h:334) > libust[3341/3341]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:584) > libust[3341/3341]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) > [New Thread 0xb7dddb70 (LWP 3344)] > [New Thread 0xb75dcb70 (LWP 3345)] > libust[3341/3344]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) > libust[3341/3344]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:621) > libust[3341/3344]: Linux kernels 2.6.33 to 3.0 (with the exception of stable versions) do not support FUTEX_WAKE on read-only memory mappings correctly. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallback. (in wait_for_sessiond() at lttng-ust-comm.c:634) > libust[3341/3344]: Error: futex: Bad address (in wait_for_sessiond() at lttng-ust-comm.c:636) > libust[3341/3344]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) > libust[3341/3345]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3341/3345]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3341/3345]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3341/3345]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3341/3341]: just registered probe ust_tests_hello containing 2 events (in ltt_probe_register() at ltt-probes.c:109) > libust[3341/3341]: Registered event probe "ust_tests_hello:tptest" with signature "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-probes.c:118) > libust[3341/3341]: Registered event probe "ust_tests_hello:tptest_sighandler" with signature "" (in ltt_probe_register() at ltt-probes.c:118) > liblttng_ust_tracepoint[3341/3341]: just registered a tracepoints section from 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) > liblttng_ust_tracepoint[3341/3341]: registered tracepoint: ust_tests_hello:tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) > liblttng_ust_tracepoint[3341/3341]: registered tracepoint: ust_tests_hello:tptest (in tracepoint_register_lib() at tracepoint.c:643) > > Breakpoint 1, main (argc=1, argv=0xbffff754) at hello.c:84 > 84 if (argc == 2) > Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.12.i686 libuuid-2.17.2-12.4.el6.i686 > (gdb) p __tracepoint_ust_tests_hello___tptest > $1 = {name = 0x804a380 "ust_tests_hello:tptest", state = 0, probes = 0x0, tracepoint_provider_ref = 0x804b724, > signature = 0x8049240 "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg", padding = '\000' } > > Notice here the __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust_tests_hello___tptest.probes both are 0, which means no register and API tracepoint doesn't invoke probe. > > Example B: enable event ust_tests_hello:tptest > lttng create hello > lttng enable-event ust_tests_hello:tptest -u > lttng list hello > Tracing session hello: [inactive] > Trace path: /root/lttng-traces/hello-20120621-073315 > > === Domain: UST global === > > Channels: > ------------- > - channel0: [enabled] > > Attributes: > overwrite mode: 0 > subbufers size: 4096 > number of subbufers: 4 > switch timer interval: 0 > read timer interval: 200 > output: mmap() > > Events: > ust_tests_hello:tptest (type: tracepoint) [enabled] > lttng start > gdb ./hello > (gdb) file .libs/hello > (gdb) set env LTTNG_UST_DEBUG=1 > (gdb) show env > ... > LTTNG_UST_DEBUG=1 > (gdb) br main > Breakpoint 1 at 0x80489b9: file hello.c, line 84. > (gdb) r > Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hello > [Thread debugging using libthread_db enabled] > liblttng_ust_tracepoint[3365/3365]: just registered a tracepoints section from 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) > liblttng_ust_tracepoint[3365/3365]: registered tracepoint: lttng_ust:metadata (in tracepoint_register_lib() at tracepoint.c:643) > libust[3365/3365]: just registered probe lttng_ust containing 1 events (in ltt_probe_register() at ltt-probes.c:109) > libust[3365/3365]: Registered event probe "lttng_ust:metadata" with signature "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) > libust[3365/3365]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-client.h:334) > libust[3365/3365]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:584) > libust[3365/3365]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) > [New Thread 0xb7dddb70 (LWP 3368)] > libust[3365/3368]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) > [New Thread 0xb75dcb70 (LWP 3369)] > libust[3365/3368]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:621) > libust[3365/3368]: Linux kernels 2.6.33 to 3.0 (with the exception of stable versions) do not support FUTEX_WAKE on read-only memory mappings correctly. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallback. (in wait_for_sessiond() at lttng-ust-comm.c:634) > libust[3365/3368]: Error: futex: Bad address (in wait_for_sessiond() at lttng-ust-comm.c:636) > libust[3365/3368]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > liblttng_ust_tracepoint[3365/3369]: Registering probe to tracepoint lttng_ust:metadata (in __tracepoint_probe_register() at tracepoint.c:426) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3369]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3365/3365]: just registered probe ust_tests_hello containing 2 events (in ltt_probe_register() at ltt-probes.c:109) > libust[3365/3365]: Registered event probe "ust_tests_hello:tptest" with signature "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-probes.c:118) > liblttng_ust_tracepoint[3365/3365]: Registering probe to tracepoint ust_tests_hello:tptest (in __tracepoint_probe_register() at tracepoint.c:426) > libust[3365/3365]: Registered event probe "ust_tests_hello:tptest_sighandler" with signature "" (in ltt_probe_register() at ltt-probes.c:118) > liblttng_ust_tracepoint[3365/3365]: just registered a tracepoints section from 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) > liblttng_ust_tracepoint[3365/3365]: registered tracepoint: ust_tests_hello:tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) > liblttng_ust_tracepoint[3365/3365]: registered tracepoint: ust_tests_hello:tptest (in tracepoint_register_lib() at tracepoint.c:643) > > Breakpoint 1, main (argc=1, argv=0xbffff754) at hello.c:84 > 84 if (argc == 2) > Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.12.i686 libuuid-2.17.2-12.4.el6.i686 > (gdb) p __tracepoint_ust_tests_hello___tptest > $1 = {name = 0x804a380 "ust_tests_hello:tptest", state = 1, probes = 0x804c258, tracepoint_provider_ref = 0x804b724, > signature = 0x8049240 "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg", padding = '\000' } > > We can see __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust_tests_hello___tptest.probes have been set, which means API tracepoint can invoke probe callback function and generate trace info. > > Example C: enable event and then disable it > lttng create hello > Session hello created. > Traces will be written in /root/lttng-traces/hello-20120621-074221 > lttng enable-event ust_tests_hello:tptest -u > UST event ust_tests_hello:tptest created in channel channel0 > lttng disable-event ust_tests_hello:tptest -u > UST event ust_tests_hello:tptest disabled in channel channel0 for session hello > lttng list hello > Tracing session hello: [inactive] > Trace path: /root/lttng-traces/hello-20120621-074221 > > === Domain: UST global === > > Channels: > ------------- > - channel0: [enabled] > > Attributes: > overwrite mode: 0 > subbufers size: 4096 > number of subbufers: 4 > switch timer interval: 0 > read timer interval: 200 > output: mmap() > > Events: > ust_tests_hello:tptest (type: tracepoint) [disabled] > > lttng start > gdb ./hello > (gdb) file .libs/hello > (gdb) set env LTTNG_UST_DEBUG=1 > (gdb) show env > ... > LTTNG_UST_DEBUG=1 > (gdb) br main > Breakpoint 1 at 0x80489b9: file hello.c, line 84. > (gdb) r > Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hello > [Thread debugging using libthread_db enabled] > liblttng_ust_tracepoint[3384/3384]: just registered a tracepoints section from 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) > liblttng_ust_tracepoint[3384/3384]: registered tracepoint: lttng_ust:metadata (in tracepoint_register_lib() at tracepoint.c:643) > libust[3384/3384]: just registered probe lttng_ust containing 1 events (in ltt_probe_register() at ltt-probes.c:109) > libust[3384/3384]: Registered event probe "lttng_ust:metadata" with signature "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) > libust[3384/3384]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-client.h:334) > libust[3384/3384]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:584) > libust[3384/3384]: LTT : ltt ring buffer client init > (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) > [New Thread 0xb7dddb70 (LWP 3387)] > [New Thread 0xb75dcb70 (LWP 3388)] > libust[3384/3387]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) > libust[3384/3387]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:621) > libust[3384/3387]: Linux kernels 2.6.33 to 3.0 (with the exception of stable versions) do not support FUTEX_WAKE on read-only memory mappings correctly. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallback. (in wait_for_sessiond() at lttng-ust-comm.c:634) > libust[3384/3387]: Error: futex: Bad address (in wait_for_sessiond() at lttng-ust-comm.c:636) > libust[3384/3387]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > liblttng_ust_tracepoint[3384/3388]: Registering probe to tracepoint lttng_ust:metadata (in __tracepoint_probe_register() at tracepoint.c:426) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3388]: message received > (in ust_listener_thread() at lttng-ust-comm.c:766) > libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) > libust[3384/3384]: just registered probe ust_tests_hello containing 2 events (in ltt_probe_register() at ltt-probes.c:109) > libust[3384/3384]: Registered event probe "ust_tests_hello:tptest" with signature "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-probes.c:118) > liblttng_ust_tracepoint[3384/3384]: Registering probe to tracepoint ust_tests_hello:tptest (in __tracepoint_probe_register() at tracepoint.c:426) > libust[3384/3384]: Registered event probe "ust_tests_hello:tptest_sighandler" with signature "" (in ltt_probe_register() at ltt-probes.c:118) > liblttng_ust_tracepoint[3384/3384]: just registered a tracepoints section from 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) > liblttng_ust_tracepoint[3384/3384]: registered tracepoint: ust_tests_hello:tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) > liblttng_ust_tracepoint[3384/3384]: registered tracepoint: ust_tests_hello:tptest (in tracepoint_register_lib() at tracepoint.c:643) > > Breakpoint 1, main (argc=1, argv=0xbffff754) at hello.c:84 > 84 if (argc == 2) > Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.12.i686 libuuid-2.17.2-12.4.el6.i686 > (gdb) p __tracepoint_ust_tests_hello___tptest > $1 = {name = 0x804a380 "ust_tests_hello:tptest", state = 1, probes = 0x804c258, tracepoint_provider_ref = 0x804b724, > signature = 0x8049240 "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg", padding = '\000' } > > Here __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust_tests_hello___tptest.probes have been set, which means probe callback function wiil be called by API tracepoint. But the event has been disabled, is this necessary to call into the probe again? If this behavior is normal, what's suppoed to do with disable-event command? > > Any misunderstanding please fix me. Thanks disabling an event ends up calling, in the program: lttng-ust-abi.c:lttng_event_cmd() with "LTTNG_UST_DISABLE", which calls ltt_event_disable(). Looking at this function: int ltt_event_disable(struct ltt_event *event) { int old; if (event->chan == event->chan->session->metadata) return -EPERM; old = uatomic_xchg(&event->enabled, 0); if (!old) return -EEXIST; return 0; } shows us that disabling an event sets the "enabled" flag within the event (struct ltt_event) to 0. This flag is tested in include/lttng/ust-tracepoint-event.h: #undef TRACEPOINT_EVENT_CLASS #define TRACEPOINT_EVENT_CLASS(_provider, _name, _args, _fields) \ static void __event_probe__##_provider##___##_name(_TP_ARGS_DATA_PROTO(_args))\ [...] if (caa_unlikely(!CMM_ACCESS_ONCE(__chan->session->active))) \ return; \ if (caa_unlikely(!CMM_ACCESS_ONCE(__chan->enabled))) \ return; \ if (caa_unlikely(!CMM_ACCESS_ONCE(__event->enabled))) \ return; What you are looking at with the debugger are the tracepoint call sites, which still have a handler connected to them when you disable the event. So yes, in theory, we could lessen the overhead of the enable followed by disable case and ensure that we disconnect the probe from the call site, but diminishing the performance impact of this rare use-case has not been high on my priority list so far. Hoping that my explanation helps clarifying things, Thanks, Mathieu > > Best Regards > Zheng > > > > Thanks, > > Mathieu > > > > Thanks all for your useful info! > > > > Best regards > > Zheng > > > > > > _______________________________________________ > > > > lttng-dev mailing list > > > > lttng-dev@lists.lttng.org > > > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > > > > -- > > > Mathieu Desnoyers > > > Operating System Efficiency R&D Consultant > > > EfficiOS Inc. > > > http://www.efficios.com > > > > > _______________________________________________ > > > lttng-dev mailing list > > > lttng-dev@lists.lttng.org > > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > > -- > > Mathieu Desnoyers > > Operating System Efficiency R&D Consultant > > EfficiOS Inc. > > http://www.efficios.com > -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: changz Subject: Re: Some questions about Lttng Date: Mon, 25 Jun 2012 15:32:45 +0800 Message-ID: <4FE8141D.3030107__12914.3488048159$1340609626$gmane$org@emc.com> References: <20120619163655.GC6743@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC418@CORPUSMX30B.corp.emc.com> <20120620130338.GA25746@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC8FC@CORPUSMX30B.corp.emc.com> <20120621124532.GA7255@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from hop-nat-141.emc.com ([168.159.213.141] helo=mexforward.lss.emc.com) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1Sj3nI-0004DY-8u for lttng-dev@lists.lttng.org; Mon, 25 Jun 2012 03:33:08 -0400 In-Reply-To: <20120621124532.GA7255@Krystal> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: Mathieu Desnoyers Cc: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org On 6/21/2012 20:45 PM, Mathieu Desnoyers wrote: > * Zheng.Chang@emc.com (Zheng.Chang@emc.com) wrote: >>> -----Original Message----- >>> From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com] > [...] >>>> 8. What does disable-event command of lttng do? With the >>>> example(hello) provided by lttng-ust, I enabled all events with '-a >>>> -u' and then disabled them again. I launched the example with gdb and >>>> dumped the tracepoint's structure and then found its state was active. >>>> It's supposed to be inactive here, right? >>> Can you provide the detail of commands you launched, and the result of >>> gdb printout ? Please run "hello" with LTTNG_UST_DEBUG=1 env. var set. >>> >>>> BTW: I didn't see any trace generated here with view command. >>> That is after the disable, right ? >> Yes >> >>> Also, did you do a lttng start at some point in your test ? >> >> Yes. Following three examples(A/B/C) provide the testing info for question 8: >> >> Example A: None event >> lttng create hello >> lttng list hello >> Tracing session hello: [active] >> Trace path: /root/lttng-traces/hello-20120621-071913 >> >> lttng start >> >> gdb ./hello >> (gdb) file .libs/hello >> (gdb) set env LTTNG_UST_DEBUG=1 >> (gdb) show env >> ... >> LTTNG_UST_DEBUG=1 >> (gdb) br main >> Breakpoint 1 at 0x80489b9: file hello.c, line 84. >> (gdb) r >> Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hello >> [Thread debugging using libthread_db enabled] >> liblttng_ust_tracepoint[3341/3341]: just registered a tracepoints section from 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) >> liblttng_ust_tracepoint[3341/3341]: registered tracepoint: lttng_ust:metadata (in tracepoint_register_lib() at tracepoint.c:643) >> libust[3341/3341]: just registered probe lttng_ust containing 1 events (in ltt_probe_register() at ltt-probes.c:109) >> libust[3341/3341]: Registered event probe "lttng_ust:metadata" with signature "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) >> libust[3341/3341]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-client.h:334) >> libust[3341/3341]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:584) >> libust[3341/3341]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) >> [New Thread 0xb7dddb70 (LWP 3344)] >> [New Thread 0xb75dcb70 (LWP 3345)] >> libust[3341/3344]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) >> libust[3341/3344]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:621) >> libust[3341/3344]: Linux kernels 2.6.33 to 3.0 (with the exception of stable versions) do not support FUTEX_WAKE on read-only memory mappings correctly. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallback. (in wait_for_sessiond() at lttng-ust-comm.c:634) >> libust[3341/3344]: Error: futex: Bad address (in wait_for_sessiond() at lttng-ust-comm.c:636) >> libust[3341/3344]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) >> libust[3341/3345]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3341/3345]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3341/3345]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3341/3345]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3341/3341]: just registered probe ust_tests_hello containing 2 events (in ltt_probe_register() at ltt-probes.c:109) >> libust[3341/3341]: Registered event probe "ust_tests_hello:tptest" with signature "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-probes.c:118) >> libust[3341/3341]: Registered event probe "ust_tests_hello:tptest_sighandler" with signature "" (in ltt_probe_register() at ltt-probes.c:118) >> liblttng_ust_tracepoint[3341/3341]: just registered a tracepoints section from 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) >> liblttng_ust_tracepoint[3341/3341]: registered tracepoint: ust_tests_hello:tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) >> liblttng_ust_tracepoint[3341/3341]: registered tracepoint: ust_tests_hello:tptest (in tracepoint_register_lib() at tracepoint.c:643) >> >> Breakpoint 1, main (argc=1, argv=0xbffff754) at hello.c:84 >> 84 if (argc == 2) >> Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.12.i686 libuuid-2.17.2-12.4.el6.i686 >> (gdb) p __tracepoint_ust_tests_hello___tptest >> $1 = {name = 0x804a380 "ust_tests_hello:tptest", state = 0, probes = 0x0, tracepoint_provider_ref = 0x804b724, >> signature = 0x8049240 "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg", padding = '\000' } >> >> Notice here the __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust_tests_hello___tptest.probes both are 0, which means no register and API tracepoint doesn't invoke probe. >> >> Example B: enable event ust_tests_hello:tptest >> lttng create hello >> lttng enable-event ust_tests_hello:tptest -u >> lttng list hello >> Tracing session hello: [inactive] >> Trace path: /root/lttng-traces/hello-20120621-073315 >> >> === Domain: UST global === >> >> Channels: >> ------------- >> - channel0: [enabled] >> >> Attributes: >> overwrite mode: 0 >> subbufers size: 4096 >> number of subbufers: 4 >> switch timer interval: 0 >> read timer interval: 200 >> output: mmap() >> >> Events: >> ust_tests_hello:tptest (type: tracepoint) [enabled] >> lttng start >> gdb ./hello >> (gdb) file .libs/hello >> (gdb) set env LTTNG_UST_DEBUG=1 >> (gdb) show env >> ... >> LTTNG_UST_DEBUG=1 >> (gdb) br main >> Breakpoint 1 at 0x80489b9: file hello.c, line 84. >> (gdb) r >> Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hello >> [Thread debugging using libthread_db enabled] >> liblttng_ust_tracepoint[3365/3365]: just registered a tracepoints section from 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) >> liblttng_ust_tracepoint[3365/3365]: registered tracepoint: lttng_ust:metadata (in tracepoint_register_lib() at tracepoint.c:643) >> libust[3365/3365]: just registered probe lttng_ust containing 1 events (in ltt_probe_register() at ltt-probes.c:109) >> libust[3365/3365]: Registered event probe "lttng_ust:metadata" with signature "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) >> libust[3365/3365]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-client.h:334) >> libust[3365/3365]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:584) >> libust[3365/3365]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) >> [New Thread 0xb7dddb70 (LWP 3368)] >> libust[3365/3368]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) >> [New Thread 0xb75dcb70 (LWP 3369)] >> libust[3365/3368]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:621) >> libust[3365/3368]: Linux kernels 2.6.33 to 3.0 (with the exception of stable versions) do not support FUTEX_WAKE on read-only memory mappings correctly. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallback. (in wait_for_sessiond() at lttng-ust-comm.c:634) >> libust[3365/3368]: Error: futex: Bad address (in wait_for_sessiond() at lttng-ust-comm.c:636) >> libust[3365/3368]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> liblttng_ust_tracepoint[3365/3369]: Registering probe to tracepoint lttng_ust:metadata (in __tracepoint_probe_register() at tracepoint.c:426) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3369]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3365/3369]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3365/3365]: just registered probe ust_tests_hello containing 2 events (in ltt_probe_register() at ltt-probes.c:109) >> libust[3365/3365]: Registered event probe "ust_tests_hello:tptest" with signature "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-probes.c:118) >> liblttng_ust_tracepoint[3365/3365]: Registering probe to tracepoint ust_tests_hello:tptest (in __tracepoint_probe_register() at tracepoint.c:426) >> libust[3365/3365]: Registered event probe "ust_tests_hello:tptest_sighandler" with signature "" (in ltt_probe_register() at ltt-probes.c:118) >> liblttng_ust_tracepoint[3365/3365]: just registered a tracepoints section from 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) >> liblttng_ust_tracepoint[3365/3365]: registered tracepoint: ust_tests_hello:tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) >> liblttng_ust_tracepoint[3365/3365]: registered tracepoint: ust_tests_hello:tptest (in tracepoint_register_lib() at tracepoint.c:643) >> >> Breakpoint 1, main (argc=1, argv=0xbffff754) at hello.c:84 >> 84 if (argc == 2) >> Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.12.i686 libuuid-2.17.2-12.4.el6.i686 >> (gdb) p __tracepoint_ust_tests_hello___tptest >> $1 = {name = 0x804a380 "ust_tests_hello:tptest", state = 1, probes = 0x804c258, tracepoint_provider_ref = 0x804b724, >> signature = 0x8049240 "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg", padding = '\000' } >> >> We can see __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust_tests_hello___tptest.probes have been set, which means API tracepoint can invoke probe callback function and generate trace info. >> >> Example C: enable event and then disable it >> lttng create hello >> Session hello created. >> Traces will be written in /root/lttng-traces/hello-20120621-074221 >> lttng enable-event ust_tests_hello:tptest -u >> UST event ust_tests_hello:tptest created in channel channel0 >> lttng disable-event ust_tests_hello:tptest -u >> UST event ust_tests_hello:tptest disabled in channel channel0 for session hello >> lttng list hello >> Tracing session hello: [inactive] >> Trace path: /root/lttng-traces/hello-20120621-074221 >> >> === Domain: UST global === >> >> Channels: >> ------------- >> - channel0: [enabled] >> >> Attributes: >> overwrite mode: 0 >> subbufers size: 4096 >> number of subbufers: 4 >> switch timer interval: 0 >> read timer interval: 200 >> output: mmap() >> >> Events: >> ust_tests_hello:tptest (type: tracepoint) [disabled] >> >> lttng start >> gdb ./hello >> (gdb) file .libs/hello >> (gdb) set env LTTNG_UST_DEBUG=1 >> (gdb) show env >> ... >> LTTNG_UST_DEBUG=1 >> (gdb) br main >> Breakpoint 1 at 0x80489b9: file hello.c, line 84. >> (gdb) r >> Starting program: /root/project/lttng/lttng-ust-2.0.2/tests/hello/.libs/hello >> [Thread debugging using libthread_db enabled] >> liblttng_ust_tracepoint[3384/3384]: just registered a tracepoints section from 0xb7fddd64 and having 1 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) >> liblttng_ust_tracepoint[3384/3384]: registered tracepoint: lttng_ust:metadata (in tracepoint_register_lib() at tracepoint.c:643) >> libust[3384/3384]: just registered probe lttng_ust containing 1 events (in ltt_probe_register() at ltt-probes.c:109) >> libust[3384/3384]: Registered event probe "lttng_ust:metadata" with signature "const char *, str" (in ltt_probe_register() at ltt-probes.c:118) >> libust[3384/3384]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_metadata_client_init() at ltt-ring-buffer-metadata-client.h:334) >> libust[3384/3384]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_client_overwrite_init() at ltt-ring-buffer-client.h:584) >> libust[3384/3384]: LTT : ltt ring buffer client init >> (in ltt_ring_buffer_client_discard_init() at ltt-ring-buffer-client.h:584) >> [New Thread 0xb7dddb70 (LWP 3387)] >> [New Thread 0xb75dcb70 (LWP 3388)] >> libust[3384/3387]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) >> libust[3384/3387]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:621) >> libust[3384/3387]: Linux kernels 2.6.33 to 3.0 (with the exception of stable versions) do not support FUTEX_WAKE on read-only memory mappings correctly. Please upgrade your kernel (fix is commit 9ea71503a8ed9184d2d0b8ccc4d269d05f7940ae in Linux kernel mainline). LTTng-UST will use polling mode fallback. (in wait_for_sessiond() at lttng-ust-comm.c:634) >> libust[3384/3387]: Error: futex: Bad address (in wait_for_sessiond() at lttng-ust-comm.c:636) >> libust[3384/3387]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:699) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> liblttng_ust_tracepoint[3384/3388]: Registering probe to tracepoint lttng_ust:metadata (in __tracepoint_probe_register() at tracepoint.c:426) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3388]: message received >> (in ust_listener_thread() at lttng-ust-comm.c:766) >> libust[3384/3388]: message successfully sent (in send_reply() at lttng-ust-comm.c:202) >> libust[3384/3384]: just registered probe ust_tests_hello containing 2 events (in ltt_probe_register() at ltt-probes.c:109) >> libust[3384/3384]: Registered event probe "ust_tests_hello:tptest" with signature "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg" (in ltt_probe_register() at ltt-probes.c:118) >> liblttng_ust_tracepoint[3384/3384]: Registering probe to tracepoint ust_tests_hello:tptest (in __tracepoint_probe_register() at tracepoint.c:426) >> libust[3384/3384]: Registered event probe "ust_tests_hello:tptest_sighandler" with signature "" (in ltt_probe_register() at ltt-probes.c:118) >> liblttng_ust_tracepoint[3384/3384]: just registered a tracepoints section from 0x804b6c4 and having 2 tracepoints (in tracepoint_register_lib() at tracepoint.c:638) >> liblttng_ust_tracepoint[3384/3384]: registered tracepoint: ust_tests_hello:tptest_sighandler (in tracepoint_register_lib() at tracepoint.c:643) >> liblttng_ust_tracepoint[3384/3384]: registered tracepoint: ust_tests_hello:tptest (in tracepoint_register_lib() at tracepoint.c:643) >> >> Breakpoint 1, main (argc=1, argv=0xbffff754) at hello.c:84 >> 84 if (argc == 2) >> Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.12.i686 libuuid-2.17.2-12.4.el6.i686 >> (gdb) p __tracepoint_ust_tests_hello___tptest >> $1 = {name = 0x804a380 "ust_tests_hello:tptest", state = 1, probes = 0x804c258, tracepoint_provider_ref = 0x804b724, >> signature = 0x8049240 "int, anint, int, netint, long *, values, char *, text, size_t, textlen, double, doublearg, float, floatarg", padding = '\000' } >> >> Here __tracepoint_ust_tests_hello___tptest.state and __tracepoint_ust_tests_hello___tptest.probes have been set, which means probe callback function wiil be called by API tracepoint. But the event has been disabled, is this necessary to call into the probe again? If this behavior is normal, what's suppoed to do with disable-event command? >> >> Any misunderstanding please fix me. Thanks > disabling an event ends up calling, in the program: > > lttng-ust-abi.c:lttng_event_cmd() with "LTTNG_UST_DISABLE", which calls > ltt_event_disable(). Looking at this function: > > int ltt_event_disable(struct ltt_event *event) > { > int old; > > if (event->chan == event->chan->session->metadata) > return -EPERM; > old = uatomic_xchg(&event->enabled, 0); > if (!old) > return -EEXIST; > return 0; > } > > shows us that disabling an event sets the "enabled" flag within the > event (struct ltt_event) to 0. This flag is tested in > include/lttng/ust-tracepoint-event.h: > > #undef TRACEPOINT_EVENT_CLASS > #define TRACEPOINT_EVENT_CLASS(_provider, _name, _args, _fields) \ > static void __event_probe__##_provider##___##_name(_TP_ARGS_DATA_PROTO(_args))\ > [...] > if (caa_unlikely(!CMM_ACCESS_ONCE(__chan->session->active))) \ > return; \ > if (caa_unlikely(!CMM_ACCESS_ONCE(__chan->enabled))) \ > return; \ > if (caa_unlikely(!CMM_ACCESS_ONCE(__event->enabled))) \ > return; > > What you are looking at with the debugger are the tracepoint call sites, > which still have a handler connected to them when you disable the event. > So yes, in theory, we could lessen the overhead of the enable followed > by disable case and ensure that we disconnect the probe from the call > site, but diminishing the performance impact of this rare use-case has > not been high on my priority list so far. > > Hoping that my explanation helps clarifying things, Mathieu, thank you so much. May I know if following two features have been in your schedule list? If yes, what's the target release? a. trace_printf API b. dynamic tracing for lttng-ust Best regards Zheng > Thanks, > > Mathieu > >> Best Regards >> Zheng >> >> >>> Thanks, >>> Mathieu >>> >>> Thanks all for your useful info! >>> >>> Best regards >>> Zheng >>> >>>>> _______________________________________________ >>>>> lttng-dev mailing list >>>>> lttng-dev@lists.lttng.org >>>>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev >>> >>>> -- >>>> Mathieu Desnoyers >>>> Operating System Efficiency R&D Consultant >>>> EfficiOS Inc. >>>> http://www.efficios.com >>>> _______________________________________________ >>>> lttng-dev mailing list >>>> lttng-dev@lists.lttng.org >>>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev >>> -- >>> Mathieu Desnoyers >>> Operating System Efficiency R&D Consultant >>> EfficiOS Inc. >>> http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: Some questions about Lttng Date: Tue, 26 Jun 2012 02:06:09 -0400 Message-ID: <20120626060609.GD11445__34427.9077988633$1340690789$gmane$org@Krystal> References: <20120619163655.GC6743@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC418@CORPUSMX30B.corp.emc.com> <20120620130338.GA25746@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC8FC@CORPUSMX30B.corp.emc.com> <20120621124532.GA7255@Krystal> <4FE8141D.3030107@emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.openrapids.net ([64.15.138.104] helo=blackscsi.openrapids.net) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1SjOug-00065R-HJ for lttng-dev@lists.lttng.org; Tue, 26 Jun 2012 02:06:10 -0400 Content-Disposition: inline In-Reply-To: <4FE8141D.3030107@emc.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: changz Cc: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org * changz (zheng.chang@emc.com) wrote: [...] > Mathieu, thank you so much. > May I know if following two features have been in your schedule list? If > yes, what's the target release? > a. trace_printf API In schedule list, by the end of 2012. > b. dynamic tracing for lttng-ust No ETA at the moment for this feature. It's a "wishlist" feature, but it is not planned for any specific point in time. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: changz Subject: Re: Some questions about Lttng Date: Tue, 26 Jun 2012 16:59:55 +0800 Message-ID: <4FE97A0B.4070608__4197.79601875252$1340701300$gmane$org@emc.com> References: <20120619163655.GC6743@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC418@CORPUSMX30B.corp.emc.com> <20120620130338.GA25746@Krystal> <6539770C71C3814BB0BFC2DBEBD105087FC8FC@CORPUSMX30B.corp.emc.com> <20120621124532.GA7255@Krystal> <4FE8141D.3030107@emc.com> <20120626060609.GD11445@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from hop-nat-141.emc.com ([168.159.213.141] helo=mexforward.lss.emc.com) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1SjRdF-0007Sm-Pw for lttng-dev@lists.lttng.org; Tue, 26 Jun 2012 05:00:21 -0400 In-Reply-To: <20120626060609.GD11445@Krystal> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: Mathieu Desnoyers Cc: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org On 6/26/2012 14:06 PM, Mathieu Desnoyers wrote: > * changz (zheng.chang@emc.com) wrote: > [...] >> Mathieu, thank you so much. >> May I know if following two features have been in your schedule list? If >> yes, what's the target release? >> a. trace_printf API > In schedule list, by the end of 2012. > >> b. dynamic tracing for lttng-ust > No ETA at the moment for this feature. It's a "wishlist" feature, but > it is not planned for any specific point in time. I see. Thanks for your info. Best Regards Zheng > Thanks, > > Mathieu > From mboxrd@z Thu Jan 1 00:00:00 1970 From: loody Subject: some questions about lttng Date: Sat, 10 Nov 2012 17:55:57 +0800 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f48.google.com ([74.125.83.48]) by ltt.polymtl.ca with esmtp (Exim 4.72) (envelope-from ) id 1TX7nG-0006dC-ST for lttng-dev@lists.lttng.org; Sat, 10 Nov 2012 04:56:03 -0500 Received: by mail-ee0-f48.google.com with SMTP id b45so2871024eek.35 for ; Sat, 10 Nov 2012 01:55:57 -0800 (PST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: lttng-dev@lists.lttng.org List-Id: lttng-dev@lists.lttng.org hi all: each time I use lttng, I -- Regards,