Failed to include `cmsis_gcc.h` because c-translation puts extern variables outside of inline function.

[Vitmark97]

Zig Version

0.12.0-dev.3667+77abd3a96

Steps to Reproduce and Observed Behavior

1. Source files

// problematic.h
static inline int problematic_func(void) {
  typedef int test_type_t;
  
  extern const test_type_t problematic_variable_1;
  extern const test_type_t problematic_variable_2;
  return problematic_variable_1 + problematic_variable_2;
}

// mainc.c
#include <stdio.h>
#include "problematic.h"

const int problematic_variable_1 = 10;
const int problematic_variable_2 = 35;

int main() {
  int result = problematic_func();
  printf("Result: %d\n", result);
  return 0;
}

// main.zig
const std = @import("std");
const problematic = @cImport({
    @cInclude("problematic.h");
});

export const problematic_variable_1: c_int = 10;
export const problematic_variable_2: c_int = 35;

pub fn main() void {
    const result = problematic.problematic_func();
    std.debug.print("Result: {}\n", .{result});
}

2. Try to compile C code

zig cc mainc.c -o mainc
./mainc

Prints Result: 45

3. Try to compile zig code

zig build-exe -lc -I. main.zig

Results in error:

.../cimport.zig:57:38: error: use of undeclared identifier 'test_type_t'
extern const problematic_variable_1: test_type_t;
                                     ^~~~~~~~~~~
.../cimport.zig:58:38: error: use of undeclared identifier 'test_type_t'
extern const problematic_variable_2: test_type_t;
                                     ^~~~~~~~~~~
