[llvm-dev] Representing X86 long double in Debug Info

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 2 14:26:49 PST 2015


I'm a bit confused by all this - sizeof(long double) is 16 bytes (128
bits). I /think/ that's what we should be describing, even if some of
that's essentially padding?

On Mon, Nov 2, 2015 at 1:04 PM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/26e484d3/attachment.html>


More information about the llvm-dev mailing list