clang: Inline assembly for declaration of global symbol for arm64 |
||||
Issue description
The inline assembly used in crypto/sha2-ce-glue.c of the v4.4 Linux kernel to export a symbol is not compatible with clang:
#define ASM_EXPORT(sym, val) \
asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
http://lxr.free-electrons.com/source/arch/arm64/crypto/sha2-ce-glue.c?v=4.4#L20
With the upstream maintainers we initially agreed to use the following instead:
#define ASM_EXPORT(sym, val) \
asm(".globl " #sym "; .set " #sym ", %c0" :: "i"(val));
This seemed to work with gcc and clang, however it turned out that it doesn't work with older gcc versions (e.g. gcc v4.8):
https://www.spinics.net/lists/arm-kernel/msg576704.html
We need a construct compatible with both gcc and clang, or make clang support the original code.
,
Apr 21 2017
> any particular reason we are marking these with restrict-view-google? No other reason than mirroring the restriction of the 'parent' Issue 690756.
,
Apr 21 2017
ok, if we remove the restrict-view-google we can share it with ARM. I think it should be ok to do that.
,
Apr 21 2017
,
Apr 29 2017
Arm reply - This is my analysis and understanding of the situation: The ARMARM specifies that the correct AArch64 instruction assembly syntax is to have a hash sign (#) before an immediate. Therefore, every time an inline assembly constraint is used that specifies to print an immediate (like 'i' or 'I'), the immediate (e.g. 42) should be printed with the hash (e.g. #42). Therefore, if you're using an immediate constraint where the hash sign must not be printed, as in your example below, you have to use the "c" operand modifier. The "c" operand modifier apparently got introduced to gcc after the 4.8 release. The binutils assembler and the clang integrated assembler accept immediates without the hash sign as a non-official extension. Some of the immediate constraints on gcc seem to not print out the hash sign either; which is why the variant in the v4.4 linux kernel you quoted below works with gcc. In summary, it seems to me that the inline assembly with the %c0 operand is the correct one and gcc 4.8 is simply too old to support this. I don't have a good feel for your project goals and dependencies. Neither do I have a good feel for what is acceptable to the linux kernel community. Therefore, I'm afraid I can't give advice on what the best way would be to work around this. I hope the explanation above at least helps to find the best work around. Thanks, Kristof -
,
May 1 2017
The author of the driver reworked the code to not need inline assembly for the global symbol: https://www.spinics.net/lists/linux-crypto/msg25555.html The change hasn't been applied yet by the maintainer, but I expect it to be accepted.
,
May 19 2017
The change has been integrated by the maintainer
,
Jun 3 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by llozano@chromium.org
, Apr 21 2017Owner: manojgupta@chromium.org