Investigate performance of `exit_after` approaches

[hintron]

There are a few approaches for checking exit_after - I'm curious which one is better.

One way is to match outside the loop first to see if it's set, then if it is, check it inside the loop.

Another way (the current method) is to match inside the loop for existence and do the check at the same time.

I've been trying to do this, but I can't seem to correlate the assembly created by cargo asm with the debugger assembly. The instructions and stack offsets are slightly different, and I'm not sure why.

[pacak]

The instructions and stack offsets are slightly different, and I'm not sure why.

If we are talking about cargo-show-asm - currently it compiles everything with a single codegen unit, if that's a problem - I can try looking into changing that. Recent rustc makes some things a bit easier.

[hintron]

@pacak Ok, I see now that even though I have the same cargo build profile selected for both the LLDB debugger in VSCode and for cargo-show-asm, when I alternate between the two, they are being rebuilt every time.

E.g. my launch.json file specifies this for the VSCode LLDB plugin:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "RTOS simulator release-with-debug",
            "cargo": {
                "args": [
                    "build",
                    "--profile=release-with-debug",
                    "--bin=emu86rs",
                    "--package=emu86rs"
                ],
                "filter": {
                    "name": "emu86rs",
                    "kind": "bin"
                }
            },
...

and when I launch this debug run it does

Running `cargo build --profile=release-with-debug --bin=emu86rs --package=emu86rs --message-format=json`...
   Compiling emu86rs v0.1.0 (/home/hintron/code/computer-enhance/emu86rs)
    Finished release-with-debug [optimized + debuginfo] target(s) in 11.40s

Afterwards, when I run cargo asm, like so:

cargo asm \
-p emu86rs \
--profile=release-with-debug \
--color \
--rust \
--att \
--lib \
--simplify \
--everything \
> everything.lst

I get

cargo asm -p emu86rs --profile=release-with-debug --color --rust --att --lib --simplify --everything > everything.lst
   Compiling emu86rs v0.1.0 (/home/hintron/code/computer-enhance/emu86rs)
    Finished release-with-debug [optimized + debuginfo] target(s) in 22.74s

What I'm confused about is that they share the same cargo build profile - release-with-debug. Do you know why it forces a rebuild? Is this because of the single codegen unit? What can I do to make these two builds actually match, so that I have assembly with interleaved Rust code that matches what my debugger is running?

Hopefully that makes sense; Thanks for the great tool!

[pacak]

Currently I pass -Ccodegen-units=1 to rustc to avoid solving the hard problem of figuring out what is the same, Adding codegen-units = 1 to your profile in Cargo.toml might help for now. I'll take a look at fixing this.

[pacak]

I'll take a look at fixing this.

That would be nope. Got as far as this https://github.com/pacak/cargo-show-asm/pull/253 - it mostly works when job generates an rlib file and doesn't work with other files. Started this - https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477/1

[hintron]

Btw setting codegen-units = 1 seems to work - the stack offsets and instructions appear to be 1:1 between the debugger asm and cargo asm. Thanks!