main.zig:2:21: error: C import failed: AnalysisFail
const problematic = @cImport({

Generated zig code:

// cimport.zig
extern const problematic_variable_1: test_type_t;
extern const problematic_variable_2: test_type_t;
pub fn problematic_func() callconv(.C) c_int {
    const test_type_t = c_int;
    _ = &test_type_t;
    return problematic_variable_1 + problematic_variable_2;
}

4. Putting the typedef int test_type_t outside of the inline function

zig build-exe -lc -I. main.zig
./main

Prints Result: 45

Context

I've started to experiment with using zig on STM32G431 with STM32 HAL and CMSIS libraries and I'm getting a C import failed error because of __cmsis_start(void) function in cmsis_gcc.h.

https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_gcc.h#L137

The function contains type definitions for extern variables inside of it. When zig translates this code it leaves the type definitions inside the function but puts the extern variables before the function. This results in error where the type is not known at the point of extern declaration.

For now I can get around this issue without having to modify cmsis_gcc.h by defining @cDefine("__PROGRAM_START", ""); before including any STM32 HAL headers.

Expected Behavior

Successful compilation of zig code that includes inline C function with extern variables inside of it.

[haydenridd]

Noodling on a possible solution here. The issue, I think, stems from the fact that in Zig you can't declare:

extern const problematic_variable_1: test_type_t;

Inside a function like so:

// cimport.zig

pub fn problematic_func() callconv(.C) c_int {
    const test_type_t = c_int;
    _ = &test_type_t;
    extern const problematic_variable_1: test_type_t;
    extern const problematic_variable_2: test_type_t;
    return problematic_variable_1 + problematic_variable_2;
}

Matching the semantics of how these extern variables are referenced in C.

However, what you CAN do is the following using the @extern builtin:

// cimport.zig
pub fn problematic_func() callconv(.C) c_int {
    const test_type_t = c_int;
    _ = &test_type_t;
    const problematic_variable_1: test_type_t = @extern(*test_type_t, .{ .name = "problematic_variable_1" }).*;
    const problematic_variable_2: test_type_t = @extern(*test_type_t, .{ .name = "problematic_variable_2" }).*;
    return problematic_variable_1 + problematic_variable_2;
}

I'll look into the actual code that generates this and see how intrusive that change would be...

[silver-signal]

@Vexu this issue seems important to fix. Could we get it added to a milestone?

[Sazerac4]

Zig version

0.14.0-dev.2851+b074fb7dd

Description

Since I upgraded my experimentation code with STM32 to zig 0.14.0 (source code), I have tried to remove the workaround @cdefine("__PROGRAM_START", ""); from the 0.13.0 version.

I got an error when I import:

cimport.zig:215:49: error: use of undeclared identifier '__copy_table_start__'
        var pTable: [*c]const __copy_table_t = &__copy_table_start__;
                                              ^~~~~~~~~~~~~~~~~~~~

C Code:

__STATIC_FORCEINLINE __NO_RETURN void __cmsis_start(void)
{
  extern void _start(void) __NO_RETURN;
  
  typedef struct {
    uint32_t const* src;
    uint32_t* dest;
    uint32_t  wlen;
  } __copy_table_t;
  
  typedef struct {
    uint32_t* dest;
    uint32_t  wlen;
  } __zero_table_t;
  
  extern const __copy_table_t __copy_table_start__;
  extern const __copy_table_t __copy_table_end__;
  extern const __zero_table_t __zero_table_start__;
  extern const __zero_table_t __zero_table_end__;

  for (__copy_table_t const* pTable = &__copy_table_start__; pTable < &__copy_table_end__; ++pTable) {
    for(uint32_t i=0u; i<pTable->wlen; ++i) {
      pTable->dest[i] = pTable->src[i];
    }
  }
 
  for (__zero_table_t const* pTable = &__zero_table_start__; pTable < &__zero_table_end__; ++pTable) {
    for(uint32_t i=0u; i<pTable->wlen; ++i) {
      pTable->dest[i] = 0u;
    }
  }
 
  _start();
}

Here the translated code:

pub extern fn _start() noreturn;
pub inline fn __cmsis_start() noreturn {
    const struct_unnamed_1 = extern struct {
        src: [*c]const u32 = @import("std").mem.zeroes([*c]const u32),
        dest: [*c]u32 = @import("std").mem.zeroes([*c]u32),
        wlen: u32 = @import("std").mem.zeroes(u32),
    };
    _ = &struct_unnamed_1;
    const __copy_table_t = struct_unnamed_1;
    _ = &__copy_table_t;
    const struct_unnamed_2 = extern struct {
        dest: [*c]u32 = @import("std").mem.zeroes([*c]u32),
        wlen: u32 = @import("std").mem.zeroes(u32),
    };
    _ = &struct_unnamed_2;
    const __zero_table_t = struct_unnamed_2;
    _ = &__zero_table_t;
    const ExternLocal___copy_table_start__ = struct {
        extern const __copy_table_start__: __copy_table_t;
    };
    _ = &ExternLocal___copy_table_start__;
    const ExternLocal___copy_table_end__ = struct {
        extern const __copy_table_end__: __copy_table_t;
    };
    _ = &ExternLocal___copy_table_end__;
    const ExternLocal___zero_table_start__ = struct {
        extern const __zero_table_start__: __zero_table_t;
    };
    _ = &ExternLocal___zero_table_start__;
    const ExternLocal___zero_table_end__ = struct {
        extern const __zero_table_end__: __zero_table_t;
    };
    _ = &ExternLocal___zero_table_end__;
    {
        var pTable: [*c]const __copy_table_t = &__copy_table_start__;
        _ = &pTable;
        while (pTable < (&__copy_table_end__)) : (pTable += 1) {
            {
                var i: u32 = 0;
                _ = &i;
                while (i < pTable.*.wlen) : (i +%= 1) {
                    pTable.*.dest[i] = pTable.*.src[i];
                }
            }
        }
    }
    {
        var pTable: [*c]const __zero_table_t = &__zero_table_start__;
        _ = &pTable;
        while (pTable < (&__zero_table_end__)) : (pTable += 1) {
            {
                var i: u32 = 0;
                _ = &i;
                while (i < pTable.*.wlen) : (i +%= 1) {
                    pTable.*.dest[i] = 0;
                }
            }
        }
    }
    _start();
}

By looking at the merge request #20298 addressed to this issue, I expect these lines

        var pTable: [*c]const __copy_table_t = &__copy_table_start__;
       ...
        while (pTable < (&__copy_table_end__)) : (pTable += 1) {
       ...
        var pTable: [*c]const __zero_table_t = &__zero_table_start__;
       ...
        while (pTable < (&__zero_table_end__)) : (pTable += 1) {

To be :

        var pTable: [*c]const __copy_table_t = &ExternLocal___copy_table_start__.__copy_table_start__;
       ...
        while (pTable < (&ExternLocal___copy_table_end__.__copy_table_end__)) : (pTable += 1) {
       ...
        var pTable: [*c]const __zero_table_t = &ExternLocal___zero_table_start__.__zero_table_start__;
       ...
        while (pTable < (&ExternLocal___zero_table_end__.__zero_table_end__)) : (pTable += 1) {

Am I wrong ?

[haydenridd]

@Sazerac4 interesting! I'll clone this and see if either:

• This is a case my original change didn't account for somehow
• Something else after this change clobbered it

[haydenridd]

@Sazerac4 good catch, it seems to specifically be failing when the extern variable is referenced in the condition clause of the for loop. Someone already similarly fixed something I missed in:
#20828

I'll open an additional issue to not clog up this thread!

[haydenridd]

Opened as:
#22671