3242 2012-10-05 12:21:50 +0000 cannot select kernel trace type for a lttng project 2019-08-29 15:17:24 +0000 1 1 6 Yocto Project Subprojects Eclipse Plugin eclipse-plugin 1.3 x86 Multiple CLOSED OBSOLETE release note, upstream is unpluged lttng legacy support, so please stop using lttng legacy Medium normal 1.3 1 alexandru.c.georgescu jessica.zhang dvhart ioanax.grigoropol tom.zanussi yp.ep.watcher yp.watcher --- --- --- oldest_to_newest 26281 0 alexandru.c.georgescu 2012-10-05 12:21:50 +0000 ######################################## STEPS TO REPRODUCE: 1.Upgrade Eclipse Linux tools lttng to latest version which is under http://download.eclipse.org/technology/linuxtools/update. 2.Install Lttng parser library 2.5 and 2.6 with the URL http://wiki.eclipse.org/Linux_Tools_Project/LTTng. 3. In Eclipse, File->New Project and create a new Lttng project. 4.Scp the file lttng.c to target machine, then in remote target run: gcc -lust lttng.c, it will generate a binary file named a.out. 5. Run lttng-ust YoctoProjectTools -> lttng-user space , in the window set the import project to your newly created lttng project, set Application as the absolute patch of a.out on target machine. 6.After lttng-ust is done, you should see an entry created in your ust project's Traces sub-dir, named as a long numbers. 7.Right click the entry to change the type to kernel type and select Open ######################################### EXPECTED RESULTS 7.You may see some tracing date in the lttng-viewer. ######################################### ACTUAL RESULTS 7. An error appears when selecting kernel trace type: Type could not be set for one or more traces. lttng.c file: ######## #include <ust/marker.h> int main(int argc, char **argv) { int v=6; char *st="lttng example"; trace_mark(main, myevent, "firstarg %d secondarg %s", v, st); trace_mark(main, myotherevent, MARK_NOARGS); return 0; } ######## 26282 1 alexandru.c.georgescu 2012-10-05 12:22:45 +0000 I am using: Location: http://autobuilder.yoctoproject.org/pub/nightly/20121003-4 Branch: danny Tag: 1.3_M5.rc3 Commits: poky: 86c9aa8081f107420cd3763d0566d779daddc2b1 eclipse-poky: aa38f8b19c921cce2f73647d8aeb7e355c868b56 meta-qt3: c86fb1727ae09526c442ec29fffde3f010aa70eb meta-intel: 2c1e927fa99abe47865a03cf661d4757ff3147c6 26355 2 dvhart 2012-10-08 18:00:08 +0000 Adding Tom to CC for context. 26503 3 jessica.zhang 2012-10-11 04:04:02 +0000 Alex, Is this the legacy lttng? 26510 4 alexandru.c.georgescu 2012-10-11 09:29:40 +0000 (In reply to comment #3) > Alex, > > Is this the legacy lttng? Hi Jessica, I am using the legacy lttng. 26542 5 jessica.zhang 2012-10-12 03:19:14 +0000 we'll remove lttng legacy support in 1.3 point release 26565 6 tom.zanussi 2012-10-13 17:48:49 +0000 The links above in STEPS TO REPRODUCE steps 1 and 2 don't work, and I wasn't able to locate any current documentation that tells how to set up ADT for 1.3, so haven't been able to get the basic setup working in order to try reproducing upgrading and installing the components mentioned. The comments suggest that the user has a choice between using legacy lttng and lttng 2.0. lttng 2.0 was currently not operational (either was legacy lttng because it's not supported in the yocto kernels, but that won't change), but I just submitted a couple patches that fix that: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-October/030957.html https://lists.yoctoproject.org/pipermail/poky/2012-October/008477.html With lttng 2.0 apparently fixed, can the above steps be used to test lttng 2.0 instead of legacy lttng for this bug? If so, please provide the correct links and updated instructions to try reproducing. 26613 7 tom.zanussi 2012-10-15 17:08:46 +0000 Apparently, eclipse in the Juno release already has an LTTNG plugin installed that will read and display lttng 2.0 traces. With the lttng-2.0 fixes mentioned in the previous comment, I was able to capture an lttng 2.0 trace and view the trace files in the eclipse 'LTTng kernel perspective'. This was the eclipse tarball that I used: eclipse-cpp-juno-SR1-linux-gtk-x86_64.tar.gz I wasn't able to connect to the target machine remotely to do this, though, I had to bring the trace files over manually - trying to connect to the remote target I got an 'RSE' error: 'Connect (RSE SubSystem Operation:)' has encountered a problem. Failed to connect sshd on "192.168.7.2:22" Failed to connect sshd on "192.168.7.2:22" 26614 8 jessica.zhang 2012-10-15 19:45:38 +0000 Tom, The RSE connection issue is caused by RSE can't handle proxy settings very well, so can you go to Windows->Preferences->General->Network Connection, then under Active Provider: select "Direct" instead of "Manual" or "Native". Also, for lttng2.0 we changed the tools to import the remote trace to local tracing project since upstream already have the built in viewer created. Thanks, Jessica 26615 9 tom.zanussi 2012-10-15 20:15:02 +0000 (In reply to comment #8) > Tom, > > The RSE connection issue is caused by RSE can't handle proxy settings very > well, so can you go to Windows->Preferences->General->Network Connection, > then under Active Provider: select "Direct" instead of "Manual" or "Native". > That seemed to work, thanks, or at least it now connects and lists available events, will have to play around to see if it actually works. > > Also, for lttng2.0 we changed the tools to import the remote trace to local > tracing project since upstream already have the built in viewer created. > So the LTTng kernel plugin that comes with Juno allows you to list events and initiate tracing over the network, and the tool changes you made allow you to import the trace to the local machine in order to view the trace? Not sure about the status of this bug then - none of this will work unless the 2 patches I posted to oe-core/poky are pulled in, as I understand it... But even then, is it working as intended? I have no context and although it seems to minimally work using Juno out of the box and just pointed at a Yocto target, I can't test using the official ADT tools since I can't find the appropriate docs. > Thanks, > Jessica 26618 10 jessica.zhang 2012-10-15 20:55:15 +0000 OK, I'm marking this bug as resolved and obsolte since 1: the context is more toward the legacy lttng-ust support which is obsolete and at that time when importing tracing data (even for ust), there's no other type associate it them so we just use kernel type, even though it's not right, but at least allow us to view the tracing data in the trace viewer. Long story shot, that is no longer support with the un-plug of legacy lttng-ust support from upstream. 2. Seems we're piggyback this bug for the new lttng2.0 support, so what I'm proposing us to do is: a. I'll update ADT manual for the correct 2.0 usage model which is more for importing remote tracing data to an local lttng project, kernel or user space. For 2.0 since upstream has done a full clean up, now for user space tracing data, the type will be distinguished as "generic CTF trace" or "kernel" trace depends on the tracing data. I've just verified that as far as user space trace, mapping them to "generic CTF trace" works fine. 2. Tom please make sure that our images after your patch can correctly generate both kernel and user space lttng tracing data. The user space tracing data that I've genereated is using the lttng 2.0 hello demo program sample and generate on my local host and copied over to remote target. Then I verified my eclipse plug-in works. So, yes, we've never fully tested lttng2.0 support in any of our images. 26642 11 alexandru.c.georgescu 2012-10-16 14:40:16 +0000 verified as per Jessica's last comment. 84826 12 akuster 2019-08-29 15:17:24 +0000 closing