qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Färber
Subject: Re: [Qemu-devel] Thoughts around dtrace linking...
Date: Wed, 21 Mar 2012 14:01:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2

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)
> 
> 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),
b) the additional .o file depends on its input .o files, so must be
unique per executable.
This seems to be guaranteed when doing it at rules.mak level. Haven't
checked all the variables being passed back and forth here yet though; I
really am not comfortable reviewing code that's HTML-formatted in my
mailer. ;)

> How compatible is this with FreeBSD - it doesn't sound like it's needed
> at all?

Don't know about FreeBSD but on Darwin that step is indeed not needed or
supported, so needs to be guarded.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]