support external weak symbol references

[andrewrk]

Accepted Proposal

---

We need a way to declare an external symbol, but one that should be NULL rather than a linker error if the symbol is never supplied.

One use case is to detect if an executable is dynamically linked, like this: https://git.musl-libc.org/cgit/musl/tree/src/env/__init_tls.c#n89:

extern weak hidden const size_t _DYNAMIC[];
...
		if (_DYNAMIC)

When an external weak symbol is not linked, there actually is no address for it. So representing it as an optional type is incorrect. What we need is an optional pointer to the symbol. For that I propose a builtin function:

@externWeak(comptime name: []const u8, comptime PointerType: type) ?PointerType

PointerType could be any pointer type. The reason we supply the pointer type and not the element type is so that the default alignment can optionally be overridden by using a pointer type with an explicit alignment.

With this proposal the C code above could be represented in Zig like this:

if (@externWeak("_DYNAMIC", [*]usize) != null)

The result value of the function is a runtime-time known value, however it is eligible to participate in simple global variable initialization expressions.

[emekoi]

could we change the order of parameters to be @externWeak(comptime PointerType: type, comptime name: []const u8, ) ?PointerType to match other builtins?

[andrewrk]

You mean to match the casting builtins? This builtin is closer to a variable declaration than a cast, which is why I picked parameters that matched variable declaration syntax: var name: Type.

[andrewrk]

The result value of the function is a runtime-time known value, however it is eligible to participate in simple global variable initialization expressions.

This is related to #2174

[LemonBoy]

I have implemented this but it's a bit awkward to use: it actually declares a global symbol during the codegen phase but it's not exposed to the Zig side since it's not really a variable declaration. The biggest problem here is that I have no clue about what to do if we detect a pre-existing symbol (coming either from a normal declaration or a previous use of @externWeak) nor how to handle the re-definition case in general.

I can upload a draft PR if you want to have a look at the code.

[andrewrk]

@LemonBoy I would be interested in seeing that draft. I reviewed this proposal and it still makes sense to me.

I think conflicts with other external symbols can simply be compile errors.

I'd be happy to work with you on getting the feature to feel correct.

[LemonBoy]

Here's my branch.

[LemonBoy]

I think the same problem applies to @export, if you're not careful enough you may end up stomping over some other symbol without any warning.