Displaying 4 results from an estimated 4 matches for "dibasetype".
Did you mean:
basetype
2014 Oct 24
8
[LLVMdev] First-class debug info IR: MDLocation
...the following:
!0 = metadata DIFile(filename: "foo.cpp", directory: "/path/to")
!1 = metadata DIFile(filename: "./t.h", directory: "/path/to")
!2 = metadata DIFile(filename: "bar.cpp", directory: "/path/to")
!3 = metadata DIBaseType(name: "short", size: 16, align: 16)
!5 = metadata DIBaseType(name: "int", size: 32, align: 32)
!6 = metadata DICompositeType(tag: 0x13, name: "T", uniqued: "_ZTS1T",
file: !1, line: 1, size: 32, align: 16)
!7 = me...
2015 Nov 02
4
Representing X86 long double in Debug Info
...scribe this in IR, because right now, even though the size is in bits,
will always emit `DW_AT_byte_size $(size>>3)`
3) How would clang describe this in it's TargetInfo
Just to throw my opinion out there:
1) Use the DW_AT_bit_size/DW_AT_byte_size
2) Add a new `storage_size` attribute to DIBaseType that is generally equal
to size, except in cases like this, where we should have `storage_size =
128, size = 80`
3) Have clang set those based on `getLongDoubeSize` (for storage size) and
`getLongDoubleFormat` as Reid suggested. This did seem very hacky too me at
first as well, but thinking about i...
2015 Nov 03
2
Representing X86 long double in Debug Info
...(size>>3)`
>>
>> 3) How would clang describe this in it's TargetInfo
>>
>>
>>
>> Just to throw my opinion out there:
>>
>>
>>
>> 1) Use the DW_AT_bit_size/DW_AT_byte_size
>>
>> 2) Add a new `storage_size` attribute to DIBaseType that is generally
>> equal to size, except in cases like this, where we should have
>> `storage_size = 128, size = 80`
>>
>>
>>
>> Maybe the other way around (so we don't change the semantics of an
>> existing field & have to worry about breaking ba...
2015 Nov 02
2
Representing X86 long double in Debug Info
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