DTrace issues?

[Mark Johnston]

On Mon, Apr 17, 2017 at 09:28:07PM +0100, Sevan / Venture37 wrote:
> On 17 April 2017 at 20:54, Ryan Stone <rysto32 at gmail.com> wrote:
> > On Sat, Apr 15, 2017 at 10:50 AM, George Neville-Neil <gnn at neville-neil.com>
> > wrote:
> >
> >>
> >> Can you explain this grief?  What is the problem?
> >>
> >> Best,
> >> George
> >>
> >
> > dtrace -G requires the ability to modify the object files in-place before
> > linking.  This causes havoc if the objects are in .a archives (dtrace can't
> > read those) or if the objects need to be linked into multiple binaries.  It
> > also destroys the ability to do an incremental build, as dtrace -G can't be
> > run on the same object twice.
> >
> > The whole process is really a hack.  The build actions done by dtrace
> > should be done by the compiler and linker instead.  Getting the linker to
> > support the process would go a long way, as then dtrace -G could be run on
> > individual objects and most of my complaints go away.
> 
> Not to detract from the issue with the -G flag, I just wanted to
> highlight that it's used for ELF binaries, until Apple switches away
> from Mach-o, this wont be an issue there (dtrace on OS X does not
> feature the -G flag).

I think the more significant difference is that Apple has more control
over their toolchain and have modified it to directly implement the
functionality that's overwise implemented by dtrace -G.

As Ryan pointed out, this functionality really belongs in the static
linker; one more piece of evidence for this is the number of non-trivial
modifications we've needed to make to dtrace -G to avoid relying on
undocumented behaviour in the Sun link editor, and later, GNU ld 2.17.
Now that FreeBSD is transitioning to lld, we have some opportunity to
implement USDT support in the static linker, and at least one of the lld
developers seems amenable to proposals along those lines. However, I
don't know of any concrete plans or designs.