[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[Cui, Dexuan]

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. :-)

Thanks!

-- Dexuan
 

[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[Mathieu Desnoyers]

* 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.

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

> 
> Thanks!
> 
> -- Dexuan
>  
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[Cui, Dexuan]

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

[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[Tom Tromey]

>>>>> "Dexuan" == Cui, Dexuan <dexuan.cui at 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

[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[Mathieu Desnoyers]

* Tom Tromey (tromey at redhat.com) wrote:
> >>>>> "Dexuan" == Cui, Dexuan <dexuan.cui at 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

[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[Josh Stone]

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

[ltt-dev] gdb-7.2 can't build with lttng-ust-0.12

[Tom Tromey]

>>>>> "Mathieu" == Mathieu Desnoyers <compudj at 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