Inline assembler in padlock.c is incompatible with LTO #312

New issue

Closed

opened 2019-11-01 14:54:50 -05:00 by StefanBruens · 1 comment

StefanBruens commented

2019-11-01 14:54:50 -05:00

(Migrated from github.com)

Description

When using LTO, the non-local label 'unsupported' may be instantiated several times in the traslation unit (which is the whole program with LTO typically). This leads to an error during linking:

[ 212s] ../../contrib/mbedtls/library/padlock.c: Assembler messages:
[ 212s] ../../contrib/mbedtls/library/padlock.c:64: Error: symbol `unsupported' is already defined
[ 212s] lto-wrapper: fatal error: cc returned 1 exit status
[ 212s] compilation terminated.
[ 212s] /usr/lib/gcc/i586-suse-linux/9/../../../../i586-suse-linux/bin/ld: error: lto-wrapper failed

github.com/ARMmbed/mbed-crypto@08c674dfe3/library/padlock.c (L61-L64)

This happens when compiling premake5, which statically links to a bundled mbedtls.

Only ix86 (32bit) is affected, as the padlock code is left out otherwise.

The problem can probably avoided by using local labels in the asm code, e.g.

jb 1f
movl  $0xC0000001, %%eax
cpuid
1:

or assembler templates, unsupported_%=:. A local label likely is the better option, as it avoids generating a globally visible symbol in the firs place.

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

### Description When using LTO, the non-local label 'unsupported' may be instantiated several times in the traslation unit (which is the whole program with LTO typically). This leads to an error during linking: [ 212s] ../../contrib/mbedtls/library/padlock.c: Assembler messages: [ 212s] ../../contrib/mbedtls/library/padlock.c:64: Error: symbol `unsupported' is already defined [ 212s] lto-wrapper: fatal error: cc returned 1 exit status [ 212s] compilation terminated. [ 212s] /usr/lib/gcc/i586-suse-linux/9/../../../../i586-suse-linux/bin/ld: error: lto-wrapper failed https://github.com/ARMmbed/mbed-crypto/blob/08c674dfe3e57932fe21e3feb3aebed680759c37/library/padlock.c#L61-L64 This happens when compiling premake5, which statically links to a bundled mbedtls. Only ix86 (32bit) is affected, as the padlock code is left out otherwise. The problem can probably avoided by using local labels in the asm code, e.g. ``` jb 1f movl $0xC0000001, %%eax cpuid 1: ``` or [assembler templates](https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#AssemblerTemplate), `unsupported_%=:`. A local label likely is the better option, as it avoids generating a globally visible symbol in the firs place.  ### Issue request type  [ ] Question [ ] Enhancement [X] Bug

gilles-peskine-arm commented

2023-05-24 14:00:51 -05:00

(Migrated from github.com)