Entrypoint is now required to be `_start` on thumb-freestanding builds?

[frmdstryr]

Zig Version

0.12.0-dev.2059+42389cb9c

Steps to Reproduce and Observed Behavior

I recently updated from 0.12.0-dev.1721 ish to the version above... Now when trying to build with the I get:

   +- zig build-exe firmware.elf ReleaseSafe thumb-freestanding-eabihf failure
error: warning(link): unexpected LLD stderr:
ld.lld: warning: cannot find entry symbol _start; not setting start address

And the firmware just immediately hard faults.

If I rename the actual entry point function (eg resetHandler) from the linker script to _start it works but I'm not sure why it requires this now.

Expected Behavior

It should either:

• Provide a way to change the entry point function name (or a more helpful error message on how to do so)
• use the entry point from the linker script as it did before (eg Entry(resetHandler))

[frmdstryr]

Appears to be due to https://github.com/ziglang/zig/commit/57562c8d507667b6fefcb7fbc7a305fbd610b5dd

[frmdstryr]

Guess you have to now use this:

    elf.entry = .{.symbol_name="resetHandler"};

[Vexu]

If you are using a linker script that sets the entry point that seems like something that should still work. cc @kubkon

[kubkon]

cc @andrewrk seems related to your latest yak shave. FWIW I can have a look as well when porting latest MachO over.

[andrewrk]

    elf.entry = .{.symbol_name="resetHandler"};

This looks perfect to me.

I think we should transition to declarative linking as much as possible. I don't see any reason why a linker script should be used to specify the entry point when a declarative symbol name perfectly solves the problem.

It looks to me like this use case is handled just fine.

Related: #3206

[kubkon]

    elf.entry = .{.symbol_name="resetHandler"};

This looks perfect to me.

I think we should transition to declarative linking as much as possible. I don't see any reason why a linker script should be used to specify the entry point when a declarative symbol name perfectly solves the problem.

It looks to me like this use case is handled just fine.

Related: #3206

FWIW I will take declarative style and in Zig over GNU linker scripts any day.