[PATCH] D16440: [ThinLTO] Link in only necessary DICompileUnit operands
Duncan Exon Smith via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 29 06:09:03 PST 2016
> On Jan 29, 2016, at 5:47 AM, Teresa Johnson <tejohnson at google.com> wrote:
>
> tejohnson added a comment.
>
>>> I think so. At least for composite types. Are there any cases, other than from the retainedTypes list on the compile unit, where a DICompositeType node is referenced by its address rather than by UUID?
>
>
>
>> Try types without a mangled name - I suppose one example might be something like:
>
>
>> a.cpp:
>
>> void b();
>
>> int main() {
>
>
>> b();
>
>
>> }
>
>
>> b.cpp:
>
>> namespace {
>
>> struct anon {
>
>> };
>
>> void bimpl(anon) {
>
>> }
>
>> }
>
>> void b() {
>
>
>> bimpl(anon());
>
>
>> }
>
>
>> If bimpl is imported into a (presumably after b is imported into a) then you'll see a type without a mangled name... what you should do with this is perhaps a difficult question. A debugger's going to have a hard time identifying these types (or even the two 'bimpl' functions) as the same when they're in two different object files & flagged as being "local" entities...
>
>
> Confirmed that in this case, the composite type for anon is in the subroutine type list for bimpl, and that when we import bimpl into a.cpp we therefore import the full composite type definition.
>
> It isn't clear to me from your last sentence what we should do here. Does having the full type definition imported make it easier or harder for the debugger?
>
> Thanks,
> Teresa
You need the full type definition when the DICompositeType has no uuid (the identifier: field).
>
>
>
>> - Dave
>
>
>
> http://reviews.llvm.org/D16440
>
>
>
More information about the llvm-commits
mailing list