Bug 1005

Summary: gdb-7.2: can't build with ust-0.12: need upstream fix
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Dexuan Cui <dexuan.cui>
Component: coreAssignee: Saul Wold <sgw>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: meta.mr.watcher, meta.watcher, sgw
Version: unspecified   
Target Milestone: 1.1   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Dexuan Cui 2011-04-25 01:18:22 UTC 
By default gdb-7.2 depends on ust(btw, the recipe of gdb lacks: DEPENDS += " lttng-ust") unless we specify --without-ust.

gdb-7.2 works with lttng-ust 0.11 fine.
Recently we upgraded lttng-ust to 0.12 that has API changes(http://www.mail-archive.com/ltt-dev@lists.casi.polymtl.ca/msg01839.html) so gdb-7.2 doesn't build now:
gdb-7.2/gdb/gdbserver/tracepoint.c: In function 'first_marker':
gdb-7.2/gdb/gdbserver/tracepoint.c:7009:3: warning: return from incompatible pointer type.

Saul has worked around the build issue by adding --without-ust to gdb-7.2's configure, and we need try to push upstream gdb to fix the issue.
Comment 1 Dexuan Cui 2011-04-25 06:25:44 UTC 
I reported http://sourceware.org/bugzilla/show_bug.cgi?id=12699 in gdb bugzilla.

Also reported the issue in gdb and lttng-ust communities:
http://sourceware.org/ml/gdb/2011-04/msg00140.html
http://lists.casi.polymtl.ca/pipermail/ltt-dev/2011-April/004449.html
Comment 2 Dexuan Cui 2011-04-25 18:52:55 UTC 
A comment from lttng mailing list follows:

http://lists.casi.polymtl.ca/pipermail/ltt-dev/2011-April/004450.html

----------------------------

We're currently doing instrumentation API changes in UST. At the moment,
it is in the git tree, planned for release in UST 0.13. Our goal is to
perform this painful (but required) step sooner than later so that we
minimize the amount of pain for our user-base.

Also, we should reopen the discussion on the way the UST Markers collect
the registers for GDB, because the current way involves a _lot_ of ugly
assembly code. It should be possible to only use a volatile inline asm
to specify input constraints on the target marker parameters, and keep
the instruction pointer address that corresponds to this inline asm in a
section known by gdb (so gdb could use the drawf info to fetch data from
registers/memory). If you can ensure that this would fit gdb's
requirements, I could clean up the marker code and we could resync the
APIs together. We could also provide this for UST Tracepoints in the
same go, with pretty much the same interface as we'd use for UST
Markers. I am aware that this would require change on the GDB side, but
I think it's better to synchronise our effort rather than to shoot at
different targets.

Thanks,

Mathieu

----------------------------
Comment 3 Saul Wold 2011-04-28 15:20:05 UTC 
Need to wait for the upstream resolution with UST and gdb