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

[Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>]

On Thu, Mar 22, 2012 at 05:00:53PM +0000, Lee Essen wrote:
> On 22/03/2012 16:28, Stefan Hajnoczi wrote:
> >On Wed, Mar 21, 2012 at 1:01 PM, Andreas Färber<afaerber@suse.de>  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.

If you're able to try out the dependency-based approach that would be a
good starting point.  You may hit a point where it turns out to be too
ugly or complicated - in that case, please post your progress and maybe
someone can help find a way to structure it.  I'm not a make guru but I
can try to give feedback on your patches.

Stefan