Linker error with inline assembly: unable to translate instruction: call about llvm-mos

[mysterymath]

Can you try building this with -fcrash-diagnostics=all? This should produce automatically produce a reproducer directory that collects together all of the necessary inputs, along with a script to reproduce the crash.

Otherwise, I'll try installing the VSCode extension and so forth, but it's usually preferable to have smaller, self-contained reproducers for compiler issues whenever possible.

I took a stab at reproducing this in godbolt.org, but I couldn't produce a crash with just what was given. Something from the context may be causing this: https://godbolt.org/z/9Gv3xe7rP

[rolandshacks]

Will try asap.
I already tried a bit, and problems are going away when not using the "n" constraint.
Use case: using"n" for passing an uint16_t to be used as target address for JSR.
When using a void* together with "g" or "o", ... , it compiles, but code does not work. What would be the right way to use an uint16_t to pass an address to inline asm?

[rolandshacks]

Reproducing the problem might require two compilation units, one referencing another with extern ... ?

[rolandshacks]

This is how to reproduce:
---- main.cpp ----

extern const short ext_address; // defined outside this compilation unit
const short address = 0x1234;   // defined locally
int main(void) {
    asm volatile (
        "jsr %0\n"
        ::
        "n"(ext_address) // <-- fails with 'ext_address', works with 'address'
    );
    return 0;
}

--- data.cpp ---
extern const short ext_address = 0x1234;

[rolandshacks]

This is the produced compile_commands.json:

---

[
    {
        "directory": "C:/Users/Roland/AppData/Local/Programs/Microsoft VS Code",
        "arguments": [
            "--config",
            "mos-c64.cfg",
            "-o",
            "d:/Work/c64/newproject/build/data.o",
            "-c",
            "-std=gnu++20",
            "-g",
            "-fstandalone-debug",
            "-fno-limit-debug-info",
            "-fno-discard-value-names",
            "-fcrash-diagnostics=all",
            "-O0",
            "-DDEBUG",
            "-I",
            "d:/Work/c64/newproject",
            "-I",
            "C:/tools/llvm-mos/mos-platform/common/include",
            "-I",
            "C:/tools/llvm-mos/mos-platform/commodore/include",
            "-I",
            "C:/tools/llvm-mos/mos-platform/c64/include",
            "-I",
            "C:/tools/llvm-mos/lib/clang/16/include"
        ],
        "file": "d:/Work/c64/newproject/src/data.cpp"
    },
    {
        "directory": "C:/Users/Roland/AppData/Local/Programs/Microsoft VS Code",
        "arguments": [
            "--config",
            "mos-c64.cfg",
            "-o",
            "d:/Work/c64/newproject/build/main.o",
            "-c",
            "-std=gnu++20",
            "-g",
            "-fstandalone-debug",
            "-fno-limit-debug-info",
            "-fno-discard-value-names",
            "-fcrash-diagnostics=all",
            "-O0",
            "-DDEBUG",
            "-I",
            "d:/Work/c64/newproject",
            "-I",
            "C:/tools/llvm-mos/mos-platform/common/include",
            "-I",
            "C:/tools/llvm-mos/mos-platform/commodore/include",
            "-I",
            "C:/tools/llvm-mos/mos-platform/c64/include",
            "-I",
            "C:/tools/llvm-mos/lib/clang/16/include"
        ],
        "file": "d:/Work/c64/newproject/src/main.cpp"
    }
]

[rolandshacks]

Here is the stack dump on a Linux platform:

compiling /home/roland/work/c64/clangbug/src/main.cpp
compiling /home/roland/work/c64/clangbug/src/data.cpp
linking /home/roland/work/c64/clangbug/build/example.prg
LLVM ERROR: unable to translate instruction: call (in function: main)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/roland/llvm-mos/bin/ld.lld /home/roland/work/c64/clangbug/build/main.o /home/rola
nd/work/c64/clangbug/build/data.o -plugin-opt=O0 -plugin-opt=-crash-diagnostics-dir=/home/roland/work/c64/clangbug/build -mllvm -force-precise-rotation-cost -mllvm -jump-inst-cost=6 -mllvm -force-loop-cold-block -mllvm -phi-node-folding-threshold=0 -mllvm -two-entry-phi-node-folding-threshold=0 -mllvm -align-large-globals=false -mllvm -disable-spill-hoist -mllvm -lsr-complexity-limit=10000000 -mllvm 
-zp-avail=110 --gc-sections --sort-section=alignment -L/home/roland/llvm-mos/bin/../mos-platform/c64/lib -L/home/roland/llvm-mos/bin/../mos-platform/commodore/lib -L/home/roland/llvm-mos/bin/../mos-platform/common/lib -l:crt0.o -lcrt0 -lcrt -lc -Tlink.ld -o /home/roland/work/c64/clangbug/build/example.prg
1.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
2.      Running pass 'IRTranslator' on function '@main'
 #0 0x000056477531aa1b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/roland/llvm-mos/bin/ld.lld+0x762a1b)
 #1 0x0000564775319639 llvm::sys::RunSignalHandlers() (/home/roland/llvm-mos/bin/ld.lld+0x761639)
 #2 0x0000564775319e2a SignalHandler(int) Signals.cpp:0:0
 #3 0x00007fedc2be2520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #4 0x00007fedc2c36a7c pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x96a7c)
