search for: createsubroutinetyp

Is anyone maintaining this page? http://llvm.org/docs/SourceLevelDebugging.html#composite-type-descriptors DIBuilder::createSubroutineType seems to generate metadatas with a different format. Thanks! Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/70facf50/attachment.html>

...of a pointer type, which could then be used as the type of a variable, without any actual function at all. To build corresponding debug info, I must: 6. Build a llvm::DIArray, using llvm::getOrCreateArray, from the results of 4. 7. Build a llvm::DIComposite type for the function, using llvm::createSubroutineType, from the result of 6. 8. Build a llvm::DIFunction using llvm::createFunction, from the result of 7. Here, I need the formal values, with names, first, before building the function type. This appears to imply that, in debug info, the formal names are also part of the function type, which thus ca...

...due to this > check > in DebugInfo.cpp: > > 486 DICompositeType Ty = getType(); > 487 if (!Ty.Verify()) > 488 return false; > > Is it in fact wrong to pass a typedef here? > I can't come up with a way that'd be correct, no. You should be using createSubroutineType and passing that into the builder. Have example code where this is coming up? -eric

Hi David, I'm seeing an assertion failure when passing this node !{i32 786454, metadata <badref>, metadata <badref>, metadata !"fn_t", i32 5, i64 0, i64 0, i64 0, i32 0, metadata <badref>} ; [ DW_TAG_typedef ] [fn_t] [line 5, size 0, align 0, offset 0] [from ] as the function type parameter to DIBuilder::createFunction, due to this check in DebugInfo.cpp:

...pp: >> >> 486 DICompositeType Ty = getType(); >> 487 if (!Ty.Verify()) >> 488 return false; >> >> Is it in fact wrong to pass a typedef here? >> > > I can't come up with a way that'd be correct, no. You should be using > createSubroutineType and passing that into the builder. Have example > code where this is coming up? OK, it looks like a DW_TAG_typedef node defines a new type. If the original type is a subroutine type, I don't see why a typedef of it shouldn't be used anywhere the original could. After all, it is just...

On Thu, Aug 29, 2013 at 6:58 AM, Pan, Wei <wei.pan at intel.com> wrote: > Is anyone maintaining this page? ish. We sometimes forget to update it for a while. > http://llvm.org/docs/SourceLevelDebugging.html#composite-type-descriptors > > > > DIBuilder::createSubroutineType seems to generate metadatas with a different > format. composite types recently got one new field (a string unique identifier) & the template arguments field was made non-optional. Were there other differences you noticed/were referring to?

...metamata doc? On Thu, Aug 29, 2013 at 6:58 AM, Pan, Wei <wei.pan at intel.com> wrote: > Is anyone maintaining this page? ish. We sometimes forget to update it for a while. > http://llvm.org/docs/SourceLevelDebugging.html#composite-type-descript > ors > > > > DIBuilder::createSubroutineType seems to generate metadatas with a > different format. composite types recently got one new field (a string unique identifier) & the template arguments field was made non-optional. Were there other differences you noticed/were referring to?

...>>>> 487 if (!Ty.Verify()) >>>> 488 return false; >>>> >>>> Is it in fact wrong to pass a typedef here? >>>> >>> >>> I can't come up with a way that'd be correct, no. You should be using >>> createSubroutineType and passing that into the builder. Have example >>> code where this is coming up? >> >> >> OK, it looks like a DW_TAG_typedef node defines a new type. If the original >> type is a subroutine type, I don't see why a typedef of it shouldn't be used >>...

...DICompositeType Ty = getType(); >>> 487 if (!Ty.Verify()) >>> 488 return false; >>> >>> Is it in fact wrong to pass a typedef here? >>> >> >> I can't come up with a way that'd be correct, no. You should be using >> createSubroutineType and passing that into the builder. Have example >> code where this is coming up? > > > OK, it looks like a DW_TAG_typedef node defines a new type. If the original > type is a subroutine type, I don't see why a typedef of it shouldn't be used > anywhere the original co...

...f (!Ty.Verify()) >>>>> 488 return false; >>>>> >>>>> Is it in fact wrong to pass a typedef here? >>>>> >>>> >>>> I can't come up with a way that'd be correct, no. You should be using >>>> createSubroutineType and passing that into the builder. Have example >>>> code where this is coming up? >>> >>> >>> OK, it looks like a DW_TAG_typedef node defines a new type. If the original >>> type is a subroutine type, I don't see why a typedef of it shouldn'...

...;>>> 488 return false; >>>>>> >>>>>> Is it in fact wrong to pass a typedef here? >>>>>> >>>>> >>>>> I can't come up with a way that'd be correct, no. You should be using >>>>> createSubroutineType and passing that into the builder. Have example >>>>> code where this is coming up? >>>> >>>> >>>> OK, it looks like a DW_TAG_typedef node defines a new type. If the original >>>> type is a subroutine type, I don't see why a typed...