Bug: "unable to evaluate constant expression" when depending on symbol address

[ikskuh]

Consider the following Zig code:

var stack: [256]u32 = undefined;

export const interrupt_table = [_][*]u32{
    @ptrCast([*]u32, &stack) + stack.len,
};

which will yield this error:

<source>:4:30: error: unable to evaluate constant expression
    @ptrCast([*]u32, &stack) + stack.len,
                             ^
<source>:3:41: note: referenced here
export const interrupt_table = [_][*]u32{
                                        ^

Such code is required when bootstrapping microcontrolls like the Cortex M3, as it requires the initial stack pointer to be stored in the interrupt vector table.

The C equivalent works:

uint32_t stack[256];

const uint32_t * interrupt_table[1] = {
    stack + 256,
};

Example in godbolt: https://c.godbolt.org/z/zhxcMM

One workaround i tried was declaring the end of stack as a separate symbol:

extern var stack: [256]u32;

export const interrupt_table = [_][*]u32{
    &stack,
};

but this yields this error:

<source>:4:5: error: unable to evaluate constant expression
    &stack,
    ^
<source>:3:41: note: referenced here
export const interrupt_table = [_][*]u32{
                                        ^

This code is required to work, otherwise it is not possible to bootstrap such microcontrollers in Zig.

[ghost]

I wasn't aware that Zig allows pointer math? Don't you have to use ptrToInt?

[LiterallyVoid]

Pointer math is allowed on unknown-length pointers ([*]T).

[ghost]

Cool didn't know that. I guess that and intToPtr/ptrToInt are not currently allowed in a global expression.

The only workaround I got to work was making the stack 257 values long:

var stack: [257]u32 = undefined;

export const interrupt_table = [_][*]u32{
    @ptrCast([*]u32, &stack[256]),
};

[justinbalexander]

Here's how I worked around it.

https://github.com/vegecode/BurnedHead/blob/d393f348b8c5f6282128cea2af9c81c6e5fa296e/firmware/startup.zig#L17-L28

[ikskuh]

@vegecode yeah, using linker script magic is a option here. for now, i just keep that part in C, doesn't really hurt. Can i somehow contact you on irc/discord/mail? I'd like to create some good embedded ARM base and it looks like you also did some work already :)

[justinbalexander]

@MasterQ32, Sure you can contact me. I'm on reddit with the same username, I think discord too. I got burned out juggling family stuff, work, and side projects so I haven't done much in a while. I'd love to be re-inspired though! I can PM you my email on there which is probably the easiest way to get a response from me.

[iacore]

Does "address of symbol" even make sense with weak linkage?

For example, the address is not defined at compile time (of the object file), but will be defined when linked with other objects later.

Example

main.c:

#include <stdio.h>

extern __attribute__((weak)) int foo;

int main() {
    printf("%p\n", &foo);
    if (&foo != 0) {
        printf("foo = %d\n", foo);
    }
    fflush(stdout);
}

lib.c:

int foo = 42;

> clang -c main.c -o main.o^C
> clang main.o -o main
> ./main
(nil)
> clang -c lib.c -o lib.o
> clang main.o lib.o -o main2
> ./main2
0x5f732464c038
foo = 42

[Vexu]

Why are you bringing up weak linkage? None of the symbols in the examples have weak linkage.

[iacore]

It is not in the example. I fear that some compiler/linker with attempt to move the PLT table after the zig code is already compiled (e.g. with compiler flags).

It is a concern for relocatable linkable objects too, where exported symbols can change address.

[SpexGuy]

Regardless, it does still make sense. Comptime known addresses are symbolic values that will be resolved after comptime. They can be passed around and you can use @ptrToInt and @intToPtr on them, but attempting to inspect their actual value at comptime is a compile error. A more detailed description of how these symbols behave is in #9646.

It's implemented by tracking offsets and emitting relocations anywhere this value is stored.

[iacore]

If #9646 is implemented then it is fine.

[xdBronch]

this is marked stage1 and seems to compile now, can it be closed since stage2 is default?

[Vexu]

Works in master.