debug info: f128 values do not display correctly in debuggers

[andrewrk]

test "aoeu" {
    var x = @bitCast(f128, 0x40042eab345678439abcdefea5678234);
    @breakpoint();
}

Expected behavior:

(gdb) p x
$1 = 37.8335959201289829757620127916183076

Actual behavior:

(gdb) p x
$1 = 1.3135418964036871286e+4336

Here's where the debug info for floats is set:

zig/src/codegen.cpp

Line 7106 in b5cc92f

add_fp_entry(g, "f128", 128, LLVMFP128Type(), &g->builtin_types.entry_f128);

[shawnl]

This bug also exists when using __float128 with gcc or clang, and this source file, compiled with -O0 -g, on amd64:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
  __float128 f = 37.8335959201289829757620127916183076;
  printf("Hello, world!\n");
  return EXIT_SUCCESS;
}

Sometimes lldb or gdb give
(long double) $0 = 1.35821198058130049262E+4336
and other times they give:
$1 = 37.8335959201289853126581874676048756

both are incorrect

[andrewrk]

both are incorrect

That's good to know. In the original issue description, I assumed the gdb/clang output for __float128 was correct. I guess this is an upstream issue then.

So now we need to file an upstream bug against LLVM or maybe one against gdb.

[rGradeStd]

I did a quick review of the lldb source code. It seems like there is lack of support for float128: many switches don't even have a float128 case.
Speaking of gdb, I found this topic, the situation is similar: http://sourceware-org.1504.n7.nabble.com/Debugger-support-for-float128-type-td348253.html
I may be wrong, but it seems that both lldb and gdb treat float128 as a long double, while it’s actually not long double. (or is it?)

[shawnl]

I may be wrong, but it seems that both lldb and gdb treat float128 as a long double, while it’s actually not long double. (or is it?)

This is not surprising. types in C are weird, because of legacy considerations.

[nektro]

confirming this affects stage2 as well

test {
    var x = @bitCast(f128, @as(u128, 0x40042eab345678439abcdefea5678234));
    @breakpoint();
    _ = x;
}

(gdb) p x
$1 = 1.3135418964036871286e+4336

[mikdusan]

did some digging:

1. gdb with main.c works with both gcc and clang on linux

2. lldb with main.c does not work on linux, can't try it on macos because __float128 not target supported

3. gdb with main.zig does not work because:

!2368 = !DICompositeType(tag: DW_TAG_union_type, name: "z2.main__union_3484", size: 128, align: 128, elements: !2369)
!2369 = !{!2370, !2372, !2374}
!2370 = !DIDerivedType(tag: DW_TAG_member, name: "u", scope: !2368, baseType: !2371, size: 128, align: 64)
!2371 = !DIBasicType(name: "u128", size: 128, encoding: DW_ATE_unsigned)
!2372 = !DIDerivedType(tag: DW_TAG_member, name: "f", scope: !2368, baseType: !2373, size: 128, align: 128)
!2373 = !DIBasicType(name: "f128", size: 128, encoding: DW_ATE_float)

on !2373 the name f128 is not recognized by gdb. Yes, gdb hard-codes a list of strings here:

https://github.com/bminor/binutils-gdb/blob/a62320ed0818decde5f3265ebc508756f517d6f9/gdb/i386-tdep.c#L8154-L8178

a potential hack would be for zig to emit __float128 in debug info. For example, manually editing a .ll and then building an executable works:

*** a	2024-02-20 18:47:59.757925875 -0500
--- b	2024-02-20 18:48:15.887751324 -0500
***************
*** 1 ****
! !2373 = !DIBasicType(name: "f128", size: 128, encoding: DW_ATE_float)
--- 1 ----
! !2373 = !DIBasicType(name: "__float128", size: 128, encoding: DW_ATE_float)

--

useful test sources...

main.c

#include <stdint.h>

int main(void) {
    typedef union {
        unsigned __int128 u;
        __float128 f;
        struct {
            uint64_t lo;
            uint64_t hi;
        } aggregate;
    } value;

    value num;
    num.aggregate.lo = 0x9abcdefea5678234;
    num.aggregate.hi = 0x40042eab34567843;

    char *p = 0;
    *p = 0;
}

main.zig

pub fn main() void {
    @setRuntimeSafety(false);

    var value: union {
        u: u128,
        f: f128,
        aggregate: struct {
            lo: u64,
            hi: u64,
        },
    } = undefined;
    value.u = 0x40042eab345678439abcdefea5678234;

    @breakpoint();
}

debug sessions

# GOOD: look to `f =` value
$ gcc -g -o mc main.c
$ gdb ./mc
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
(gdb) info locals
num = {u = 85092307472724069154655634854253134388, f = 37.8335959201289829757620127916183076, aggregate = {lo = 11150031962740589108, hi = 4612863231186597955}}

# BAD
$ zig build-exe main.zig -femit-bin=mz
$ gdb ./mz
(gdb) run
Program received signal SIGTRAP, Trace/breakpoint trap.
(gdb) info locals
value = {u = 85092307472724069154655634854253134388, f = 1.3135418964036871286e+4336, aggregate = {lo = 11150031962740589108, hi = 4612863231186597955}}

# GOOD
$ zig build-obj main.zig -femit-llvm-ir
$ cat main.ll | sed 's,"f128","__float128",' > main_hack.ll
$ zig build-exe main_hack.ll
$ gdb ./main_hack
Program received signal SIGTRAP, Trace/breakpoint trap.
(gdb) info locals
value = {u = 85092307472724069154655634854253134388, f = 37.8335959201289829757620127916183076, aggregate = {lo = 11150031962740589108, hi = 4612863231186597955}}