Project

General

Profile

Actions

Bug #376

closed

32b instrumented application with lttng-sessiond in 64b

Added by Damien COTTIER over 11 years ago. Updated over 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
10/16/2012
Due date:
% Done:

0%

Estimated time:

Description

Hi,

I have build from the repository lttng-tools/ust/babeltrace/userspace-rcu environment for both 32b/64b userspace ABI (i'm on a x86_64 fc16 machine).

build cmd line example for lttng-ust modules

export INSTALL_PREFIX=/home/dcottier/Trace

cd lttng-ust ; git clean -xdf ; ./bootstrap ; LDFLAGS=-L${INSTALL_PREFIX}/lib64 CPPFLAGS=-I${INSTALL_PREFIX}/include ./configure --prefix=${INSTALL_PREFIX} --libdir=${INSTALL_PREFIX}/lib64 && make install ; cd -
cd lttng-ust ; git clean -xdf ; ./bootstrap ; LDFLAGS="-L${INSTALL_PREFIX}/lib -m32" CPPFLAGS="-I${INSTALL_PREFIX}/include -m32" ./configure --prefix=${INSTALL_PREFIX} --libdir=${INSTALL_PREFIX}/lib --bindir=${INSTALL_PREFIX}/bin32 && make install ; cd -

After building successfully the lttng tools i tried to start a session and use a simple 32b instrumented application:

HOME=/home/dcottier/Trace /home/dcottier/Trace/bin/lttng-sessiond --consumerd32-path /home/dcottier/Trace/lib/lttng/libexec/lttng-consumerd --consumerd32-libdir /home/dcottier/Trace/lib/ --consumerd64-path /home/dcottier/Trace//lib64/lttng/libexec/lttng-consumerd --consumerd64-libdir /home/dcottier/Trace//lib64/ --verbose-consumer --verbose --no-kernel

on another shell:

/home/dcottier/Trace/bin/lttng create test
/home/dcottier/Trace/bin/lttng enable-event -u -a
/home/dcottier/Trace/bin/lttng start

Launching the 32b instrumented application:

./lttng-ust/tests/hello/hello
libust[8926/8941]: Error: incorrect message size (local socket): 4
(in ust_listener_thread() at lttng-ust-comm.c:878)
libust[8926/8941]: Error: incorrect message size (local socket): 4
(in ust_listener_thread() at lttng-ust-comm.c:878)
Hello, World!
Tracing... done

The lttng-session/consumer daemon gives the following messages:

DEBUG1: Woken up but nothing in the UST command queue [in thread_dispatch_ust_registration() at main.c:1250]
DEBUG3: Created hashtable size 4 at 0x7f47900009d0 of type 1 [in lttng_ht_new() at hashtable.c:96]
DEBUG1: App registered with pid:8926 ppid:8588 uid:1001 gid:1001 sock:19 name:lt-hello (version 2.0) [in ust_app_register() at ust-app.c:1474]
incorrect message size: 292
incorrect message size: 292
DEBUG1: PID 8926 unregistering with sock 19 [in ust_app_unregister() at ust-app.c:1504]
DEBUG1: Apps thread polling on 2 fds [in thread_manage_apps() at main.c:1095]
DEBUG3: Call RCU deleting app PID 8926 [in delete_ust_app_rcu() at ust-app.c:240]

However the same test case using 32b lttng tools will work:

HOME=/home/dcottier/Trace /home/dcottier/Trace/bin32/lttng-sessiond --consumerd32-path /home/dcottier/Trace/lib/lttng/libexec/lttng-consumerd --consumerd32-libdir /home/dcottier/Trace/lib/ --consumerd64-path /home/dcottier/Trace//lib64/lttng/libexec/lttng-consumerd --consumerd64-libdir /home/dcottier/Trace//lib64/ --verbose-consumer --verbose --no-kernel

/home/dcottier/Trace/bin32/lttng create test
/home/dcottier/Trace/bin32/lttng enable-event -u -a
/home/dcottier/Trace/bin32/lttng start

Launching the 32b instrumented application:

./lttng-ust/tests/hello/hello
Hello, World!
Tracing... done.

everything will work properly and all the tracepoints can be observed using babeltrace.
ex:

...
test: { cpu_id = 2 }, { intfield = 999999, intfield2 = 0xF423F, longfield = 999999, netintfield = 999999, netintfieldhex = 0xF423F, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2, boolfield = 1 }

Is there any reason for instrumented 32b application not being supported via 64b lttng tools?

I tried to force packing some structure (ustcomm_ust_reply and ustcomm_ust_msg) and provide full matching of 32b/64 structure size while reorganizing structure element and tune the various #define *PADDING present in the ust-abi.h. The message size mismatch error disappear then but i still failing later in lttcomm_recv_fds_unix_sock going into "Invalid control message header".

Rgds.

Actions

Also available in: Atom PDF