Compiler deficiencies compiling Nextvi

[kyx0r]

Hello, I'm compiling Nextvi:

./xcc -I /usr/include nextvi/vi.c

/usr/include/bits/alltypes.h(326): `;' or `,' expected
typedef __builtin_va_list va_list;
                          ^~~~~~~
/usr/include/bits/alltypes.h(326): unexpected token
typedef __builtin_va_list va_list;
                          ^~~~~~~
Assertion failed: type->struct_.info != NULL (src/cc/frontend/type.c: type_size: 206)

These are 2 separate problems. First va_list, this should be a trivial fix. Just parse the builtin and ignore.
The second one is a compiler deficiency with struct forward declarations.

// Reproducer for: typedef struct forward-decl + VLA = assertion failure
//
// Compile:
//   $ ./xcc examples/echo.c

typedef struct Foo Foo;

struct Foo {
    int x;
    int y;
};

void use(Foo *p);

void test(int n) {
    Foo arr[n];   // VLA: triggers type_size(Foo) via typedef -> incomplete type
    use(arr);
}

cc1: src/cc/frontend/type.c:206: type_size: Assertion `type->struct_.info != NULL' failed.

I'm interested in the project. The compiler looks promising. Could be a great tool for me if these are the only issues right now from having Nextvi compiling.

[kyx0r]

@tyfkda This PR solved the forward decl issue. But there was still the __builtin_va_list issue.

The patch below made the __builtin_va_list issue go away. It is nasty and probably not the correct way to do it.
I haven't looked deep enough, maybe you got better ideas.

diff --git a/include/stdarg.h b/include/stdarg.h
index 2e70a837..d3682a64 100644
--- a/include/stdarg.h
+++ b/include/stdarg.h
@@ -36,6 +36,8 @@ typedef void **va_list;
 
 #include <stdint.h>
 
+#ifndef __VA_ELEM_DEFINED
+#define __VA_ELEM_DEFINED
 struct __va_elem {
   unsigned int gp_offset;
   unsigned int fp_offset;
@@ -44,6 +46,7 @@ struct __va_elem {
 };
 
 typedef struct __va_elem __builtin_va_list[1];
+#endif
 
 typedef __builtin_va_list __gnuc_va_list;
 typedef __gnuc_va_list va_list;
diff --git a/src/cc/builtin.c b/src/cc/builtin.c
index 36589028..9b24d82a 100644
--- a/src/cc/builtin.c
+++ b/src/cc/builtin.c
@@ -562,9 +562,28 @@ void install_builtins(Vector *decls) {
   {
 #if VAARG_ON_STACK || XCC_TARGET_ARCH == XCC_ARCH_RISCV64
     Type *tyVaList = ptrof(&tyVoidPtr);
+    add_typedef(global_scope, alloc_name("__builtin_va_list", NULL, false), tyVaList);
 #else
-    Type *tyVaElem = create_struct_type(NULL, alloc_name("__va_elem", NULL, false), 0);
-    Type *tyVaList = ptrof(tyVaElem);
+    {
+      static const char va_list_src[] =
+        "#define __VA_ELEM_DEFINED\n"
+        "struct __va_elem {\n"
+        "  unsigned int gp_offset;\n"
+        "  unsigned int fp_offset;\n"
+        "  void *overflow_arg_area;\n"
+        "  void *reg_save_area;\n"
+        "};\n"
+        "typedef struct __va_elem __builtin_va_list[1];\n";
+      FILE *fp = fmemopen((void*)va_list_src, sizeof(va_list_src) - 1, "r");
+      if (fp != NULL) {
+        set_source_file(fp, "*builtins*");
+        parse(decls);
+        fclose(fp);
+      }
+    }
+    Type *tyBuiltinVaList = find_typedef(global_scope, alloc_name("__builtin_va_list", NULL, false), NULL);
+    assert(tyBuiltinVaList != NULL && tyBuiltinVaList->kind == TY_ARRAY);
+    Type *tyVaList = ptrof(tyBuiltinVaList->pa.ptrof);
 #endif
     static BuiltinFunctionProc p_va_start = &gen_builtin_va_start;
     Type *rettype = &tyVoid;
diff --git a/src/xcc/main.c b/src/xcc/main.c
index ce41f10c..35394f67 100644
--- a/src/xcc/main.c
+++ b/src/xcc/main.c
@@ -656,6 +656,9 @@ static void append_predefined_macros(Vector *cpp_cmd) {
 # error "Unsupported programming model"
 #endif
 
+#if !VAARG_ON_STACK && XCC_TARGET_ARCH != XCC_ARCH_RISCV64
+  vec_push(cpp_cmd, "-D__VA_ELEM_DEFINED");
+#endif
 #if defined(__NO_FLONUM)
   vec_push(cpp_cmd, "-D__NO_FLONUM");
 #endif

Later I realized that compiler doesn't support dynamic linking with GLIBC, so I am doing static linking with MUSL right now.

./xcc -I /usr/include -L /lib nextvi/vi.c
Multiple NOBITS sections not supported

Looks like still pretty far from working. Working around it:

diff --git a/src/ld/elfobj.c b/src/ld/elfobj.c
index c6f0ae2a..057e6e2f 100644
--- a/src/ld/elfobj.c
+++ b/src/ld/elfobj.c
@@ -107,9 +107,8 @@ ElfObj *read_elf(FILE *fp, const char *fn) {
     if (shdr->sh_size > 0) {
       switch (shdr->sh_type) {
       case SHT_NOBITS:
-        if (elfobj->nobit_shndx >= 0)
-          error("Multiple NOBITS sections not supported");
-        elfobj->nobit_shndx = i;
+        if (elfobj->nobit_shndx < 0)
+          elfobj->nobit_shndx = i;
         // Fallthrough
       case SHT_PROGBITS:
       case SHT_INIT_ARRAY:

There are also issues with:

Unresolved: #3
  __on_exit_chain
  _GLOBAL_OFFSET_TABLE_
  _DYNAMIC

Ok full stop. I decided to take a different route and compile to obj file with xcc -c and link using my native linker:

./xcc -c -I /usr/include -L /lib nextvi/vi.c
cc -static vi.o -o vi
/usr/bin/ld.bfd: warning: vi.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

Now I run ./vi and it working as intended. There are limitations with the current ld. But the compiler works overall.
What do you think we should do going forward? Fix all the issues with ld, or that is a non goal?

[tyfkda]

In my environment (Windows/WSL2/Ubuntu),
I was able to build nextvi using the following command.
Could you please try it?

$ CC=<PATH/TO/XCC>/tool/xccsh ./cbuild.sh

Since xccsh uses system's cc as the linker instead of xcc's one,
I believe the procedure is essentially the same as the one you followed.

I’m thinking of looking into the issues you reported, particularly the one where multiple NOBITS sections are being output.

[kyx0r]

It works on your environment because the system headers are different. Whatever the path it takes doesn't end up defining that __builtin_va_list. I can also compile it with whatever headers come on Arch Linux. I think allbits.h comes from libc, e.g MUSL. It would be a good practice to handle it. I'll be back in a week or 2 to take a look. Would be nice for compiler to handle this case. In the meantime, you could use my minimal 50MB KISS chroot to try and reproduce the issue: https://github.com/kyx0r/repo-main/releases It got gcc and sufficient build environment for xcc and reproduce this issue hopefully.

…

On Tue, Mar 31, 2026, 12:22 tyfkda ***@***.***> wrote: *tyfkda* left a comment (tyfkda/xcc#247) <#247 (comment)> In my environment (Windows/WSL2/Ubuntu), I was able to build nextvi using the following command. Could you please try it? $ CC=<PATH/TO/XCC>/tool/xccsh ./cbuild.sh Since xccsh <https://github.com/tyfkda/xcc/blob/578935cba1b76510ca57eb26e2988f4a9c4bf409/tool/xccsh> uses system's cc as the linker instead of xcc's one, I believe the procedure is essentially the same as the one you followed. I’m thinking of looking into the issues you reported, particularly the one where multiple NOBITS sections are being output. — Reply to this email directly, view it on GitHub <#247?email_source=notifications&email_token=AH52FH3XO6PA5O6XUERLVMD4TOL7XA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJWGE2TINZXGQ32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4161547747>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH52FH7R2AGN5XE5ADF3C2L4TOL7XAVCNFSM6AAAAACXFKC6WCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNRRGU2DONZUG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>