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.

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).

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