[PATCH] D16440: [ThinLTO] Link in only necessary DICompileUnit operands

[David Blaikie via llvm-commits]

On Fri, Jan 29, 2016 at 5:47 AM, Teresa Johnson via llvm-commits <
llvm-commits at lists.llvm.org> 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?
>

(probably as Duncan said, there's nothing else we can really do here other
than to have the full type definition imported)

As for what debuggers will do with this - I'm not really sure. I think
it'll hurt users a little bit, but don't know of any way to improve that
off hand.

(what I'm thinking might happen is that, when the user is evaluating
expressions within the context of the Compilation Unit that imported a
local function (or non-local function using a local type, not sure how we
emit that, maybe it still looks like a local function) from another CU,
it'll find the imported local, probably discover that it has no definition
(because it was only imported for inlining, etc - the definition would
never be emitted here), and be unable to call it in the expression
evaluator because it wouldn't know that the local function in another CU is
the same function)

Not sure whether local types would present the same/similar issues - they
could introduce strange name lookup situations for example:

a.cpp:
namespace a {
namespace {
struct foo { int a; };
}
}
void f1() {
  a::foo f;
}

b.cpp:
namespace {
struct foo { float b; };
}
namespace a {
void f2() {
  f1();
  foo f;
}
}

f1 is imported into the b.cpp module, along with the types necessary to
describe it.

So now b.cpp's debug info looks like this:
namespace {
struct foo { float b; };
}
// f1
namespace a {
struct foo { int a; };
void f2() {
  f1();
  foo f; // but miraculously, this 'foo' refers to ::foo, not a::foo
}
}

Now if the user is in the expression evaluator in f2 and refers to 'foo',
the debugger will find a::foo, even though the user is staring at code that
uses the unqualified 'foo' to refer to ::foo

I don't expect this sort of thing to be terribly common - but it's seems
technically possible to produce awkward debugging situations when importing
file-local entities. ("benign" violations of the ODR may cause other
problems, but our type uniquing by mangled name will probably already break
those in LTO at least, FWIW)


>
> Thanks,
> Teresa
>
> >
>
> >
>
> > - Dave
>
>
>
> http://reviews.llvm.org/D16440
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160129/a030f22c/attachment.html>