#5 0x00007fedc2be2476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #6 0x00007fedc2bc87f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
 #7 0x00005647752e0816 llvm::report_fatal_error(llvm::Twine const&, bool) (/home/roland/llvm-mos/bin/ld.lld+0x728816)
 #8 0x000056477580c12d reportTranslationError(llvm::MachineFunction&, llvm::TargetPassConfig const&, llvm::OptimizationRemarkEmitter&, llvm::OptimizationRemarkMissed&) IRTranslator.cpp:0:0
 #9 0x000056477581c493 llvm::IRTranslator::runOnMachineFunction(llvm::MachineFunction&) (/home/roland/llvm-mos/bin/ld.lld+0xc64493)
#10 0x0000564775a7719b llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#11 0x0000564776643d80 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/roland/llvm-mos/bin/ld.lld+0x1a8bd80)
#12 0x0000564776643ef7 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/roland/llvm-mos/bin/ld.lld+0x1a8bef7)
#13 0x00005647766445bc llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/roland/llvm-mos/bin/ld.lld+0x1a8c5bc)
#14 0x0000564775a0bf98 codegen(llvm::lto::Config const&, llvm::TargetMachine*, std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex const&) LTOBackend.cpp:0:0
#15 0x0000564775a0c136 llvm::lto::backend(llvm::lto::Config const&, std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&) (/home/roland/llvm-mos/bin/ld.lld+0xe54136)
#16 0x0000564775a057cb llvm::lto::LTO::runRegularLTO(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int)>) (/home/roland/llvm-mos/bin/ld.lld+0xe4d7cb)
#17 0x0000564775a05ae8 llvm::lto::LTO::run(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int)>, std::function<llvm::Expected<std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int)>> (unsigned int, llvm::StringRef)>) (/home/roland/llvm-mos/bin/ld.lld+0xe4dae8)
#18 0x0000564775402cae lld::elf::BitcodeCompiler::compile() (/home/roland/llvm-mos/bin/ld.lld+0x84acae)
#19 0x00005647753af7bc void lld::elf::LinkerDriver::compileBitcodeFiles<llvm::object::ELFType<(llvm::support::endianness)1, false>>(bool) (/home/roland/llvm-mos/bin/ld.lld+0x7f77bc)
#20 0x00005647753b5be7 lld::elf::LinkerDriver::link(llvm::opt::InputArgList&) (/home/roland/llvm-mos/bin/ld.lld+0x7fdbe7)
#21 0x00005647753bd8a7 lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef<char const*>) (/home/roland/llvm-mos/bin/ld.lld+0x8058a7)
#22 0x00005647753be59e lld::elf::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) (/home/roland/llvm-mos/bin/ld.lld+0x80659e)
#23 0x00005647752cf0a1 lldMain(int, char const**, llvm::raw_ostream&, llvm::raw_ostream&, bool) lld.cpp:0:0
#24 0x00005647752cf1e2 lld_main(int, char**) (/home/roland/llvm-mos/bin/ld.lld+0x7171e2)
#25 0x00007fedc2bc9d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#26 0x00007fedc2bc9e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#27 0x00005647752cd7fe _start (/home/roland/llvm-mos/bin/ld.lld+0x7157fe)
clang-16: error: unable to execute command: Aborted (core dumped)
clang-16: error: ld.lld command failed due to signal (use -v to see invocation)

[mysterymath]

Thanks for your help; I was able to reproduce this and diagnose it.

So, there's two problems here: how to actually do something like this, and why there wasn't an error message.

The first is simple; your code passes the contents of the external symbol, not its address. That's why n and i aren't acceptable without optimizations; the argument isn't a constant in that case, since the transformation that makes it a constant is an optimization. For example , you can say &ext_address, not ext_address. If you actually need to do a jump through a loaded address, then you'd have to do it with a pair of ZP registers in the general case, or enable optimizations so that the compiler can see across translation units that the value is actually constant; there has to be a way for the compiler to figure out what code to emit here!

As for the error message, compiling this code snippet to x86 assembly produces this:

main.cpp:5:9: error: invalid operand for inline asm constraint 'i'
        "jsr %0\n"
        ^
1 error generated.

Note that that's not an error message for the use of JSR, but for the use of an external symbol for constraint i.

The reason we're not getting good error messages is because we're using GlobalISel, the new instruction selection framework, while other targets use SelectionDAG. The way it's currently implemented, GlobalISel is supposed to fall back to SelectionDAG in cases like this, so it doesn't emit its own error messages. We don't actually have a SelectionDAG implementation to fall back to though, so it just crashes unhelpfully. I'll see what it'd take to check if a fall back is available and to emit error messages if not, but it'd be a pretty hefty diff from upstream.

I'll leave this open for the error message; we should do better here if we can.

[rolandshacks]

Hi. Thanks for picking this up so quickly!

I was fiddling around a bit further and also stumbled upon the missing address operator (forgotten &). Damn.

As there are plenty of workarounds available, I don't think this issue is in any sense high-prio. Writing asm modules might be the better choice for many things anyways.

Btw. I was optimizing a bit on that little demo I wrote using clang, ... looks there's plenty of things to further optimize on both sides ... the way to write code, and maybe the optimizer...

Thanks again for working on this fantastic idea to build a modern compiler for 6502!

[mysterymath]

Closing as won'tfix for the error message. It looks like this will need substatial effort to do, and that should happen naturally upstream as work on GlobalISel continues.