arm64/crypto: fix makefile rule for aes-glue-%.o

PATCH In review Andreas Schwab 3 participants 19 messages Jun 30, 2014 – Jul 28, 2014

Subsystems (2)

Crypto API arm64

lore

Share & tools

lore

Andreas Schwab

author

2014-06-30 13:14 UTC #0 lore raw

PATCH 1/1 arm64/crypto: fix makefile rule for aes-glue-%.o

This fixes the following build failure:

CC [M] arch/arm64/crypto/aes-glue-ce.o
ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory scripts/Makefile.build:393: recipe for target 'arch/arm64/crypto/aes-ce-blk.o' failed make[1]: *** [arch/arm64/crypto/aes-ce-blk.o] Error 1
Makefile:893: recipe for target 'arch/arm64/crypto' failed
make: *** [arch/arm64/crypto] Error 2

The $(obj)/aes-glue-%.o rule only creates $(obj)/.tmp_aes-glue-ce.o, it should use if_changed_rule instead of if_changed_dep.

Signed-off-by Andreas Schwab <[email protected]>

---
 arch/arm64/crypto/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/crypto/Makefile +1 -1

index 2070a56..a3f935f 100644
@@ -35,4 +35,4 @@ AFLAGS_aes-neon.o	:= -DINTERLEAVE=4
 CFLAGS_aes-glue-ce.o	:= -DUSE_V8_CRYPTO_EXTENSIONS
 
 $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
-	$(call if_changed_dep,cc_o_c)
+	$(call if_changed_rule,cc_o_c)

Signature · 6 lines

2.0.1

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Ard Biesheuvel

2014-06-30 13:38 UTC #1 lore raw

Quoted 9 lines · Andreas Schwab

This fixes the following build failure:
CC [M] arch/arm64/crypto/aes-glue-ce.o
ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory scripts/Makefile.build:393: recipe for target 'arch/arm64/crypto/aes-ce-blk.o' failed make[1]: *** [arch/arm64/crypto/aes-ce-blk.o] Error 1
Makefile:893: recipe for target 'arch/arm64/crypto' failed
make: *** [arch/arm64/crypto] Error 2

Quoted 3 lines

The $(obj)/aes-glue-%.o rule only creates $(obj)/.tmp_aes-glue-ce.o, it should use if_changed_rule instead of if_changed_dep.

Oops, my bad

Out of curiosity, how did you trigger this failure? I have build this code numerous times (and so have others) and I have never seen this failure.

Signature · 1 line

Ard.

Quoted 27 lines

Signed-off-by Andreas Schwab <[email protected]>
---
 arch/arm64/crypto/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/crypto/Makefile +1 -2
index 2070a56..a3f935f 100644
@@ -35,4 +35,4 @@ AFLAGS_aes-neon.o     := -DINTERLEAVE=4
 CFLAGS_aes-glue-ce.o   := -DUSE_V8_CRYPTO_EXTENSIONS
 
 $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
-       $(call if_changed_dep,cc_o_c)
+       $(call if_changed_rule,cc_o_c)
--
2.0.1
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Andreas Schwab

author

2014-06-30 13:56 UTC #2 lore raw

Quoted 3 lines · Ard Biesheuvel

Out of curiosity, how did you trigger this failure? I have build this code numerous times (and so have others) and I have never seen this failure.

Did you ever start with a clean tree?

Andreas.

Signature · 3 lines

Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Ard Biesheuvel

2014-06-30 14:08 UTC #3 lore raw

Quoted 8 lines · Andreas Schwab

Quoted 3 lines · Ard Biesheuvel
Out of curiosity, how did you trigger this failure? I have build this code numerous times (and so have others) and I have never seen this failure.
Did you ever start with a clean tree?

Yep, building both in-tree and out-of-tree, no trouble at all.

Signature · 1 line

Ard.

Andreas Schwab

author

2014-07-24 12:29 UTC #4 lore raw

Quoted 11 lines · Ard Biesheuvel

Quoted 8 lines · Andreas Schwab
Quoted 3 lines · Ard Biesheuvel
Out of curiosity, how did you trigger this failure? I have build this code numerous times (and so have others) and I have never seen this failure.
Did you ever start with a clean tree?
Yep, building both in-tree and out-of-tree, no trouble at all.

So you probably didn't configure them as modules.

Andreas.

Signature · 3 lines

Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Ard Biesheuvel

2014-07-24 12:35 UTC #5 lore raw

Quoted 9 lines · Andreas Schwab

Quoted 7 lines · Ard Biesheuvel
Quoted 6 lines · Andreas Schwab
Quoted 3 lines · Ard Biesheuvel
Out of curiosity, how did you trigger this failure? I have build this code numerous times (and so have others) and I have never seen this failure.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
Did you ever start with a clean tree?
Yep, building both in-tree and out-of-tree, no trouble at all.
So you probably didn't configure them as modules.

