[DTrace-devel] Dtrace on Linux Port

[Paul Dagnelie]

Hey Nick,

Thanks for the feedback! I managed to get past that issue (I made a silly
mistake and only partially finished rebuilding the kernel after switching
branches a couple times), but now I am actually hitting a crash in
dwarf2ctf.  Unfortunately, the core dump is 7.2GB. I've taken a quick poke
around with gdb, and the crash is in ctf_type_resolve. Specifically, the
instruction that's faulting is `mov %rdi,0x8(%rsp)`, which looks to me like
it's overflowing a stack. It's possible that means the backtrace I got is
actually accurate, but I doubt it; after a few reasonable looking entries,
it quickly starts repeating `#n  0x00007f818c395c7d in ctf_type_align
(fp=<optimized out>, type=<optimized out>) at libctf/ctf_types.c:408` for
at least the next 15 thousand entries.  I've put the output of some
rudimentary GDBing in at https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_Fbne2xjw&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=TH500uwHRHLHqjhgluCyxMsbZEewvpf7ynuq0G-WrEk&m=R69QilJR7Qqi7XhNkV03JVyMwDa912j7jGdNfnj_hzQ&s=Un_Fl6yOvT7QN5wTaNgMxMWQvJJ9c8M6AirNoMmGJaY&e= . Let me know if you
need the core file itself, or any other information.

On Thu, Mar 1, 2018 at 1:55 PM, Nick Alcock <nick.alcock at oracle.com> wrote:

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



-- 
Paul Dagnelie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/dtrace-devel/attachments/20180302/7d4990da/attachment.html