[DTrace-devel] Dtrace on Linux Port

[Nick Alcock]

On 1 Mar 2018, Paul Dagnelie said:

> Hey all,
>
> As part of a hackathon project, I was attempting to build the linux kernel
> with dtrace, get it running on a VM, and then get it working with ZFS On
> Linux.  I have had moderate success; I managed to get the machine to boot,
> the dtrace modules loaded, and zfs installed. I can run dtrace fbt probes
> and see stack traces! However, there is a significant barrier to doing more
> interesting things: the kernel does not appear to contain any CTF data.

As you've discovered, CTF data is only built when explicitly requested

> Attempting to run `make ctf` in the linux kernel results in a slew of
> errors of the form ERROR: "osduld_device_info" [fs/exofs/exofs.ko]
> undefined!  I was hoping that someone on this list might be able to provide
> some insight into what's going on here, and potentially how to fix the
> issues. Thanks for your time!

This is almost certainly a bug, but I'd need more build output to be
sure what component it came from. dwarf2ctf has been developed by fixing
bugs as they arise, which means that configs very different from the
ones it's been tested with may malfunction :(

However, that is not your problem. dwarf2ctf never emits any messages of
the form 'ERROR: ': that error sounds like it's coming from modpost.
(See scripts/mod/modpost.c:add_versions()).

Since modpost runs before dwarf2ctf and is serialized with it (since it
edits the module object files, and dwarf2ctf reads them all in),
dwarf2ctf has never run and thus never had a chance to go wrong. I
suspect that this is a simple bug, probably a .config bug: you've got
exofs built in but CONFIG_SCSI_OSD_ULD is not set, so
drivers/scsi/osd/osd_uld.c, which defines that function, is never
compiled. Alternatively, it's quite possible that you can only build
exofs if you have built CONFIG_SCSI_OSD_ULD into the kernel rather than
making it a module, since otherwise you might end up with an
inter-modular call, or a call from a non-module to a module: the latter
is definitely verboten.

The exofs config depends on SCSI_OSD_ULD, so I wouldn't normally expect
this scenario to be possible, but perhaps it's happened anyway.

-- 
NULL && (void)