On both non-Windows x86-64 (which uses x86_fp80 as long double) and PowerPC (which uses ppc_fp80 as long double), Clang emits long double and __float128 with exactly the same debuginfo: a DW_AT_encoding of DW_ATE_float and a DW_AT_byte_size of 0x10. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as long double is long double, meaning __float128 values get displayed as nonsense.
This can be seen by debugging this C program on an affected platform:
The long double will be displayed correctly in LLDB, whereas the __float128 will not. This problem also affects debuginfo emitted by GCC and rustc (while rustc doesn't support long double, its f128 type will still get misinterpreted as long double by the debugger).
While searching for previous discussion, I found this thread from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new DW_ATE codes, but I haven't been able to find any further discussion since.
On both non-Windows x86-64 (which uses `x86_fp80` as `long double`) and PowerPC (which uses `ppc_fp80` as `long double`), Clang emits `long double` and `__float128` with exactly the same debuginfo: a `DW_AT_encoding` of `DW_ATE_float` and a `DW_AT_byte_size` of `0x10`. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as `long double` is `long double`, meaning `__float128` values get displayed as nonsense.
This can be seen by debugging this C program on an affected platform:
```c
void breakpoint(long double ld, __float128 f128) {}
int main() {
breakpoint(1.0, 2.0);
}
```
The `long double` will be displayed correctly in LLDB, whereas the `__float128` will not. This problem also affects debuginfo emitted by GCC and `rustc` (while `rustc` doesn't support `long double`, its `f128` type will still get misinterpreted as `long double` by the debugger).
While searching for previous discussion, I found [this thread](https://lists.dwarfstd.org/pipermail/dwarf-discuss/2022-January/002103.html) from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new `DW_ATE` codes, but I haven't been able to find any further discussion since.
On both non-Windows x86-64 (which uses `x86_fp80` as `long double`) and PowerPC (which uses `ppc_fp80` as `long double`), Clang emits `long double` and `__float128` with exactly the same debuginfo: a `DW_AT_encoding` of `DW_ATE_float` and a `DW_AT_byte_size` of `0x10`. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as `long double` is `long double`, meaning `__float128` values get displayed as nonsense.
This can be seen by debugging this C program on an affected platform:
```c
void breakpoint(long double ld, __float128 f128) {}
int main() {
breakpoint(1.0, 2.0);
}
```
The `long double` will be displayed correctly in LLDB, whereas the `__float128` will not. This problem also affects debuginfo emitted by GCC and `rustc` (while `rustc` doesn't support `long double`, its `f128` type will still get misinterpreted as `long double` by the debugger).
While searching for previous discussion, I found [this thread](https://lists.dwarfstd.org/pipermail/dwarf-discuss/2022-January/002103.html) from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new `DW_ATE` codes, but I haven't been able to find any further discussion since.
On both non-Windows x86-64 (which uses `x86_fp80` as `long double`) and PowerPC (which uses `ppc_fp80` as `long double`), Clang emits `long double` and `__float128` with exactly the same debuginfo: a `DW_AT_encoding` of `DW_ATE_float` and a `DW_AT_byte_size` of `0x10`. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as `long double` is `long double`, meaning `__float128` values get displayed as nonsense.
This can be seen by debugging this C program on an affected platform:
```c
void breakpoint(long double ld, __float128 f128) {}
int main() {
breakpoint(1.0, 2.0);
}
```
The `long double` will be displayed correctly in LLDB, whereas the `__float128` will not. This problem also affects debuginfo emitted by GCC and `rustc` (while `rustc` doesn't support `long double`, its `f128` type will still get misinterpreted as `long double` by the debugger).
While searching for previous discussion, I found [this thread](https://lists.dwarfstd.org/pipermail/dwarf-discuss/2022-January/002103.html) from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new `DW_ATE` codes, but I haven't been able to find any further discussion since.
On both non-Windows x86-64 (which uses
x86_fp80
aslong double
) and PowerPC (which usesppc_fp80
aslong double
), Clang emitslong double
and__float128
with exactly the same debuginfo: aDW_AT_encoding
ofDW_ATE_float
and aDW_AT_byte_size
of0x10
. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size aslong double
islong double
, meaning__float128
values get displayed as nonsense.This can be seen by debugging this C program on an affected platform:
The
long double
will be displayed correctly in LLDB, whereas the__float128
will not. This problem also affects debuginfo emitted by GCC andrustc
(whilerustc
doesn't supportlong double
, itsf128
type will still get misinterpreted aslong double
by the debugger).While searching for previous discussion, I found this thread from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new
DW_ATE
codes, but I haven't been able to find any further discussion since.