ctfconvert dependency...

Shrikanth Kamath shrikanth07 at gmail.com
Thu Mar 11 09:26:40 UTC 2010


Any idea if ctfconvert is needed to run on the cddl and sys/cddl files? My
understanding here is ctfconvert
needs to build the ctfdata for the kernel image and the kernel loadable
modules. If we were to DTrace 'DTrace' then
we need the ctfdata for the files under cddl/ and sys/cddl, is that correct?


2010/3/11 Marius Nünnerich <marius at nuenneri.ch>

> 2010/3/11 "C. Bergström" <cbergstrom at pathscale.com>:
> > Shrikanth Kamath wrote:
> >>
> >> Just trying to understand the build dependency for ctfconvert...
> >>
> >> I see ctfconvert (cddl/usr.bin/ctfconvert/)  has dependency on libctf.a
> >> (cddl/lib/libctf/)
> >>
> >> Now the snippet in bsd.lib.mk has this check for various target
> suffixes,
> >>
> >> .c.So:
> >> .if defined(CTFCONVERT)
> >>        ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
> >> .endif
> >>
> >> and sys.mk
> >>
> >> .c
> >> .if defined(CTFCONVERT)
> >>        ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
> >> .endif
> >>
> >> My query, libctf includes  <bsd.lib.mk> in it's Makefile, so will the
> >> above
> >> not try to
> >> run 'ctfconvert' on libctf itself?
> >>
> >
> > I'm going to make some assumptions and go out on a limb here..
> >
> > The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg
> repo)
> >  When OpenSolaris is built they convert stab debugging information over
> to
> > CTF (compressed text format?).  This is done so that they can have
> debugging
> > information, but without the overhead of stab (or dwarf2).  I don't know
> how
> > much of the original onnv-gate Makefiles came over from OpenSolaris, but
> > assuming the FBSD kernel doesn't need/use CTF format this dependency can
> and
> > probably should go away.  (Only (k)mdb supports CTF that I'm aware of?)
> >
> > Hopefully this is useful information and I'm not too wrong or someone
> will
> > correct me
>
> The CTF information is needed by DTrace.
> My guess is that it will run ctfconvert on itself so it should be
> there from a prior install or it is part of some early toolchain
> stuff.
>


More information about the freebsd-hackers mailing list