Enable debug for all release, attach console for windows.[CPP-380][CPP-384]

[john-michaelburke]

Implements

• Debug symbols enabled by default
• Now have a stripped artifact and an additional "-debug" artifact created and stored in CI.
  https://github.com/swift-nav/console_pp/actions/runs/1409567717
• Was able to verify the debug symbols work as intended on Linux/Mac but not too sure about Windows.

Risks

Since rust is not building them for gnu, I have read you must rely on other tools for running the debug sessions. I tried Windgb but was not able to figure out how to set up the application to run with our symbols; however, the .pdb files are stored so maybe this is sufficient for now.

[john-michaelburke]

I wonder if this is related?
rust-lang/rust#41775

[silverjam]

Hrmm, weird, can we try split-debuginfo? https://doc.rust-lang.org/cargo/reference/profiles.html#split-debuginfo -- this way the debug info isn't embedded in the binary itself.

[john-michaelburke]

Hrmm, weird, can we try split-debuginfo? https://doc.rust-lang.org/cargo/reference/profiles.html#split-debuginfo -- this way the debug info isn't embedded in the binary itself.

Alright false alarm. I was not running thread apply all bt to get the debug info from all threads and it looks like this is working.

That being said we currently globally disable debug info in our CI (unless this flag would supersede RUSTFLAGS?). Should I restrict that to only the benchmarks/code quality check so we have this enabled in built releases? @silverjam

[silverjam]

Hrmm, weird, can we try split-debuginfo? https://doc.rust-lang.org/cargo/reference/profiles.html#split-debuginfo -- this way the debug info isn't embedded in the binary itself.

Alright false alarm. I was not running thread apply all bt to get the debug info from all threads and it looks like this is working.

That being said we currently globally disable debug info in our CI (unless this flag would supersede RUSTFLAGS?). Should I restrict that to only the benchmarks/code quality check so we have this enabled in built releases? @silverjam

Yeah, we can leave it disabled for everything except for the installer/release build, we should still try split-debuginfo too

[john-michaelburke]

Hrmm, weird, can we try split-debuginfo? https://doc.rust-lang.org/cargo/reference/profiles.html#split-debuginfo -- this way the debug info isn't embedded in the binary itself.

Alright false alarm. I was not running thread apply all bt to get the debug info from all threads and it looks like this is working.
That being said we currently globally disable debug info in our CI (unless this flag would supersede RUSTFLAGS?). Should I restrict that to only the benchmarks/code quality check so we have this enabled in built releases? @silverjam

Yeah, we can leave it disabled for everything except for the installer/release build, we should still try split-debuginfo too

split-debuginfo requires nightly it seems at least for linux AFAICT

[silverjam]

Hrmm, weird, can we try split-debuginfo? https://doc.rust-lang.org/cargo/reference/profiles.html#split-debuginfo -- this way the debug info isn't embedded in the binary itself.

Alright false alarm. I was not running thread apply all bt to get the debug info from all threads and it looks like this is working.
That being said we currently globally disable debug info in our CI (unless this flag would supersede RUSTFLAGS?). Should I restrict that to only the benchmarks/code quality check so we have this enabled in built releases? @silverjam

Yeah, we can leave it disabled for everything except for the installer/release build, we should still try split-debuginfo too

split-debuginfo requires nightly it seems at least for linux AFAICT

Ah, bummer-- we'll need to make a copy of the binary then call strip to remove the debug info

[silverjam]

We need automation that does two things:

• Copies the output binary into the artifacts for the release so that we can use this to debug crashes in the future
• Calls strip on the binary to remove the debug info before it's packaged into the app distribution

I think we can wait to see where @notoriaga's PR #146 lands before finalizing this

[john-michaelburke]

• Now have an additional "-debug" archive created and stored which has the non-stripped distributions.
  https://github.com/swift-nav/console_pp/actions/runs/1409567717
• Was able to verify the debug symbols work as intended on Linux/Mac but not too sure about Windows.

Since rust is not building them for gnu, I have read you must rely on other tools for running the debug sessions. I tried Windgb but was not able to figure out how to set up the application to run with our symbols; however, the .pdb files are stored so maybe this is sufficient for now.

[silverjam]

@john-michaelburke can you update the PR summary with your last comment please?

[silverjam]

We should just make the entrypoint program output an exe called "swiftnav-console" rather than renaming it

[silverjam]

We need pdb files for each file that we want to debug, so in addition to entrypoint pdb we'll need the pdb file for the backend

[john-michaelburke]

I also removed the line that was previously removing .pdb files. But I'm not seeing anything related to the backend so I may need to dig around more.

[silverjam]

The pdb for the backend is probably going to be the Rust target/release folder, or it might be in the build directory for Python module

[silverjam]

Or... it could be a issue with PyO3 setuptools integration, maybe it's not reading the Cargo.toml profile? Maybe we need to enable this differently in the setup.py for the backend?

[john-michaelburke]

The question now is where should I copy it to? Just the Scripts folder with the swiftnav_console.exe/.pdb?

[silverjam]

should be copied alongside the console_backend python module in the site-packages directory