Yes, all the time, in fact. They have now been added as built-ins to the defconfig, but I always build as modules, because it is far easier when developing.

Ard Biesheuvel

2014-07-24 12:53 UTC #6 lore raw

Quoted 13 lines · Ard Biesheuvel

Quoted 12 lines · Andreas Schwab
Quoted 10 lines · Ard Biesheuvel
Quoted 8 lines · Andreas Schwab
Quoted 3 lines · Ard Biesheuvel
Out of curiosity, how did you trigger this failure? I have build this code numerous times (and so have others) and I have never seen this failure.
Did you ever start with a clean tree?

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
Yep, building both in-tree and out-of-tree, no trouble at all.
So you probably didn't configure them as modules.
Yes, all the time, in fact. They have now been added as built-ins to the defconfig, but I always build as modules, because it is far easier when developing.

Also, looking into this a bit more, in my case I do see arch/arm64/crypto/.aes-glue-ce.o.cmd containing the command line and the full set of include/config/... rules that are used to track dependencies on the configuration.

So what strikes me as odd is this:

Quoted 2 lines

CC [M] arch/arm64/crypto/aes-glue-ce.o
ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory

so it seems make is perfectly happy to create the aes-glue-ce.o file, but the subsequent ld that uses it as input cannot find it. Perhaps the dependencies are screwed up elsewehere?

Are there any other circumstances of interest? How many threads are you building in parallel? Other steps to reproduce?

Signature · 1 line

Ard.

Andreas Schwab

author

2014-07-24 13:26 UTC #7 lore raw

You are not using CONFIG_MODVERSIONS.

Andreas.

Signature · 3 lines

Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Ard Biesheuvel

2014-07-24 13:29 UTC #8 lore raw

Quoted 2 lines · Andreas Schwab

You are not using CONFIG_MODVERSIONS.

I am

Andreas Schwab

author

2014-07-24 13:40 UTC #9 lore raw

Quoted 5 lines · Ard Biesheuvel

Quoted 2 lines · Andreas Schwab
You are not using CONFIG_MODVERSIONS.
I am

No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.

Andreas.

Signature · 3 lines

Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Ard Biesheuvel

2014-07-24 14:18 UTC #10 lore raw

Quoted 11 lines · Andreas Schwab

Quoted 5 lines · Ard Biesheuvel
Quoted 2 lines · Andreas Schwab
You are not using CONFIG_MODVERSIONS.
I am
No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.

OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. But I am still not seeing the error you are seeing, strangely enough.

Ard Biesheuvel

Acked-by

2014-07-24 14:24 UTC #11 lore raw

Quoted 7 lines · Ard Biesheuvel

Quoted 6 lines · Andreas Schwab
Quoted 4 lines · Ard Biesheuvel
Quoted 2 lines · Andreas Schwab
You are not using CONFIG_MODVERSIONS.

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
I am
No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.
OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. But I am still not seeing the error you are seeing, strangely enough.

OK, now I am seeing it.

Acked-by Ard Biesheuvel <[email protected]>

Thanks for your patience.

Signature · 1 line

Ard.

Sam Ravnborg

2014-07-24 16:12 UTC #12 lore raw

Quoted 14 lines · Ard Biesheuvel

Quoted 13 lines · Ard Biesheuvel
Quoted 11 lines · Andreas Schwab
Quoted 5 lines · Ard Biesheuvel
Quoted 2 lines · Andreas Schwab
You are not using CONFIG_MODVERSIONS.
I am
No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.

Quoted 6 lines

Quoted 2 lines
OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. But I am still not seeing the error you are seeing, strangely enough.
OK, now I am seeing it.
Acked-by Ard Biesheuvel <[email protected]>

Jumping in the end of the thread here - sorry for that.

Another way to solve this would be to create two
small wrapper files:
aes-glue-neon.c - which include aes-glue.c
aes-glue-ce.c that include aes-glue.c

Then you could use standard kbuild support for building your module. And we will not potentially break it when we change cc_o_c in the near future.

Sam

Ard Biesheuvel

2014-07-24 19:25 UTC #13 lore raw

Quoted 15 lines · Sam Ravnborg

Quoted 14 lines · Ard Biesheuvel
Quoted 13 lines · Ard Biesheuvel
Quoted 11 lines · Andreas Schwab
Quoted 5 lines · Ard Biesheuvel
Quoted 2 lines · Andreas Schwab
You are not using CONFIG_MODVERSIONS.
I am
No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.

Quoted 9 lines

Quoted 6 lines
Quoted 2 lines
OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. But I am still not seeing the error you are seeing, strangely enough.
OK, now I am seeing it.
Acked-by Ard Biesheuvel <[email protected]>
Jumping in the end of the thread here - sorry for that.

