qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Lee Essen <lee.essen@nowonline.co.uk>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Thoughts around dtrace linking...
Date: Wed, 21 Mar 2012 14:01:54 +0100	[thread overview]
Message-ID: <4F69D142.7020307@suse.de> (raw)
In-Reply-To: <4F69B137.3070709@nowonline.co.uk>

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	other threads:[~2012-03-21 13:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-21 10:45 [Qemu-devel] Thoughts around dtrace linking Lee Essen
2012-03-21 13:01 ` Andreas Färber [this message]
2012-03-21 13:37   ` Lee Essen
2012-03-22 16:28   ` Stefan Hajnoczi
2012-03-22 17:00     ` Lee Essen
2012-03-23  8:08       ` Stefan Hajnoczi
2012-03-23 14:11         ` Lee Essen
2012-03-26 10:14           ` Stefan Hajnoczi
2012-03-26 15:28             ` Lee Essen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F69D142.7020307@suse.de \
    --to=afaerber@suse.de \
    --cc=lee.essen@nowonline.co.uk \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).