Open ethindp opened 1 month ago
This is very likely not a Flanterm issue. Make sure your provided mem*()
family of functions respects the C specification, and that your bindings work properly.
I believe that Zig's mem*()
implementation does respect the C specification, but I can check. As for the bindings part, I'm not using any bindings; I'm directly calling into the C code via Zig's @cImport
facility. I know that in hosted environments Zig does turn on some extras such as the thread sanitizer and such, but I can't imagine it would do that in a freestanding environment since the relevant infrastructure isn't available.
@mintsuki Okay, can confirm that it's something wrong with the flanterm library itself because somewhere it's invoking undefined behavior. Normally when Zig builds code it enables the UB sanitizer (which is obviously particularly important in C code). If I pass -fno-sanitize=undefined
to the C compiler when building flanterm specifically, I don't get the crash. I still get a black screen (for some reason it's not writing anything to my framebuffer... Weird) but it doesn't immediately crash for me when initializing flanterm.
Update: okay, so it's working fine for me (with UB sanitizer off) but it just doesn't work properly for me with -nographic
. So probably a qemu problem, maybe.
When I initialize flanterm as demonstrated in the README but adapted for Zig, like so:
A triple fault occurs, at least when built in debug mode. When built in release safe mode, the system just hangs. Qemu says this about the triggered interrupt:
The data that's passed to the first flanterm_fb_init call is:
(Why there are 30 video modes is beyond me.) After lots of digging into Flanterm's FB backend code, it appears that the error occurs sometime in the flanterm_fb_full_refresh function, specifically, I believe, in the plot_char call. Line 456 does:
And appears to just assume that the canvas is set, from what I can tell. But I may be wrong here; I'm not positive if I'm quite getting the right lines or not.