No worries

Quoted 8 lines

Another way to solve this would be to create two
small wrapper files:
aes-glue-neon.c - which include aes-glue.c
aes-glue-ce.c that include aes-glue.c
Then you could use standard kbuild support for building your module. And we will not potentially break it when we change cc_o_c in the near future.

I see how that would fix this issue, but frankly, if we need to add .c files that only #include other .c files to support building multiple objects from a single .c file, I think the flaw is in the build system, and I would rather fix the build system instead.

Cheers,
Ard.

Sam Ravnborg

2014-07-24 20:45 UTC #14 lore raw

Quoted 33 lines · Ard Biesheuvel

Quoted 15 lines · Sam Ravnborg
Quoted 14 lines · Ard Biesheuvel
Quoted 13 lines · Ard Biesheuvel
Quoted 11 lines · Andreas Schwab
Quoted 5 lines · Ard Biesheuvel
Quoted 2 lines · Andreas Schwab
You are not using CONFIG_MODVERSIONS.
I am
No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. But I am still not seeing the error you are seeing, strangely enough.
OK, now I am seeing it.
Acked-by Ard Biesheuvel <[email protected]>
Jumping in the end of the thread here - sorry for that.
No worries
Quoted 5 lines
Another way to solve this would be to create two
small wrapper files:
aes-glue-neon.c - which include aes-glue.c
aes-glue-ce.c that include aes-glue.c

Quoted 8 lines

Quoted 3 lines
Then you could use standard kbuild support for building your module. And we will not potentially break it when we change cc_o_c in the near future.
I see how that would fix this issue, but frankly, if we need to add .c files that only #include other .c files to support building multiple objects from a single .c file, I think the flaw is in the build system, and I would rather fix the build system instead.

The kbuild syntax could be extended to allow building multiple .o files from a single .c file. But the need for this feature is so seldom that people would not recognize the syntax most likely.

Btw. the current solution is already faulty - even with the fix. There are no support for make C=2 arch/.../crypto/

Therefore - for now the correct fix is to use two wrapper .c files, and accept this. It will not have the C=2 problem above.

Sam

Ard Biesheuvel

2014-07-25 06:28 UTC #15 lore raw

Quoted 38 lines · Sam Ravnborg

Quoted 37 lines · Ard Biesheuvel
Quoted 15 lines · Sam Ravnborg
Quoted 14 lines · Ard Biesheuvel
Quoted 13 lines · Ard Biesheuvel
Quoted 11 lines · Andreas Schwab
Quoted 5 lines · Ard Biesheuvel
Quoted 2 lines · Andreas Schwab
You are not using CONFIG_MODVERSIONS.
I am
No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. But I am still not seeing the error you are seeing, strangely enough.
OK, now I am seeing it.
Acked-by Ard Biesheuvel <[email protected]>
Jumping in the end of the thread here - sorry for that.
No worries
Quoted 8 lines
Another way to solve this would be to create two
small wrapper files:
aes-glue-neon.c - which include aes-glue.c
aes-glue-ce.c that include aes-glue.c
Then you could use standard kbuild support for building your module. And we will not potentially break it when we change cc_o_c in the near future.

Quoted 8 lines

Quoted 4 lines
I see how that would fix this issue, but frankly, if we need to add .c files that only #include other .c files to support building multiple objects from a single .c file, I think the flaw is in the build system, and I would rather fix the build system instead.
The kbuild syntax could be extended to allow building multiple .o files from a single .c file. But the need for this feature is so seldom that people would not recognize the syntax most likely.

True

Quoted 3 lines

Btw. the current solution is already faulty - even with the fix. There are no support for make C=2 arch/.../crypto/

So can you elaborate on how it is faulty?

Quoted 4 lines

Therefore - for now the correct fix is to use two wrapper .c files, and accept this. It will not have the C=2 problem above.
Sam

Sam Ravnborg

2014-07-27 18:40 UTC #16 lore raw

Quoted 6 lines

Quoted 4 lines
Btw. the current solution is already faulty - even with the fix. There are no support for make C=2 arch/.../crypto/
So can you elaborate on how it is faulty?

When you run "make C=2 arch/.../crypto/" then sparse shall be run for all .c files also if they are already built.
But due to the re-implementation of some parts of the kbuild logic in the makefile this does not happen with the -glue file.

A minor detail - but this may not be the only wreckage we see over time.

Sam

Ard Biesheuvel

2014-07-28 17:00 UTC #17 lore raw

Quoted 5 lines · Sam Ravnborg

Quoted 5 lines
Quoted 4 lines
Btw. the current solution is already faulty - even with the fix. There are no support for make C=2 arch/.../crypto/

Quoted 9 lines

