DTrace issues?

[George Neville-Neil]

On 17 Apr 2017, at 17:26, Mark Johnston wrote:

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

Seems like something we could discuss in an RFD:

https://github.com/opendtrace/rfd

Best,
George