December 27, 2025

Kyu - compiler headaches

I am now embarking on some work with Kyu after several years of letting it sit dormant.

I want to begin with work on the Allwinner H5, so I did this: 

cd kyu/src
make clean
./config orange_pi64
make clean
make

C now has a "bool" type

This ought to "just work", but the first thing we see is: 
make[1]: Entering directory '/u2/Projects/Kyu/src/lib'
aarch64-linux-gnu-gcc -DKYU  -nostdinc -fno-builtin -Wno-implicit-function-declaration -fno-omit-frame-pointer -march=armv8-a+crc -mtune=cortex-a53 -DARM64 -I. -I.. -isystem /usr/lib/gcc/arm-linux-gnueabi/`aarch64-linux-gnu-gcc -dumpversion`/include -o string.o -c string.c
In file included from string.c:29:
linux_headers.h:83:17: error: ‘bool’ cannot be defined via ‘typedef’
   83 | typedef _Bool   bool;
It turns out that in 2023, C23 introduced a real "bool" type along with stdbool.h
I discover that I don't need a bool type anyway (maybe at one time I did, due to some imported source files), but I just comment out this typedef and a related enum that provides true and false, and it is on to the next issue;

What happened to stdarg.h

My next error is this: 
vsprintf.c:25:10: fatal error: stdarg.h: No such file or directory
   25 | #include
An ugly "fix" for this is to get rid of the "-nostdinc" option to gcc in my Makefile. This works, without unpleasant side issues, but how did it work before? I suspect that the -isystem argument is now somehow broken -- and it is!

Using "locate" on my system shows me a myriad of stdarg.h files on my system. It would be interesting to look at one or more of them sometime. The one that I should be getting is: 

/usr/lib/gcc/aarch64-linux-gnu/15/include/stdarg.h
Notice on the compile line above, that I get: 
-isystem /usr/lib/gcc/arm-linux-gnueabi/`aarch64-linux-gnu-gcc -dumpversion`/include
I can run "aarch64-linux-gnu-gcc -dumpversion" on the command line, and it gives me "15". Some investigation shows that I am using (on my Fedora 42 system): 
gcc-aarch64-linux-gnu.x86_64-15.2.1-1.fc42
aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (GCC) 15.2.1 20250808 (Red Hat Cross 15.2.1-1)
Copyright (C) 2025 Free Software Foundation, Inc.
The trick here is that they changed the path to the compiler include files as follows: 
/usr/lib/gcc/arm-linux-gnueabi/15/include/stdarg.h  (old way)
/usr/lib/gcc/aarch64-linux-gnu/15/include/stdarg.h  (new way)
So we fix this in Makefile.inc

Warning about non-ansi function declarations

Next I find this: 
cd tcp_bsd ; make
aarch64-linux-gnu-gcc -DKYU -DKERNEL -fno-builtin -Wno-implicit-function-declaration -fno-omit-frame-pointer -march=armv8-a+crc -mtune=cortex-a53 -DARM64 -I. -I.. -isystem /usr/lib/gcc/arm-linux-gnueabi/`aarch64-linux-gnu-gcc -dumpversion`/include -o kyu_main.o -c kyu_main.c
In file included from ./bsd.h:17,
./protos.h: In function ‘imax’:
./protos.h:151:1: warning: old-style function definition [-Wold-style-definition]
  151 | imax(a, b)
Indeed I have a collection of old-style functions in this include file. I hand edit them to ansi and wonder why we did not get these warnings before (or maybe we did). My general policy is to fix all warnings, so I doubt that I once just ignored them. The new compiler is just more fussy.

Indeed, as I continue I encounter a lot more warnings of this sort, and a look at the code in the tcp_bsd directory indicates that it is mostly traditional C with a lot of "old-style" declarations. I all worked fine, so rather than tackling the daunting talk of making all this BSD tcp code ansi, I want to just turn off the warning when I compile in this directory. 

# Added 12-27-2025
# This code is mostly traditional C
XTRA = -Wno-old-style-definition -Wno-int-to-pointer-cast
# The pointer warning is more serious.
# right now none of my hardware has addresses outside 32 bits.

# overriding .c.o did not work, so we have this:
%.o: %.c
    $(CCX) $(COPTS) $(XTRA) -o $@ -c $<
We also have a variety of warnings of this sort. These are more serious. I will ignore them for now, as my 64 bit hardware never has addresses bigger than 32 bits, but it could bite in the future. 
tcp_subr.c:221:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  221 |         tp = (struct tcpcb *) k_tcpcb_alloc ();

Trouble with "copy" in the BSD network code

mbuf.c:709:25: error: too many arguments to function ‘copy’; expected 0, have 3
  709 |                         copy(cp, mtod(m, caddr_t), (unsigned)len);
I don't find "copy" declared in any header file. In fact, it is an argument passed to a function as follows: 
struct mbuf *
mb_devget ( char *buf, int totlen, int off0,
    struct ifnet *ifp, void (*copy)()  )
Indeed, this is the only declaration and suggests that the routine has no arguments. Something more like this would be in order: 
void	bcopy __P((const void *from, void *to, u_int len));
Indeed, I add arguments to the function and to the prototype in mbuf.h like the following: 
struct  mbuf *mb_devget ( char *, int, int, struct ifnet *, void (*)(const void*, void*, unsigned int) );

Another pointer warning

thread.c:2047:38: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 2047 |         sprintf ( name, "sem-%04x", ((int)sp) & 0xffff );
Here we are generating an informative label. Strict correctness is not an issue. We would like to get rid of the warning, yet still keep the compiler alert for the bulk of the Kyu codebase. The answer here is simple -- change the int to long in the cast.

Proper vim colors in Makefile.inc

The trick is called a "vim modeline" which looks like a comment. 
# vim: noexpandtab filetype=make
Since this "include" Makefile has a non-standard name, I need the modeline. The filetype gets proper colors and the tab command tells vim not to monkey with tabs.

Odds and Ends

We add this to the link options: 
LDFLAGS = -g --no-warn-rwx-segments
This avoids the stupid warning about RWX segments. Now we discover a bunch of missing functions. These all look like things from aarch32 targets (like the H3) and need conditionals. Also there are a bunch of calls to the "etimer" (event timer), which is not yet implemented for aarch64. The good news is that we are now through all the compiler troubles and on to actually working on Kyu.

Now, various missing functions: 

#ifdef BOARD_ORANGE_PI
    etimer_init ();
#endif

#ifdef ARCH_ARM32
    get_SCTLR (val);
    get_ACTLR (val);
#endif
Above you see the conditionals I use to tame these. The etimer is something I should think about implementing on arm64 -- maybe this should be a general "lib" thing. I used the CCNT facility on aarch32 and will have to see if aarch64 has something similar.

I use the etimer in many places in tcp_bsd code, so I invent a conditional ETIMER_TCP and put it in bsd.h

For now, we add this simple stub for the dhrystone benchmark (which we could compile for aarch64). 

static void dhry_main ( void )
{
    printf ( "Sorry Charley - no dhrystone yet for arm64\n" );
}

The Conclusion

We now have a clean build of Kyu for the H5.

It yields h5.bin and puts that in the tftpboot directory, so a board reset will run it.
I get a lot of output (from past experiments), then: 

RAM 2042M+ available starting at 405f8000
Kyu version 0.9.5 for orange_pi64, Compiled by tom: Sat Dec 27 05:10:59 PM MST 2025 running
Kyu (opi), ready>
There is no response to anything I type, but this may well be unsolved problems with uart interrupts that I should now be able to easily fix.

What next?

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org