Quoted 1 line
So can you elaborate on how it is faulty?
When you run "make C=2 arch/.../crypto/" then sparse shall be run for all .c files also if they are already built.
But due to the re-implementation of some parts of the kbuild logic in the makefile this does not happen with the -glue file.
A minor detail - but this may not be the only wreckage we see over time.

I agree. Any suggestions for a generic way to solve this? Perhaps something like this in scripts/Makefile.build

template_rule = $(obj)/$(tmpl)%.c: $(src)/$(tmpl).c ; @cp $$(^) $$(@) $(eval $(foreach tmpl,$(TEMPLATES),$(template_rule)))

so that arch/arm64/crypto/Makefile only has to define

TEMPLATES += aes-glue

so that all dependencies on aes-glueXXX.c are satisfied by aes-glue.c?

BTW, while looking into this issue, I noticed something else that is strange:
after touch'ing sha1-ce-glue.c in arch/arm64/crypto and re-executing 'make V=2', this is what I get

make[1]: Entering directory `/home/ard/linux-arm64-build'
CHK include/config/kernel.release
Using /home/ard/linux-2.6 as source for kernel

  GEN     ./Makefile
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    /home/ard/linux-2.6/scripts/checksyscalls.sh - due to target missing
  CHK     include/generated/compile.h
  CC      arch/arm64/crypto/sha1-ce-glue.o - due to:
/home/ard/linux-2.6/arch/arm64/crypto/sha1-ce-glue.c
  LD      arch/arm64/crypto/sha1-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o
  LD      arch/arm64/crypto/sha2-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o
  LD      arch/arm64/crypto/ghash-ce.o - due to:

arch/arm64/crypto/sha1-ce-glue.o
LD arch/arm64/crypto/aes-ce-ccm.o - due to:
arch/arm64/crypto/sha1-ce-glue.o
LD arch/arm64/crypto/built-in.o - due to:
arch/arm64/crypto/sha1-ce.o arch/arm64/crypto/sha2-ce.o arch/arm64/crypto/ghash-ce.o arch/arm64/crypto/aes-ce-ccm.o
CHK kernel/config_data.h
LINK vmlinux - due to: arch/arm64/crypto/built-in.o

IOW, unrelated object files are detected as being out of date. (This is after running make mrproper, and with the aes-glue-% related rules and definitions commented out, just to make sure this is not related to the issue you have identified)

Any ideas?

Signature · 1 line

Ard.

Sam Ravnborg

2014-07-28 19:06 UTC #18 lore raw

Quoted 13 lines · Ard Biesheuvel

Quoted 12 lines · Sam Ravnborg
Quoted 6 lines
Quoted 4 lines
Btw. the current solution is already faulty - even with the fix. There are no support for make C=2 arch/.../crypto/
So can you elaborate on how it is faulty?
When you run "make C=2 arch/.../crypto/" then sparse shall be run for all .c files also if they are already built.
But due to the re-implementation of some parts of the kbuild logic in the makefile this does not happen with the -glue file.

Quoted 4 lines

Quoted 2 lines
A minor detail - but this may not be the only wreckage we see over time.
I agree. Any suggestions for a generic way to solve this?

Yes - two small .c file that each include the same glue file. Anything else is over-engineering.

Quoted 17 lines

BTW, while looking into this issue, I noticed something else that is strange:
after touch'ing sha1-ce-glue.c in arch/arm64/crypto and re-executing 'make V=2', this is what I get
make[1]: Entering directory `/home/ard/linux-arm64-build'
CHK include/config/kernel.release
Using /home/ard/linux-2.6 as source for kernel
  GEN     ./Makefile
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    /home/ard/linux-2.6/scripts/checksyscalls.sh - due to target missing
  CHK     include/generated/compile.h
  CC      arch/arm64/crypto/sha1-ce-glue.o - due to:
/home/ard/linux-2.6/arch/arm64/crypto/sha1-ce-glue.c
  LD      arch/arm64/crypto/sha1-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o
  LD      arch/arm64/crypto/sha2-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o
  LD      arch/arm64/crypto/ghash-ce.o - due to:

Quoted 8 lines

arch/arm64/crypto/sha1-ce-glue.o
LD arch/arm64/crypto/aes-ce-ccm.o - due to:
arch/arm64/crypto/sha1-ce-glue.o
LD arch/arm64/crypto/built-in.o - due to:
arch/arm64/crypto/sha1-ce.o arch/arm64/crypto/sha2-ce.o arch/arm64/crypto/ghash-ce.o arch/arm64/crypto/aes-ce-ccm.o
CHK kernel/config_data.h
LINK vmlinux - due to: arch/arm64/crypto/built-in.o

Just from inspecting the above I have no idea. And I have no arm64 toolchain installed to test myself.

So for now no clue - sorry.

Sam