Can't format u32 values on i386 arch

[fazibear]

Trying to compile:

const std = @import("std");

pub fn main() anyerror!void {
    var x:u32 = 123;
    
    std.debug.warn("test: {}", .{x});
}

with

    const target = b.standardTargetOptions(.{
        .default_target = .{
            .cpu_arch = .i386,
        },
    });

throws error:

/usr/local/Cellar/zig/0.6.0/lib/zig/std/debug.zig:1449:78: error: expected type 'usize', found 'u64'
                    .line_info = o_file_di.getLineNumberInfo(compile_unit.*, relocated_address_o) catch |err| switch (err) {
                                                                             ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/debug.zig:1449:78: note: unsigned 32-bit int cannot represent all possible unsigned 64-bit values
                    .line_info = o_file_di.getLineNumberInfo(compile_unit.*, relocated_address_o) catch |err| switch (err) {
                                                                             ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/debug.zig:578:25: note: referenced here
    const symbol_info = try module.getSymbolAtAddress(address);
                        ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/debug.zig:328:9: note: referenced here
        try printSourceAtAddress(debug_info, out_stream, return_address - 1, tty_config);
        ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/debug.zig:211:98: note: referenced here
    writeStackTrace(stack_trace, stderr, getDebugInfoAllocator(), debug_info, detectTTYConfig()) catch |err| {
                                                                                                 ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/debug.zig:228:14: error: unable to evaluate constant expression
    if (!ok) unreachable; // assertion failure
             ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/os/bits/darwin.zig:161:11: note: called from here
    assert(@byteOffsetOf(Kevent, "filter") == 8);
          ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/os/bits/darwin.zig:159:10: note: called from here
comptime {
         ^
/usr/local/Cellar/zig/0.6.0/lib/zig/std/os/bits/darwin.zig:161:11: note: referenced here
    assert(@byteOffsetOf(Kevent, "filter") == 8);
          ^

Is it a bug?

[FireFox317]

Two bugs actually:

1. assert(@byteOffsetOf(Kevent, "filter") == 8
   Then Zig tries to print a stack trace, but that also fails:
2. usr/local/Cellar/zig/0.6.0/lib/zig/std/debug.zig:1449:78: error: expected type 'usize', found 'u64' .line_info = o_file_di.getLineNumberInfo(compile_unit.*, relocated_address_o) catch |err| switch (err) {

[LemonBoy]

Are you intentionally targeting osx/x86 ?

[Vexu]

This likely won't be fixed since Zig doesn't support i386-macosx #1930.

[fazibear]

Ups. My mistake.

I'm just messing around kernel stuff - rewriting from c, and problems appears when I want to format string with u32. Because it's qemu and don't have any debuggers configured tried to reproduce problem with simple snippet and this appeared. But it's not about osx.

Here is the repo: https://github.com/fazibear/fazigos

Within this file there is printf function.

The first version of this functions was:

pub fn printf(comptime format: []const u8, args: var) void {
  var printf_buff: [256]u8 = undefined;    
  var formatted = fmt.bufPrint(printf_buff[0..], format, args) catch |err| switch (err) {
        error.NoSpaceLeft => "xxx",
    };
    print(formatted);
}

But with large values simply throws invalid opcode exception. When I moved print_buff on the top of the file it helps. But when I trying to printf("{}", .{x}); it also throws invalid opcode exception.

Right now i'm casting it to u16 and it works fine. I'm just trying to understand why moving print_buf to the top fixes the formatting problem, and why u32 doesn't work.

[Vexu]

If you are trying to target freestanding you need to add .os_tag = .freestanding to your default_target otherwise it will default to native which for you seems to be macosx.

See https://github.com/jzck/kernel-zig/blob/master/build.zig or https://github.com/markfirmware/zig-bare-metal-raspberry-pi/blob/master/build.zig for example.

[LemonBoy]

• Run qemu with -d unimp
• Note down the faulty IP
• Disassemble the binary
• Notice how it points to 66 0f 6e c7 · movd %edi,%xmm0
• You have to enable SSE for this to work

[fazibear]

@LemonBoy Great answer thanks! Can I disable building with SSE in build.zig?

Still wondering why defining buffer inside function requires SSE, but placing it on the top doesn't ;)

[LemonBoy]

Great answer thanks! Can I disable building with SSE in build.zig?

Check this build.zig. Enabling SSE is IMO better than dealing with x87.

Still wondering why defining buffer inside function requires SSE, but placing it on the top doesn't ;)

It crashes either way for me while trying to print 0xffffffff, the buffer placement doesn't (and shouldn't) matter.

[fazibear]

Great answer thanks! Can I disable building with SSE in build.zig?

Check this build.zig. Enabling SSE is IMO better than dealing with x87.

Something has changed in 0.6.0 and this build.zig doesn't work. I can't build this project.

Still wondering why defining buffer inside function requires SSE, but placing it on the top doesn't ;)

It crashes either way for me while trying to print 0xffffffff, the buffer placement doesn't (and shouldn't) matter.

It's true for 32 bit values but if you try:

vga.printf("{}", .{"test"});

It will work, but if you move printf_buffer into printf function, it generates ILLOPC: 0001401f: 66 0f 6e

PS. Still can't enable SSE on qemu.

Tries with emu-system-x86_64, -cpu max, +sse* flags with no luck. Maybe it's something on OSX.

[LemonBoy]

Something has changed in 0.6.0 and this build.zig doesn't work. I can't build this project.

Then check this

It's true for 32 bit values but if you try:

You may be triggering other codepaths requiring SSE.

PS. Still can't enable SSE on qemu.

That's osdev stuff and way out of scope for this ticket.

[fazibear]

One moge thing. If 386 on macos is unsupported, maybe the compiler could show nice message about that?

[RetroDev256]

Since PR 5348, it seems that std.debug.warn moved to std.log.warn. I attempted to reproduce this on my machine, and could not. I cross-compiled from x86_64-linux to x86-linux and x86-windows (tested in wine). Both versions compiled, and seemed to work fine. Would we need a test added to close this issue?

[Vexu]

The standard library tests which include formatting u32s are run on some x86 targets so I think this can just be closed.