llvm dev - Nov 2015 - Representing X86 long double in Debug Info

I'm in the process of teaching the Verifier to validate that the size of
debug info variable and the described value matches (already caught a
couple of bugs, both in my frontend and in LLVM itself). However, I've run
into the following:

size of passed value (80) does not match size of declared variable (128)
  call void @llvm.dbg.declare(metadata x86_fp80* %x, metadata !11, metadata
!13), !dbg !14
  %x = alloca x86_fp80, align 16
!11 = !DILocalVariable(name: "x", scope: !4, file: !1, line: 2, type:
!12)
!12 = !DIBasicType(name: "long double", size: 128, align: 128,
encoding:
DW_ATE_float)
!13 = !DIExpression()

which happens because llvm knows that fp80s are 80bits, while clang
declares them as 128bits in the debug info. We might have to special case
this in the verifier, but before we do that, I wanted to ask about the
following:

Reading the DWARF standard, it seems like the following would be a valid
description of an X86 80bit long double:

DW_TAG_base_type
DW_AT_name "long double"
DW_AT_byte_size  16
DW_AT_bit_size      80

As far as I can tell from looking through the source code, both LLDB and
GDB would read this just fine, it would be a more accurate description of a
long double and if we add support for it in LLVM IR, the verifier would be
able to understand what's actually going on. Does this seem like a
reasonable thing to have LLVM do or would you prefer to just disable this
check in the verifier if there are x86_fp80 types around?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151101/04106679/attachment.html>

> On Nov 1, 2015, at 3:14 AM, Keno Fischer <kfischer at
college.harvard.edu> wrote:
> 
> I'm in the process of teaching the Verifier to validate that the size
of debug info variable and the described value matches (already caught a couple
of bugs, both in my frontend and in LLVM itself). However, I've run into the
following:
> 
> size of passed value (80) does not match size of declared variable (128)
>   call void @llvm.dbg.declare(metadata x86_fp80* %x, metadata !11, metadata
!13), !dbg !14
>   %x = alloca x86_fp80, align 16
> !11 = !DILocalVariable(name: "x", scope: !4, file: !1, line: 2,
type: !12)
> !12 = !DIBasicType(name: "long double", size: 128, align: 128,
encoding: DW_ATE_float)
> !13 = !DIExpression()
> 
> which happens because llvm knows that fp80s are 80bits, while clang
declares them as 128bits in the debug info. We might have to special case this
in the verifier, but before we do that, I wanted to ask about the following:
> 
> Reading the DWARF standard, it seems like the following would be a valid
description of an X86 80bit long double:
> 
> DW_TAG_base_type
> DW_AT_name "long double"
> DW_AT_byte_size  16
> DW_AT_bit_size      80
> 
> As far as I can tell from looking through the source code, both LLDB and
GDB would read this just fine, it would be a more accurate description of a long
double and if we add support for it in LLVM IR, the verifier would be able to
understand what's actually going on. Does this seem like a reasonable thing
to have LLVM do or would you prefer to just disable this check in the verifier
if there are x86_fp80 types around?
Looking at the code in clang CGDebugInfo just passes through the width of the
type as it is described by the TypeInfo, which in turn is defined by the Target.
At the moment I do not understand why an x86_fp80 is reported to be 128 bits
wide. (Since it’s a type natively supported by LLVM
http://llvm.org/docs/LangRef.html#floating-point-types
<http://llvm.org/docs/LangRef.html#floating-point-types> I would have
expected it to be more like size=80, align=128)

This looks like a bug to me and the debug info should describe an x86_fp80 as
being 80 bits wide, but I don’t understand the mechanics well enough to decide
whether the TypeInfo is wrong here or if we should work around it in
CGDebugInfo.

[Summoning more people who may have a better idea]

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/c1e553fc/attachment.html>

Using byte_size=16, bit_size=80 (and optional data_bit_offset) would be the
right way to go as far as the DWARF spec is concerned.
Persuading TypeInfo to describe something that would generate this is really the
question.
--paulr

From: aprantl at apple.com [mailto:aprantl at apple.com]
Sent: Monday, November 02, 2015 8:39 AM
To: Keno Fischer
Cc: llvm-dev; Duncan P. N. Exon Smith; David Blaikie; Eric Christopher;
Robinson, Paul
Subject: Re: Representing X86 long double in Debug Info


