[llvm] r328805 - Reapply "[DWARFv5] Emit file 0 to the line table."

[David Blaikie via llvm-commits]

Sure thing - filed PR40538 & thanks for the quick/interim fix! :)

On Wed, Jan 30, 2019 at 12:08 PM <paul.robinson at sony.com> wrote:

> Yeah… no clue why we were seeing that difference in behavior.
>
> The positive side of the llvm-mc top-level bit of code is that it will add
> in the MD5 hash to the line table.  Which argues that it ought to be in
> cc1as as well.  You'd think the llvm-mc bit would have superseded what the
> AsmParser method is up to.  But… but… I can't take time to look deeper
> right now.
>
>
>
> So if you could do me the favor of filing a PR and assign me to it, then
> we both have a chance of keeping track of this questionable solution until
> I can back to things that are merely top priority as opposed to
> hard-deadline-in-three-days.
>
> Thanks,
>
> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* Wednesday, January 30, 2019 1:52 PM
>
>
> *To:* Robinson, Paul
> *Cc:* llvm-commits at lists.llvm.org
> *Subject:* Re: [llvm] r328805 - Reapply "[DWARFv5] Emit file 0 to the
> line table."
>
>
>
> Tried this with clang, seems to not crash where it used to - thanks!
>
> I'm a bit confused/surprised by the fix - it's one of the paths I went
> down/considered, but when I found that llvm-mc wasn't crashing (at least
> for me - I'm still confused why it was crashing for you and not for me) I
> looked to see why & found the "setMCLineTableRootFile" which llvm-mc still
> calls, but clang does not. Is this function needed/correct? Should it be
> removed from both codepaths, or added to cc1_as for symmetry (more than
> aesthetic symmetry, but some functional symmetry?)?
>
>
>
> On Tue, Jan 29, 2019 at 12:58 PM <paul.robinson at sony.com> wrote:
>
> My clang problems turned out to be pilot error.  Try r352541 and let me
> know.
>
> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* Monday, January 28, 2019 7:47 PM
>
>
> *To:* Robinson, Paul
> *Cc:* llvm-commits at lists.llvm.org
> *Subject:* Re: [llvm] r328805 - Reapply "[DWARFv5] Emit file 0 to the
> line table."
>
>
>
>
>
> On Mon, Jan 28, 2019, 4:27 PM <paul.robinson at sony.com wrote:
>
> I have llvm-mc working on empty (or comment-only) source, but not clang
> yet.
>
> Are you possibly using a Release build? the crashes I see are assertions.
>
> I've been running on a full debug build, including assertions. :/
>
> Will keep on it tomorrow.
>
> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* Monday, January 28, 2019 2:44 PM
> *To:* Robinson, Paul
> *Cc:* llvm-commits at lists.llvm.org
> *Subject:* Re: [llvm] r328805 - Reapply "[DWARFv5] Emit file 0 to the
> line table."
>
>
>
>
>
> On Mon, Jan 28, 2019 at 11:12 AM <paul.robinson at sony.com> wrote:
>
> Hey Paul,
>
> I've been experimenting with DWARFv5 broadly applied to some code at
> Google & found that clang crashes when trying to emit DWARFv5 on an empty
> assembly file. Turns out llvm-mc does not because of the above code block.
>
> Seems this support is here for llvm-mc, but missing from clang's
> initialization of MCContext for cc1as.
>
> Could you refactor/common/add equivalent functionality to Clang's cc1as?
> (looks like somewhere near clang/tools/driver/cc1as_main.cpp:400? (since
> that is where "setMainFileName" is, which is near this block in llvm-mc
> too))
>
> - Dave
>
> You mean, like a zero-length file?  For me, `llvm-mc –g t.s` also crashes
> with that.  Or a .s file with only a comment in it.
>
>
> Hmm, llvm-mc doesn't seem to crash for me...
>
>
> Looks like clang and llvm-mc crash in different places too.
>
>
>
> Maybe different default targets, etc? Not sure.
>
>
>
>  I'll take a look.
>
>
> Thanks!
>
>
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190130/055420c1/attachment.html>