Re: [Qemu-devel] Thoughts around dtrace linking...

[Lee Essen]

On 22/03/2012 16:28, Stefan Hajnoczi wrote:
> On Wed, Mar 21, 2012 at 1:01 PM, Andreas Färber<address@hidden>  wrote:
> > Hi,
> >
> > Am 21.03.2012 11:45, schrieb Lee Essen:
> > > I've been trying to find a sensible way to solve the Solaris/Illumos
> > > dtrace requirement to pass all the objs to the dtrace command so that
> > > the resultant object file contains all the symbols needed to properly
> > > link the relevant binary.
> > >
> > > The easiest way to do this is just prior to linking the binary, so
> > > something like this (in rules.mak):
> > >
> > >      LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS)
> > >      $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS),"  LINK  $(TARGET_DIR)$@")
> > >
> > >      DTRACE = $(call quiet-command,dtrace $(CONFIG_DTRACE_FLAGS) -o
> > >      $(1)-dtrace.o -G -s $(2) $(3), "  GEN $(TARGET_DIR)$(1)-dtrace.o")
> > >
> > >      %$(EXESUF): %.o
> > >        $(call DTRACE,$*,trace-dtrace.dtrace,$^)
> > >        $(call LINK,$^ $*-dtrace.o)
>
> What I find slightly surprising is that you're putting the -dtrace.o
> generation step as a command in the executable's target.
>
> I would expect the -dtrace.o to be a target itself, which also allows
> make to use it's timestamping on dependencies to ensure we only
> rebuild when necessary.  i.e. specifying dependencies is the make way
> of doing things, and I think we should try where possible.

Yes, that's the way I had it the first time around, but it means quite a 
bit more complexity in the makefiles and having to touch each executable 
section, I had thought the rules.mak approach was cleaner.

For example:

qemu-ga-all-objs=qemu-ga.o $(qga-obj-y) $(tools-obj-y) $(qapi-obj-y) 
$(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ)
#ifdef USE_SOLARIS_DTRACE_APPROACH
qemu-ga.dtrace.o: $(qemu-ga-all-objs)  [assuming rule in rules.mak]

qemu-ga-all-objs+=qemu-ga.dtrace.o
#endif
qemu-ga$(EXESUF): qemu-ga-all-objs

There's also a complication with the creation of the .dtrace.o in 
Makefile.target because of it being one level down in the directory 
structure and needing access to trace-dtrace.dtrace.

None of it is unsurmountable, but it gets a bit untidy.

TBH, I can do this either way, just let me know which approach you 
prefer and I'll put a patch together.

> > > Obviously with the relevant tests around it to check the trace backend,
> > > and also an adjustment in Makefile.target to cause the right thing to
> > > happen for each target.
> > > Or, is there a better way?
> >
> > The two issues I see (as info for Stefan et al.) are
> > a) compiling DTrace probes into .o files requires linking those objects
> > with that additional .o file to avoid linker errors (even for tools
> > where using DTrace probes does not seem to make much sense),
>
> qemu-tool binaries are built with tracing enabled.  But this is a good
> point, we need to check that all binaries buildable from the QEMU
> source tree continue to work with this change.

Actually this is a good point ... if you are thinking of removing 
tracing from some of the binaries then the rules.mak approach doesn't 
really make sense.

Let me know how you want to proceed.

Cheers,

Lee.