Skip to content

Add some optimization options to our asm #12

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

Merged
merged 3 commits into from
May 29, 2020
Merged

Conversation

nelhage
Copy link
Contributor

@nelhage nelhage commented May 27, 2020

Since we don't actually emit code to speak of, we can let rustc/LLVM
know that we don't clobber anything, letting them avoid
saving/restoring registers or other state around the probe.

We can't mark the probe as pure, even though our code is pure,
since that would enable LLVM to delete it entirely (since we have no
outputs).

Since we don't actually emit code to speak of, we can let rustc/LLVM
know that we don't clobber anything, letting them avoid
saving/restoring registers or other state around the probe.

We can't mark the probe as `pure`, even though our _code_ is `pure`,
since that would enable LLVM to delete it entirely (since we have no
outputs).
@cuviper
Copy link
Owner

cuviper commented May 28, 2020

There's some tension here between what the assembly does (nothing) and what a debugger or other tool may do at that probe point (anything), and we need to strike a balance somehow. It's probably too extreme to try to deal with arbitrary writes in that respect, but reading memory from a probe seems reasonable -- so nomem should probably be readonly. Hopefully that will at least present a consistent memory state at this point.

@@ -181,7 +181,7 @@ macro_rules! sdt_asm(
#[doc(hidden)]
#[macro_export]
macro_rules! _sdt_asm(
($addr:tt, options $opt:tt, $provider:ident, $name:ident, $argstr:tt, $($arg:expr),*) => (
($addr:tt, options ($opt:tt), $provider:ident, $name:ident, $argstr:tt, $($arg:expr),*) => (
Copy link
Owner

Choose a reason for hiding this comment

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

I think this change won't work for non-x86 targets that are passing just options() here. Maybe we should use a complete repetition pattern, options ( $( $opt:ident ),* ).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right -- tested this on a non-x86 arch and it fails as you predict. Looking closer, though, do we actually need the att_syntax? If I remove it, it still builds for me on both 32- and 64-bit Linux x86, and as best I can tell everything we emit is either directives, which don't very with gas syntax, or a nop, which is perfectly valid Intel syntax. Removing that switch would certainly simplify things a bit.

Copy link
Owner

Choose a reason for hiding this comment

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

It matters for how the register is written in the probe note. When I first tried in the default (intel) syntax, GDB wasn't able to parse the probe argument correctly. Maybe GDB (and other tools!) could be taught otherwise, but then we'd only work with newer versions.

nelhage added 2 commits May 28, 2020 18:51
Make it hopefully easier for debuggers stopped at a probe to get a
consistent view of the world.
@nelhage
Copy link
Contributor Author

nelhage commented May 29, 2020

Fixed both comments. Tested building on:

  • aarch64-unknown-linux-gnu
  • i686-unknown-linux-gnu
  • x86_64-unknown-linux-gnu
  • arm-unknown-linux-gnueabi
  • wasm32-wasi

which I think should give good coverage of all the variants.

Thanks for the prompt response and feedback!

@cuviper
Copy link
Owner

cuviper commented May 29, 2020

Great, thanks!

I should probably add CI with target coverage like that...

@cuviper cuviper merged commit a38b971 into cuviper:master May 29, 2020
@cuviper
Copy link
Owner

cuviper commented May 29, 2020

BTW, is your use of this crate publicly visible?

@nelhage nelhage deleted the asm-flags branch May 29, 2020 19:18
@nelhage
Copy link
Contributor Author

nelhage commented May 29, 2020

Sort of. I was playing with it for https://github.com/nelhage/ultimattt -- I've been working on solving https://en.wikipedia.org/wiki/Ultimate_tic-tac-toe as a quarantine side project.

Unfortunately I backed off from using rust-libprobe for the moment because of the dependency on a bleeding-edge nightly compiler and did something ad-hoc based on injecting ELF symbols with special names: https://github.com/nelhage/ultimattt/blob/863fdfe2d47cf5faac5b1a785fd80fa2d85ed659/src/lib/prove/pn_dfpn.rs#L242-L257

I'll probably switch back to this crate once it's possible to get a nightly build that supports both new-style ASM and has rustfmt available (As of this writing, seems nightly builds aren't shipping rustfmt, presumably because something broke: https://rust-lang.github.io/rustup-components-history/)

@cuviper
Copy link
Owner

cuviper commented May 29, 2020

(As of this writing, seems nightly builds aren't shipping rustfmt, presumably because something broke: https://rust-lang.github.io/rustup-components-history/)

That should be fixed on the next nightly: rust-lang/rust#72671 (comment)

And hopefully the new asm! will actually be on a path to stabilization now... we'll see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants