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<afaer...@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