From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SALAz-0004BF-8w for qemu-devel@nongnu.org; Wed, 21 Mar 2012 09:02:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SALAt-0005HW-06 for qemu-devel@nongnu.org; Wed, 21 Mar 2012 09:02:04 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53166 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SALAs-0005HL-Nb for qemu-devel@nongnu.org; Wed, 21 Mar 2012 09:01:58 -0400 Message-ID: <4F69D142.7020307@suse.de> Date: Wed, 21 Mar 2012 14:01:54 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <4F69B137.3070709@nowonline.co.uk> In-Reply-To: <4F69B137.3070709@nowonline.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Thoughts around dtrace linking... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lee Essen Cc: qemu-devel@nongnu.org, Stefan Hajnoczi 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. >=20 > The easiest way to do this is just prior to linking the binary, so > something like this (in rules.mak): >=20 > LINK =3D $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) > $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS)," LINK $(TARGET_DIR)$@") >=20 > DTRACE =3D $(call quiet-command,dtrace $(CONFIG_DTRACE_FLAGS) -o > $(1)-dtrace.o -G -s $(2) $(3), " GEN $(TARGET_DIR)$(1)-dtrace.o") >=20 > %$(EXESUF): %.o > $(call DTRACE,$*,trace-dtrace.dtrace,$^) > $(call LINK,$^ $*-dtrace.o) >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg