Assemby instruction does not assemble correctly with LLVM 13(vanilla, not Apple fork) on macOS/Apple M1

[crazyquark]

Hi,

We are building LLVM 13 from sources on macOS - arm64 on an Apple M1 computer(from the official repo, not Apple's fork) and building systemc with the resulting compiler. This leads to an unusual situation: (running nm -m on the resulting lib)

libsystemc.a(aarch64.s.o):
0000000000000010 (__TEXT,__text) external _qt_abort
0000000000000078 (__TEXT,__text) external _qt_align
0000000000000010 (__TEXT,__text) external _qt_block
0000000000000010 (__TEXT,__text) external _qt_blocki
0000000000000000 (__TEXT,__text) external _qt_start
                 (indirect) non-external br (for qt_error)
0000000000000000 (__TEXT,__text) non-external ltmp0
0000000000000010 (__TEXT,__text) external qt_abort
0000000000000078 (__TEXT,__text) external qt_align
0000000000000010 (__TEXT,__text) external qt_block
0000000000000010 (__TEXT,__text) external qt_blocki
                 (undefined) external qt_error

As you can see it erroneously generates a br indirect symbol - which led lld to report it cannot handle N_INDR symbols when linking the above lib. If I change this code: https://github.com/accellera-official/systemc/blob/master/src/sysc/packages/qt/md/aarch64.s#L26 from br =qt_error to

ldr x28, =qt_error
br x28

or just: b qt_error then the error goes away. I suspect the br instruction is misused as it should be used with a register and not an address/label. P.S. Another issue is that qt_error is actually exported as _qt_error by the linker when cmake is used to build.

[ahmedsamiruci]

@crazyquark Did you success in supporting M1 processors?

[crazyquark]

@ahmedsamiruci yes, I had to use some preprocessor magic on that assembly file to use different code when the compiler is clang.

[maehne]

@pah: Could you maybe have a look on this issue?

[lmailletcontoz]

Included in SystemC 3.0.0 release