Skip to content

Ignore functions before main and thread entry points in backtraces #47824

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Jan 28, 2018

Split out from #45637.

r? @alexcrichton

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 28, 2018
@Zoxc Zoxc force-pushed the backtraces branch 3 times, most recently from ad90937 to ff74477 Compare January 28, 2018 16:19
}

/// Convenience wrapper for `mark_start`
#[unstable(feature = "rt", reason = "this is only exported for use in libtest", issue = "0")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this reason be updated as I think this is used by threading/main now, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are private usages in libstd though, which do not require an export.

fn mark_start(f: &mut FnMut()) {
f();
unsafe {
asm!("" ::: "memory" : "volatile"); // A dummy statement to prevent tail call optimization
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may not compile on platforms like asm.js, so I wonder if we could take a perhaps different route to implement this? Could this call a #[inline(never)] function which doesn't throw using the notail attribute on the call? I think that'd do the same thing, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

f may throw here, so we cannot use notail. We need something that is opaque to LLVM. I suggest we just disable this asm! expressions on platforms which do not support it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes indeed that's why we can't notail the call to f, but I"m thinking something like:

fn mark_start(f: &mut FnMut()) {
    f();
    #[notail]
    foo();

    #[inline(never)]
    fn foo() {}
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LLVM could still see that foo has no side effect, and just remove the call.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah indeed, in that case could something more portable than asm! be used, like volatile reads or something like that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think volatile operations will work as they could be reordered to happen before the call to f, if f contains no volatile operations itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does LLVM accept empty inline assembly for asm.js?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK no we disable inline assembly completely on asm.js. Does the reordering actually happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was asking about LLVM not rustc though. I do not know if the reordering could happen given LLVM's current optimizations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least in the tests I was running it wasn't reordering, but I'm not sure if that's a guarantee? I figure we could at least try it as this'll need to be upgraded for emscripten anyway.

@bors
Copy link
Collaborator

bors commented Feb 6, 2018

☔ The latest upstream changes (presumably #48040) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 6, 2018
@shepmaster
Copy link
Member

Ping from triage, @Zoxc — will you be able to address the merge conflicts sometime soon? I'm not sure if @alexcrichton wanted you to make changes or not, either...

@pietroalbini
Copy link
Member

@Zoxc closing this PR due to inactivity, feel free to open it again when you have some spare time to work on it!

@jonhoo
Copy link
Contributor

jonhoo commented Feb 26, 2018

This would be a really welcome change -- are we sure we want to close this? I guess if there's no-one else to pick it up either?

@shepmaster
Copy link
Member

This would be a really welcome change -- are we sure we want to close this

Anyone is certainly welcome to pick up from when this PR was closed! If fixing it excites you, I say to go for it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants