AVR compilation target leads to unreachable code

[schroffl]

I'm running macOS 10.15 and tried to cross-compile the default init-exe code to AVR, but this leads to unreachable code in getLDMOption. Here's the only change in the build script:

const Builder = @import("std").build.Builder;
const builtin = @import("builtin");

pub fn build(b: *Builder) void {
    const mode = b.standardReleaseOptions();
    const exe = b.addExecutable("zig-avr", "src/main.zig");
    exe.setBuildMode(mode);
+   exe.setTarget(builtin.Arch.avr, builtin.Os.freestanding, builtin.Abi.none);
    exe.install();

    const run_cmd = exe.run();
    run_cmd.step.dependOn(b.getInstallStep());

    const run_step = b.step("run", "Run the app");
    run_step.dependOn(&run_cmd.step);
}

And here's the actual error:

Unreachable at /Users/vsts/agent/2.155.1/work/1/s/src/link.cpp:1582 in getLDMOption. This is a bug in the Zig compiler.
Unable to dump stack trace: debug info stripped

[pixelherodev]

I'm not certain, but should ABI really be none there? Wouldn't EABI be more appropriate?

[schroffl]

You are right, it worked when I used EABI. I didn't have any idea and just entered some parameters that seemed like they would work, to be honest.
However, if this combination doesn't make any sense the compiler should probably tell it to the user instead of just throwing such an error, right?

[schroffl]

Nevermind, I accidentally set the architecture to Arm, which worked perfectly fine. The build still fails with AVR.

[pixelherodev]

This looks frustrating - I have a few AVR boards lying around, I'll try and see if I can get this working in my spare time over the coming weekend.

[schroffl]

Sounds awesome, thank you very much :)
I'd like to offer my help, but I'm probably not going to be of much assistance.

[pixelherodev]

A bunch of things came up, sorry for the delay; this is on my todo list for tomorrow.

[layneson]

The unreachable error is due to Zig not providing an emulation argument for the AVR target. This is understandable, considering that lld does not support AVR emulations (see the supported list here). Even if the -m argument were ignored specifically for AVR, lld's AVR support is practically nonexistent (for instance, only one of the 35 AVR ELF relocations has been implemented). Thus, AVR linking support is an upstream issue for the time being.

I have been getting around this by building an object file and then using avr-gcc to link my program (and provide the avr-libc CRT so that, for example, static data is properly initialized).

[schroffl]

@layneson Cool, thanks for the info. Did you put the avr-gcc step into our build file? I don't think I can get around to play with the Arduino right now, but it's good to know :)

[layneson]

Did you put the avr-gcc step into our build file?

Yes, I added a few system command build steps into my build.zig that run after the initial object file is produced. It's far from perfect but seems to work well.

I will publish an example/experiment repo with a build file soon; I'll link it here when it's up so that anyone who runs into this issue can see a potential workaround.

[schroffl]

Yes, I added a few system command build steps into my build.zig that run after the initial object file is produced. It's far from perfect but seems to work well.

That last sentence describes my experience with custom build processes in Zig quite well. It always seems like a makeshift solution, but in the end it works perfectly fine.

[LemonBoy]

@layneson Check out this lld patch, it should implement enough relocations to make it useful ;)

[layneson]

@LemonBoy Wow, that was quick and unexpected! I'll keep a close eye on that.

[alexrp]

This seems to have long since been fixed.