nightly does not produce dSYM files at all on OSX #46346
Labels
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
C-bug
Category: This is a bug.
O-macos
Operating system: macOS
regression-from-stable-to-nightly
Performance or correctness regression from stable to nightly.
T-dev-tools
Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Comments
|
Can you run |
|
Confirmed as an issue for me too. Thanks @durka for submitting this after our exchange on IRC. |
|
@JohnColanduoni there is no dSYM file. Perhaps this is the issue :)
|
durka
changed the title
|
kennytm
added
A-debuginfo
|
I'm not able to reproduce this locally myself, can those who can reproduce this provide more info like an XCode version? Also what happens when you run |
|
I'm on OSX 10.9.5, with XCode 6.2. |
|
OS X 10.13.1, Xcode 9.1. Example dsymutil output (on a test binary): |
|
@alexreg that's all of it, just warnings without errors? |
|
It looks like this may just be a resurgence of #45511, when running cc @philipc, mind helping to take a look here to see if it's the same issue as before? |
|
Is there a way to turn off ThinLTO for testing? I already tried |
|
No unfortunately this has to do with a libstd/libtest that is compiled with ThinLTO, nothing to down with downstream options. |
|
Ah I see. Well if I can test something by building a compiler locally let me know. |
|
One thing I don't understand is that CI is passing which at least at one point relies on filenames/line numbers in backtraces on OSX, so I don't know how that's working... |
|
Which test is that?
…On Wed, Nov 29, 2017 at 6:07 PM, Alex Crichton ***@***.***> wrote:
One thing I don't understand is that CI is passing which at least at one
point relies on filenames/line numbers in backtraces on OSX, so I don't
know how that's working...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46346 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC3nxfrQg6mi1TxDHHsKZgUkHrfew1tks5s7eOggaJpZM4Qt5YP>
.
|
|
dsymutil does segfault according to gdb, FWIW, though it somehow avoid printing "Segmentation fault" so it looks like the output just ends abruptly. |
|
Running the command from #45511: |
|
@durka Yeah, that's all of it. |
|
I've verified that the error from #45511 has been fixed for the minimal test case we had, but the error is still occurring for other code. Running the following gives about 6 files with offset errors: The patch I did for #45511 fixed a problem with references within the abstract subprogram DIE, but the errors I'm seeing here are within non-inlined subprogram DIEs. So we'll need another LLVM patch. I'm worried that patching this in the same way isn't going to give any assurance that we've fixed all the cases in which this can occur. |
|
@philipc ah that's unfortunate :( I agree yeah that we may be chasing this for awhile, but out of curiosity do you know if a patch in LLVM for this bug would be a small/easy one? If so that may be the best way to go for now at least in the short term perhaps? |
|
I expect it will be small, similar to the last patch. |
|
Ok, nice! Would you be willing to help draw that up? I can try to help stir up action on the LLVM side of things to land it upstream. |
|
Yes I'll look into it. |
|
@philipc awesome, thanks! |
arielb1
added
the
T-dev-tools
|
Here's a reduced IR (from creduce/bugpoint/hand reduction). This may not be fully reduced, but it's hard to reduce further without understanding more about when the problem occurs. I've found where I think it's going wrong, but it's not as easy to fix the same way. For #45511, the problem was this The previous fix was to switch from using |
|
Another problem is that the unit that was specified for the |
|
@philipc ok thanks for the investigation! I think maybe leaving a comment on the previous LLVM issue is a good place to start? As a side note, do you know if it'd be possible to post-process IR and remove all debuginfo codegen units except one? It seems like this is pretty problematic behavior and forcing everything to be part of the same codegen unit may not be that bad in terms of debuginfo? |
|
@alexcrichton If the codegen units are all from the same crate, then that's probably possible and even desirable, but my understanding of LLVM is lacking here. However, if we're doing ThinLTO for codegen units from multiple crates then I don't think that will work well. |
|
Ah yeah my thinking is that after we do all ThinLTO optimizations we could rewrite all the debuginfo to point to the same codegen unit (the codegen unit for that ThinLTO module). This would run the risk of messing up inlined debuginfo but optimized debuginfo in LLVM is always pretty bad anyway right now... I'm just not sure, though, how to take an LLVM module and postprocess it to change the debuginfo. |
bors
added a commit
that referenced
this issue
Dec 2, 2017
rustc: Prepare to enable ThinLTO by default This commit *almost* enables ThinLTO and multiple codegen units in release mode by default but is blocked on #46346 now before pulling the trigger.
|
I've filed an upstream LLVM bug for this, @philipc please feel free to leave any extra commments there! |
|
Do we need to worry about this slipping to beta/stable if upstream doesn't
act quickly? I don't want to hold up progress but is ThinLTO on macOS
viable right now if it effectively disables debugging? :(
…On Thu, Dec 7, 2017 at 1:25 PM, Alex Crichton ***@***.***> wrote:
I've filed an upstream LLVM bug
<https://bugs.llvm.org/show_bug.cgi?id=35562> for this, @philipc
<https://github.com/philipc> please feel free to leave any extra
commments there!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46346 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n4G0Vc360l4elPdUoY-k3TAexk0Pks5s-C2ygaJpZM4Qt5YP>
.
|
|
Yeah we for sure don't want this to slip to beta/stable. My plan is that if we're a week or so out from the next beta branch we'll turn off ThinLTO for libstd/libtest (or someone can do it sooner) which should fix the symptoms. Turning ThinLTO back on would then be blocked on fixing this issue. |
|
Sounds good, I guess we have almost a month until the next branch (1/4).
…On Thu, Dec 7, 2017 at 3:44 PM, Alex Crichton ***@***.***> wrote:
Yeah we for sure don't want this to slip to beta/stable. My plan is that
if we're a week or so out from the next beta branch we'll turn off ThinLTO
for libstd/libtest (or someone can do it sooner) which should fix the
symptoms. Turning ThinLTO back on would then be blocked on fixing this
issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46346 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC3nx9nZItomxxFO2y6CKoxu42hi3bTks5s-E4_gaJpZM4Qt5YP>
.
|
This was referenced Dec 16, 2017
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Dec 18, 2017
This commit implements a workaround for rust-lang#46346 which basically just avoids triggering the situation that LLVM's bug https://bugs.llvm.org/show_bug.cgi?id=35562 arises. More details can be found in the code itself but this commit is also intended to ... Closes rust-lang#46346
bors
added a commit
that referenced
this issue
Dec 21, 2017
rustc: Work around `DICompileUnit` bugs in LLVM This commit implements a workaround for #46346 which basically just avoids triggering the situation that LLVM's bug https://bugs.llvm.org/show_bug.cgi?id=35562 arises. More details can be found in the code itself but this commit is also intended to ... Closes #46346
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current report
Upstream LLVM bug
Original report
OSX backtrace line numbers, enabled in stable and beta, were lost (unintentionally???) starting with Thanksgiving's nightly.
Here are the commits.
Wild guess: was this caused by #46008 somehow? cc @alexcrichton
cc @JohnColanduoni
The text was updated successfully, but these errors were encountered: