[llvm-dev] Should DISubprogram's scope be allowed to be null?

[David Blaikie via llvm-dev]

On Fri, Jan 15, 2016 at 7:22 AM, Duncan P. N. Exon Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > On 2016-Jan-15, at 06:46, Keno Fischer <kfischer at college.harvard.edu>
> wrote:
> >
> > Looking at this again, I think I was under the mistaken impression that
> the DISubprogram's scope would have to be the compile unit, but it seems we
> also currently allow it to be a DIFile (or any other kind of scope). In
> that case, I suppose the behavior that the backend expects is that every
> DISubprogram is referenced from some DICompileUnit contained in
> llvm.dbg.cu. I'll implement a Verifier pass to that extent.
>
> Two things I remember:
> 1. There's difference between subprogram definitions and subprogram
> declarations.  Declarations seem to just be part of the type hierarchy.
> 2. Subprogram definitions need to be referenced from the compile units.
>
> IMO this link (2) should be reversed:  we should reference compile units
> from subprogram definitions (through a new cu: field) and drop the
> reference in the other direction.  This would be far more convenient for
> LTO (or llvm-link in general), but it causes a semantic change and I never
> worked through the implications of that.
>

I'd probably be OK with that.

Though I will note that I don't /think/ (2) is true right now, and I think
we actually violate (2) intentionally, perhaps.

Diego: To include line/col info for backend diagnostics, we produced debug
info but omitted the llvm.dbg.cu entry, right? So there are subprogram
debug info descriptions that are not referenced from a CU in llvm.dbg.cu,
yes?


>
> > On Fri, Jan 15, 2016 at 4:26 AM, Keno Fischer <
> kfischer at college.harvard.edu> wrote:
> > I'm looking at cases of disagreement between assertions in the backend
> and what the Verifier checks for (for http://reviews.llvm.org/D16083).
> One of these seems to be the question of whether a DISuprogram may exist
> without a DICompileUnit. Currently the Verifier doesn't care, but there are
> a few assertions to this extent in the backend.
> > Possible options are:
> >
> > 1) A DISubprogram may exist without a DICompileUnit (what would we have
> to change in the backend?)
> > 2) A DISubprogram's scope may be null, but only if there's a
> DICompileUnit that references it.
> > 3) A DISubprogram's scope may not be null, but the referenced
> DICompileUnit need not necessarily contain it
> > 4) A DISubprogram's scope may not be null, and the referenced
> DICompileUnit must contain it
> >
> > As far as I can tell, all of these would need some amount of changes to
> either existing code or existing test cases.
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160115/fe93c9cb/attachment.html>