search for: diabbrev

...ng I'd talked >> about when writing all of this down. :) >> >> Basically to handle abbreviations you can do them the similarly to types >> by creating a blob with an index/hash/etc and then reference that as part >> of the type tuple, e.g.: >> >> $1 = { DIAbbrev: 0x1234, DIBlob: <blah> } >> $2 = { DIType: <ID>, DIAbbrev: $1, DIBlob: <blah> } >> >> and keep them uniqued during emission and remember to merge these as well >> during module merge time. >> > > Makes sense, but wouldn't you need multiple...

...new I was forgetting something I'd talked > about when writing all of this down. :) > > Basically to handle abbreviations you can do them the similarly to types > by creating a blob with an index/hash/etc and then reference that as part > of the type tuple, e.g.: > > $1 = { DIAbbrev: 0x1234, DIBlob: <blah> } > $2 = { DIType: <ID>, DIAbbrev: $1, DIBlob: <blah> } > > and keep them uniqued during emission and remember to merge these as well > during module merge time. > Makes sense, but wouldn't you need multiple abbreviations for each DIType...

...t; about when writing all of this down. :) >>> >>> Basically to handle abbreviations you can do them the similarly to types >>> by creating a blob with an index/hash/etc and then reference that as part >>> of the type tuple, e.g.: >>> >>> $1 = { DIAbbrev: 0x1234, DIBlob: <blah> } >>> $2 = { DIType: <ID>, DIAbbrev: $1, DIBlob: <blah> } >>> >>> and keep them uniqued during emission and remember to merge these as >>> well during module merge time. >>> >> >> Makes sense, but wou...

...gt; Thanks for reminding me, I knew I was forgetting something I'd talked about when writing all of this down. :) Basically to handle abbreviations you can do them the similarly to types by creating a blob with an index/hash/etc and then reference that as part of the type tuple, e.g.: $1 = { DIAbbrev: 0x1234, DIBlob: <blah> } $2 = { DIType: <ID>, DIAbbrev: $1, DIBlob: <blah> } and keep them uniqued during emission and remember to merge these as well during module merge time. > > Any other concerns there? >> * Debug information without type units might be slig...

...nding me, I knew I was forgetting something I'd talked about when writing all of this down. :) > > Basically to handle abbreviations you can do them the similarly to types by creating a blob with an index/hash/etc and then reference that as part of the type tuple, e.g.: > > $1 = { DIAbbrev: 0x1234, DIBlob: <blah> } > $2 = { DIType: <ID>, DIAbbrev: $1, DIBlob: <blah> } > > and keep them uniqued during emission and remember to merge these as well during module merge time. > > Makes sense, but wouldn't you need multiple abbreviations for each DITyp...

Thanks for sharing this. Mostly seems like a reasonable plan to me. A few comments below. On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi All, > > This is something that's been talked about for some time and it's probably > time to propose it. > > The "We" in this document is everyone on the cc line

Hi All, This is something that's been talked about for some time and it's probably time to propose it. The "We" in this document is everyone on the cc line plus me. Please go ahead and take a look. Thanks! -eric Objective (and TL;DR) ================= Migrate debug type information generation from the backends to the front end. This will enable: 1. Separation of