From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
Wei Liu <wei.liu2@citrix.com>
Subject: Re: Xen EFI build system and gcov
Date: Tue, 30 Aug 2016 09:56:15 +0100 [thread overview]
Message-ID: <20160830085615.GF8502@citrix.com> (raw)
In-Reply-To: <57C56234020000780010A0E8@prv-mh.provo.novell.com>
On Tue, Aug 30, 2016 at 02:38:44AM -0600, Jan Beulich wrote:
> >>> On 29.08.16 at 20:41, <wei.liu2@citrix.com> wrote:
> > Hi Jan
> >
> > Today I had some free cycles so I spent some time looking at gcov
> > support in the hypervisor and tried to write a patch to fix the
> > currently broken gcov build. But my patch alone is not enough to fix
> > that.
> >
> > There seems to be a problem with the EFI Makefile. With my patch
> > applied, efi/boot.init.o still gets all gcov options _and_
> > -DINIT_SECTIONS_ONLY. See output and patch for more context.
> >
> > If I force efi to be disabled by putting in a hack into efi/Makefile,
> > Xen builds fine. It suggests for all other files my patch works.
> >
> > I am confused why efi/boot.init.o gets both set of options and I'm not
> > sure what is the best approach to fix it.
>
> That's a result of
>
> stub.o: $(extra-y)
>
> since ...
>
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -115,7 +115,9 @@ subdir-all := $(subdir-y) $(subdir-n)
> >
> > $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS +=
> > -DINIT_SECTIONS_ONLY
> >
> > -$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> > +ifeq ($(coverage),y)
> > +$(filter-out %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> > +endif
>
> ... such constructs apply to the target as well as all of its prereqs.
Right. Thanks for the explanation.
> Since the stub.o. dependency can't be eliminated easily (or else all
> the objects listed in extra-y won't get built anymore), perhaps you
> simply need to exclude stub.o from being compiler with coverage
> options as well. Since it might well be that other exceptions become
> necessary going forward, how about you introduce a nogcov-y
> variable (subject to name improvement of course) and include that
> in the $(filter-out ) above? This
>
> --- unstable.orig/xen/Rules.mk
> +++ unstable/xen/Rules.mk
> @@ -115,7 +115,9 @@ subdir-all := $(subdir-y) $(subdir-n)
>
> $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += -DINIT_SECTIONS_ONLY
>
> -$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> +ifeq ($(coverage),y)
> +$(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> +endif
>
> ifeq ($(lto),y)
> # Would like to handle all object files as bitcode, but objects made from
> --- unstable.orig/xen/arch/x86/efi/Makefile
> +++ unstable/xen/arch/x86/efi/Makefile
> @@ -15,3 +15,4 @@ extra-$(efi) += boot.init.o relocs-dummy
> $(OBJCOPY) -I ihex -O binary $< $@
>
> stub.o: $(extra-y)
> +nogcov-$(efi) := stub.o
>
>
> works for me (albeit there's then a significant number of duplicate
> symbol names getting warned about, which may be a separate thing
> in need of taking care of).
>
FWIW I also investigated how Linux does this. It has a rather
complex system for generating Makefile rules, but in the end it still
requires developers to manually mark which portion (either directory or
files) of the kernel can't be built with gcov.
So I think your approach is fine. I will incorporate your change to my
patch and stick your SoB in too.
Wei.
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-08-30 8:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 18:41 Xen EFI build system and gcov Wei Liu
2016-08-30 8:38 ` Jan Beulich
2016-08-30 8:56 ` Wei Liu [this message]
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=20160830085615.GF8502@citrix.com \
--to=wei.liu2@citrix.com \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/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).