[llvm-dev] [cfe-dev] RFC: CodeView debug info emission in Clang/LLVM

[David Blaikie via llvm-dev]

On Thu, Mar 10, 2016 at 9:24 AM, Reid Kleckner <rnk at google.com> wrote:

> On Thu, Mar 3, 2016 at 10:26 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> I think it'd be reasonable to at least figure out a good way to do type
>> references consistently across the two schemes, but I'm OK with the idea of
>> having a blob of opaque type information for different debug info formats,
>> created by frontends (& don't mind if the library for building that blob
>> live in LLVM or Clang for now - the DWARF one at least would probably live
>> in LLVM because type info and other DWARF are described by similar/the same
>> constructs (DIEs, abbrevs, etc) - but it seems like that's not the case for
>> PDB, so there might not be any code to share between LLVM's CodeView needs
>> and the type info construction - then it's just a matter of whether pushing
>> that library down into LLVM for other frontends to use would be good, which
>> it probably will be at some point, so if it goes into Clang I'd at least
>> try to keep it pretty well separated)
>>
>> Potentially that consistency could be created by going the other way -
>> replace DITypeRef with an int, then have the retained types list be the
>> int->type mapping. Skipping the mangled names. (& skip the retained types
>> list for CV/PDB)
>>
>
> DITypeRef wraps a Metadata*, though, not an int. Given that there are zero
> users of DITypeRef in Transforms/ and Analysis/, I don't see why we should
> try to forcibly create sharing where there is none. The only consumers of
> type information are essentially the separate debug info backends.
>

I haven't looked in detail at the patch - but it sounded like the proposal
was to add an int field next to every DITypeRef field? That seems
verbose/intrusive to the schema compared to making the type reference
machinery able to be one or the other (or is the proposal to have DITypeRef
fields be a union of int or DITypeRef (then the DITypeRef itself is a union
of metadata reference or string)? If we already have a union of metadata or
string, it seems like the better thing to do would be to make it metadata,
string, or int rather than having two different layers for referring to
types)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160310/894ae06c/attachment.html>