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

[via llvm-commits]

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<mailto: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<mailto:dblaikie at gmail.com>]
Sent: Monday, January 28, 2019 7:47 PM

To: Robinson, Paul
Cc: llvm-commits at lists.llvm.org<mailto: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<mailto: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<mailto:dblaikie at gmail.com>]
Sent: Monday, January 28, 2019 2:44 PM
To: Robinson, Paul
Cc: llvm-commits at lists.llvm.org<mailto: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<mailto: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/431bf086/attachment.html>