On Nov 1, 2015, at 3:14 AM, Keno Fischer <kfischer at
college.harvard.edu<mailto:kfischer at college.harvard.edu>> wrote:

I'm in the process of teaching the Verifier to validate that the size of
debug info variable and the described value matches (already caught a couple of
bugs, both in my frontend and in LLVM itself). However, I've run into the
following:

size of passed value (80) does not match size of declared variable (128)
  call void @llvm.dbg.declare(metadata x86_fp80* %x, metadata !11, metadata
!13), !dbg !14
  %x = alloca x86_fp80, align 16
!11 = !DILocalVariable(name: "x", scope: !4, file: !1, line: 2, type:
!12)
!12 = !DIBasicType(name: "long double", size: 128, align: 128,
encoding: DW_ATE_float)
!13 = !DIExpression()

which happens because llvm knows that fp80s are 80bits, while clang declares
them as 128bits in the debug info. We might have to special case this in the
verifier, but before we do that, I wanted to ask about the following:

Reading the DWARF standard, it seems like the following would be a valid
description of an X86 80bit long double:

DW_TAG_base_type
DW_AT_name "long double"
DW_AT_byte_size  16
DW_AT_bit_size      80

As far as I can tell from looking through the source code, both LLDB and GDB
would read this just fine, it would be a more accurate description of a long
double and if we add support for it in LLVM IR, the verifier would be able to
understand what's actually going on. Does this seem like a reasonable thing
to have LLVM do or would you prefer to just disable this check in the verifier
if there are x86_fp80 types around?

Looking at the code in clang CGDebugInfo just passes through the width of the
type as it is described by the TypeInfo, which in turn is defined by the Target.
At the moment I do not understand why an x86_fp80 is reported to be 128 bits
wide. (Since it’s a type natively supported by LLVM
http://llvm.org/docs/LangRef.html#floating-point-types I would have expected it
to be more like size=80, align=128)

This looks like a bug to me and the debug info should describe an x86_fp80 as
being 80 bits wide, but I don’t understand the mechanics well enough to decide
whether the TypeInfo is wrong here or if we should work around it in
CGDebugInfo.

[Summoning more people who may have a better idea]

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/428d4301/attachment.html>

On Mon, Nov 2, 2015 at 8:38 AM, Adrian Prantl via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Looking at the code in clang CGDebugInfo just passes through the width of
> the type as it is described by the TypeInfo, which in turn is defined by
> the Target. At the moment I do not understand why an x86_fp80 is reported
> to be 128 bits wide. (Since it’s a type natively supported by LLVM
> http://llvm.org/docs/LangRef.html#floating-point-types I would have
> expected it to be more like size=80, align=128)
>
> This looks like a bug to me and the debug info should describe an x86_fp80
> as being 80 bits wide, but I don’t understand the mechanics well enough to
> decide whether the TypeInfo is wrong here or if we should work around it in
> CGDebugInfo.
>
I think TypeInfo usually describes the answer that sizeof() is supposed to
give. sizeof() is typically a multiple of alignment, so if alignof() is
128, sizeof must be 128. Other common alignments are 32 and 64, which makes
sizeof() 96 and 128 respectively. In practice, sizeof(long double) is never
80.

Maybe CGDebugInfo should ask TargetInfo::getLongDoubleFormat() what model
is in use and generate dwarf accordingly. It's a bit of a hack, so I'm
open
to better suggestions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/c8b7b982/attachment.html>

Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015:
> Looking at the code in clang CGDebugInfo just passes through the  
> width of the type as it is described by the TypeInfo, which in turn  
> is defined by the Target. At the moment I do not understand why an  
> x86_fp80 is reported to be 128 bits wide.
The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended  
type in memory as 16 bytes. In all other i386 ABIs, it's defined as 12  
bytes. Delphi and, for compatibility reasons, the Free Pascal Compiler  
use 10 bytes (although FPC also has a "cextended" type that follows  
the official ABI for the platform). In FPC we use a [10 x i8] for all  
memory representations of the non-ABI 80 bits extended type.

So ideally, the bitsize of the type should be specifiable separately  
from the ABI/TypeInfo, as there may be multiple in the code.


Jonas