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

Re: [Xen-devel] [PATCH] Add -MP to CFLAGS along with -MMD.

On Tue, 2020-03-17 at 16:59 +0000, Ian Jackson wrote:
> David Woodhouse writes ("Re: [PATCH] Add -MP to CFLAGS along with -MMD."):
> > On Tue, 2020-03-17 at 15:52 +0100, Jan Beulich wrote:
> > > On 17.03.2020 15:34, David Woodhouse wrote:
> > > > From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> > > > 
> > > > This causes gcc (yes, and clang) to emit phony targets for each 
> > > > dependency.
> > > > 
> > > > This means that when a header file is deleted, the C files which *used*
> > > > to include it will no longer stop building with bogus out-of-date
> > > > dependencies like this:
> > > > 
> > > >    make[5]: *** No rule to make target
> > > >    '/home/dwmw2/git/xen/xen/include/asm/hvm/svm/amd-iommu-proto.h',
> > > >    needed by 'p2m.o'. Stop.
> > > 
> > > In principle this would be nice, but there must be a reason this isn't
> > > the default behavior. As the workaround for the issue at hand is quite
> > > simple, I wouldn't like to treat addressing this one by some other
> > > anomaly/quirk. Do you (or does anyone else) have insight into why this
> > > isn't default behavior?
> > 
> > No.
> I think this answer is:
> I think it could interfere with other rules intended to build (or
> rebuild) .h files.  This is particularly true for pattern or suffix
> rules.  I would have to RTFM properly and think about it to understand
> all the implications, to know what kind of nontrivial .h-rebuilding
> rules might be affected (and therefore, to know whether we have any
> such rules).

OK... I have attempted to address my frustration in a more coherent and
hopefully productive way (qv), rather than resorting to monosyllabic
responses. Apologies for that.

Back to the specifics of this patch...

GCC has had -MD support since so far back that I can't even find its
origin in the git history. The SVN conversion seems kind of broken but
I see signs of -MD having existed as far back as 1992.

The -MP support, adding 'phony targets' for the headers listed in the
-MD output, wasn't added until 2001:

It seems hardly surprising that the new behaviour was an additional
option to GCC instead of retroactively changing the default which had
already existed for around a decade. I do not think that questioning
the (understandably conservative) default behaviour of GCC is
appropriate or relevant in a review of a Xen patch such as this.

As it happens, the GCC documentation at 
is slightly wrong. It refers to these as 'phony targets' but they aren't really 
'phony targets' in the sense referred to in make docs at
because they aren't actually referenced from a .PHONY: rule.

Neither are they "empty recipes", as described further in
because empty recipes, well, aren't actually empty. Those would perhaps
more accurately be called "no-op recipes" because, like the example
there containing a single semicolon, they do nothing.

Both actual phony targets, and so-called empty recipes, do have the
effect of overriding implicit and pattern rules for the target in
question — they could mess up auto-generated header files, for example.

But what GCC -MP emits, despite its documentation, is neither of those
things. It merely emits an empty rule with no recipe and no actual
dependencies either. I don't think there's a specific term for that; it
*isn't* a 'phony rule', as I said.

It's probably best described as 'an explict rule without a recipe'.See 
where it states that

        'If none of the explicit rules for a target has a recipe, then 
         make searches for an applicable implicit rule to find one
         see Using Implicit Rules).'

So no, I don't think using -MP is going to break our handling of auto-
generated header files, but we'd have known that from a trivial
empirical build test within seconds, wouldn't we?

Here's another cut down test case. You can experiment with turning it
into a *real* 'phony rule', etc...

 $ grep ^ *
foo.c:#include <stdio.h>
foo.c:#include "foo.h"
foo.c:int main(void)
foo.c:  printf(HELLO);
foo.c:  return 0;
foo.h.orig:#define HELLO "Hello World!"
Makefile:#.PHONY: foo.h
Makefile:foo: foo.h foo.c
Makefile:       $(CC) -o foo foo.c
Makefile:%.h: %.h.orig
Makefile:       cp $< $@
 $ make foo
cp foo.h.orig foo.h
cc -o foo foo.c

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.