* RE: [ltt-dev] gdb-7.2 can't build with lttng-ust-0.12 [not found] ` <BLU0-SMTP7051C411EF9E3864329F4596960@phx.gbl> @ 2011-04-26 1:51 ` Cui, Dexuan 2011-04-26 18:47 ` Tom Tromey 0 siblings, 1 reply; 5+ messages in thread From: Cui, Dexuan @ 2011-04-26 1:51 UTC (permalink / raw) To: 'Mathieu Desnoyers', 'ltt-dev@lists.casi.polymtl.ca' Cc: 'gdb@sourceware.org' Mathieu Desnoyers wrote: > * Cui, Dexuan (dexuan.cui AT intel.com) wrote: >> Due to the API changes in lttng-ust 0.12, gdb's latest version 7.2 >> can't build with lttng-ust: >> http://sourceware.org/ml/gdb/2011-04/msg00140.html >> >> Hope somebody here can help gdb to work with ust 0.12. :-) > > Hi Dexuan, > > 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. Hi Mathieu, Thanks very much for the info! I'm looking forward to seeing 0.13 released and hope it can build with gdb-7.2. :-) > 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. Unluckily I'm pretty new to gdb and know few about this now. Let me Cc the gdb mailing list for more thoughts(hope this cross-posting wouldn't bother people). Thanks! -- Dexuan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ltt-dev] gdb-7.2 can't build with lttng-ust-0.12 2011-04-26 1:51 ` [ltt-dev] gdb-7.2 can't build with lttng-ust-0.12 Cui, Dexuan @ 2011-04-26 18:47 ` Tom Tromey 2011-04-26 21:42 ` Mathieu Desnoyers ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Tom Tromey @ 2011-04-26 18:47 UTC (permalink / raw) To: Cui, Dexuan Cc: 'Mathieu Desnoyers', 'ltt-dev@lists.casi.polymtl.ca', 'gdb@sourceware.org' >>>>> "Dexuan" == Cui, Dexuan <dexuan.cui@intel.com> writes: Mathieu> Also, we should reopen the discussion on the way the UST Markers Mathieu> collect the registers for GDB, because the current way involves a Mathieu> _lot_ of ugly assembly code. It should be possible to only use a Mathieu> volatile inline asm to specify input constraints on the target marker Mathieu> parameters, and keep the instruction pointer address that corresponds Mathieu> to this inline asm in a section known by gdb (so gdb could use the Mathieu> drawf info to fetch data from registers/memory). If you can ensure Mathieu> that this would fit gdb's requirements, I could clean up the marker Mathieu> code and we could resync the APIs together. We could also provide Mathieu> this for UST Tracepoints in the same go, with pretty much the same Mathieu> interface as we'd use for UST Markers. I am aware that this would Mathieu> require change on the GDB side, but I think it's better to Mathieu> synchronise our effort rather than to shoot at different targets. I am not totally clear on the proposal here. If this means reusing the <sys/sdt.h> stuff, then there are gdb patches already submitted to fully support that; and updating the existing code to also use it should not be very difficult. See gdb-patches from the last month or two. If instead you mean something else, it would be useful to have more information. From your description it sounds like this may be a different design from SDT v3; but note that SDT v2 tried to use DWARF to access the parameters and ran into various problems. I can get details on the failure modes if this is what you intend. Dexuan> Unluckily I'm pretty new to gdb and know few about this now. Dexuan> Let me Cc the gdb mailing list for more thoughts(hope this cross-posting Dexuan> wouldn't bother people). Cross-posting in cases like this is fine, even preferable. I don't know anything about the gdbserver bits here. It seems to me that it would be reasonable to have gdbserver compile against various versions of UST. Tom ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ltt-dev] gdb-7.2 can't build with lttng-ust-0.12 2011-04-26 18:47 ` Tom Tromey @ 2011-04-26 21:42 ` Mathieu Desnoyers [not found] ` <BLU0-SMTP3759F7830D97C89E9BCE9796990@phx.gbl> [not found] ` <BLU0-SMTP45CC9DEEE33FD5A526EB3896990@phx.gbl> 2 siblings, 0 replies; 5+ messages in thread From: Mathieu Desnoyers @ 2011-04-26 21:42 UTC (permalink / raw) To: Tom Tromey Cc: Cui, Dexuan, 'ltt-dev@lists.casi.polymtl.ca', 'gdb@sourceware.org', systemtap, Josh Stone * Tom Tromey (tromey@redhat.com) wrote: > >>>>> "Dexuan" == Cui, Dexuan <dexuan.cui@intel.com> writes: > > Mathieu> Also, we should reopen the discussion on the way the UST Markers > Mathieu> collect the registers for GDB, because the current way involves a > Mathieu> _lot_ of ugly assembly code. It should be possible to only use a > Mathieu> volatile inline asm to specify input constraints on the target marker > Mathieu> parameters, and keep the instruction pointer address that corresponds > Mathieu> to this inline asm in a section known by gdb (so gdb could use the > Mathieu> drawf info to fetch data from registers/memory). If you can ensure > Mathieu> that this would fit gdb's requirements, I could clean up the marker > Mathieu> code and we could resync the APIs together. We could also provide > Mathieu> this for UST Tracepoints in the same go, with pretty much the same > Mathieu> interface as we'd use for UST Markers. I am aware that this would > Mathieu> require change on the GDB side, but I think it's better to > Mathieu> synchronise our effort rather than to shoot at different targets. > > I am not totally clear on the proposal here. > > If this means reusing the <sys/sdt.h> stuff, then there are gdb patches > already submitted to fully support that; and updating the existing code > to also use it should not be very difficult. See gdb-patches from the > last month or two. Yes, the goal is to rely on sdt.h as soon as it supports a e.g. STAP_PROBEV (with variable number of args). The Josh Stone found a neat trick to do it, and I think he is preparing an updated version. The only concern here is the packaging: if we depend on sdt.h, we have to either ship it with UST, or have one more dependency on a package available for all architectures that only contain this header. Thoughts ? It's good to hear that GDB is already planning on supporting that. Thanks, Mathieu > > If instead you mean something else, it would be useful to have more > information. From your description it sounds like this may be a > different design from SDT v3; but note that SDT v2 tried to use DWARF to > access the parameters and ran into various problems. I can get details > on the failure modes if this is what you intend. > > Dexuan> Unluckily I'm pretty new to gdb and know few about this now. > Dexuan> Let me Cc the gdb mailing list for more thoughts(hope this cross-posting > Dexuan> wouldn't bother people). > > Cross-posting in cases like this is fine, even preferable. > > I don't know anything about the gdbserver bits here. It seems to me > that it would be reasonable to have gdbserver compile against various > versions of UST. > > Tom > -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <BLU0-SMTP3759F7830D97C89E9BCE9796990@phx.gbl>]
* Re: [ltt-dev] gdb-7.2 can't build with lttng-ust-0.12 [not found] ` <BLU0-SMTP3759F7830D97C89E9BCE9796990@phx.gbl> @ 2011-04-27 0:26 ` Josh Stone 0 siblings, 0 replies; 5+ messages in thread From: Josh Stone @ 2011-04-27 0:26 UTC (permalink / raw) To: Mathieu Desnoyers; +Cc: Tom Tromey, Cui, Dexuan, ltt-dev, gdb, systemtap On 04/26/2011 02:41 PM, Mathieu Desnoyers wrote: > Yes, the goal is to rely on sdt.h as soon as it supports a e.g. > STAP_PROBEV (with variable number of args). The Josh Stone found a neat > trick to do it, and I think he is preparing an updated version. I committed STAP_PROBEV to systemtap.git a couple of weeks ago. We just haven't prepared a new release yet. (soon...) > The only concern here is the packaging: if we depend on sdt.h, we have > to either ship it with UST, or have one more dependency on a package > available for all architectures that only contain this header. Thoughts ? In Fedora and RHEL, systemtap-sdt-devel.rpm contains the sdt.h header and a "dtrace" python script. The latter is only needed for projects that are specifically building the DTrace way. Distros that don't care about that could get away with packaging just the header. As for "all" architectures, there's very little arch-specific code in sdt.h, currently contained in two defines. There's _SDT_NOP for choosing the variation of "nop" of "nop 0", and there's _SDT_ARGTMPL to provide a special template for the powerpc case. If other archs need special consideration, we'll gladly accept patches. Josh ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <BLU0-SMTP45CC9DEEE33FD5A526EB3896990@phx.gbl>]
* Re: [ltt-dev] gdb-7.2 can't build with lttng-ust-0.12 [not found] ` <BLU0-SMTP45CC9DEEE33FD5A526EB3896990@phx.gbl> @ 2011-04-27 14:32 ` Tom Tromey 0 siblings, 0 replies; 5+ messages in thread From: Tom Tromey @ 2011-04-27 14:32 UTC (permalink / raw) To: Mathieu Desnoyers Cc: Cui, Dexuan, 'ltt-dev@lists.casi.polymtl.ca', 'gdb@sourceware.org', systemtap, Josh Stone >>>>> "Mathieu" == Mathieu Desnoyers <compudj@krystal.dyndns.org> writes: Mathieu> The only concern here is the packaging: if we depend on sdt.h, Mathieu> we have to either ship it with UST, or have one more dependency Mathieu> on a package available for all architectures that only contain Mathieu> this header. Thoughts ? One typical way to handle this is to put a copy of the code into your tree, but provide an option to use the system version instead. E.g., GDB does this with readline. This makes it build fine out of the box for casual users, but is also friendly to distros. This implies some discipline on your part -- updating regularly and not diverging. Alternatively, split sdt.h out into its own project and make it a build-time requirement of both stap and ust. This seems pretty heavy-weight for a couple of header files, though. Tom ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-04-27 14:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1865303E0DED764181A9D882DEF65FB6931C75A5AA@shsmsx502.ccr.corp.intel.com> [not found] ` <BLU0-SMTP7051C411EF9E3864329F4596960@phx.gbl> 2011-04-26 1:51 ` [ltt-dev] gdb-7.2 can't build with lttng-ust-0.12 Cui, Dexuan 2011-04-26 18:47 ` Tom Tromey 2011-04-26 21:42 ` Mathieu Desnoyers [not found] ` <BLU0-SMTP3759F7830D97C89E9BCE9796990@phx.gbl> 2011-04-27 0:26 ` Josh Stone [not found] ` <BLU0-SMTP45CC9DEEE33FD5A526EB3896990@phx.gbl> 2011-04-27 14:32 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).