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

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

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:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a5a4ce3c3c0ee

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 
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-MP
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
https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
because they aren't actually referenced from a .PHONY: rule.

Neither are they "empty recipes", as described further in
https://www.gnu.org/software/make/manual/html_node/Empty-Recipes.html
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 
https://www.gnu.org/software/make/manual/html_node/Multiple-Rules.html
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:
foo.c:#include "foo.h"
foo.c:
foo.c:int main(void)
foo.c:{
foo.c:  printf(HELLO);
foo.c:  return 0;
foo.c:}
foo.h.orig:#define HELLO "Hello World!"
Makefile:#.PHONY: foo.h
Makefile:
Makefile:foo: foo.h foo.c
Makefile:       $(CC) -o foo foo.c
Makefile:
Makefile:%.h: %.h.orig
Makefile:       cp $< $@
Makefile:
Makefile:foo.h:
 $ 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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel