[llvm-dev] lld-link fails to link 32bits assembly functions but 64bits pass (original) (raw)

Shi, Steven via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 18 06:54:34 PST 2019

Hi Martin, OK, It was my fault. I didn't set correct target when run the preprocess. Thank you very much!

Thanks Steven

-----Original Message----- From: Martin Storsjö [mailto:martin at martin.st] Sent: Monday, February 18, 2019 5:07 PM To: Shi, Steven <steven.shi at intel.com> Cc: Rui Ueyama <ruiu at google.com>; 'Peter Smith' <peter.smith at linaro.org>; 'llvm-dev at lists.llvm.org' <llvm-_ _dev at lists.llvm.org>; Gao, Liming <liming.gao at intel.com> Subject: RE: [llvm-dev] lld-link fails to link 32bits assembly functions but 64bits pass

On Mon, 18 Feb 2019, Shi, Steven wrote: > Hi Martin, > Thank you for the hint. > >> For 32 bit windows, functions with cdecl calling convention (the default >> in C) are decorated with an underscore prefix. So you'd need to update >> your nasm source file to define the symbol Foo instead of Foo. (Most >> assembly files use some sort of macro for wrapping this detail.) > Yes, my assembly files do use prefix macro (ASMPFX) for wrapping the > underscore. We use the USERLABELPREFIX to control the prefix macro > expand to be "" as below. I find the USERLABELPREFIX has been > predefined by clang-cl, but it is defined as nothing. That is why my > prefix macro expands to be nothing. Do you know why the clang-cl > predefines the USERLABELPREFIX as nothing? It looks to me like USERLABELPREFIX is properly defined to an underscore when preprocessing with clang-cl: $ cat userprefix.c USERLABELPREFIX $ bin/clang-cl -E userprefix.c -m32 # 1 "userprefix.c" # 1 "" 1 # 1 "" 3 # 331 "" 3 # 1 "" 1 # 1 "" 2 # 1 "userprefix.c" 2

$ bin/clang-cl -E userprefix.c # 1 "userprefix.c" # 1 "" 1 # 1 "" 3 # 334 "" 3 # 1 "" 1 # 1 "" 2 # 1 "userprefix.c" 2

$ So as long as I specify a x86 32 bit target, USERLABELPREFIX expands correctly to an underscore. Where do you observe differing behaviour? If you use (clang-)cl to preprocess your assembler files, you need make sure you run that preprocessor with the right target. // Martin

More information about the llvm-dev mailing list