Debugging support in rustc by amanjeev · Pull Request #316 · rust-lang/rustc-dev-guide (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation63 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This is still work-in-progress but I wanted to open a PR for an early review to see if I am on the right path (also suggested by @spastorino).
This document is built on top of https://www.youtube.com/watch?v=elBxMRSNYr4 by @tromey.
For the sake of simplicity, I have added this document at the top level. Please advise if this should be under a directory or group of docs.
- Add explanation to note that this document is about debugging Rust code rather than debugging the compiler itself.
- Add first questions inline to the code on this PR for missing details and my confusions.
- CHECK What is SIP and link to it.
- Add the description of what is debugger etc. in preliminary section.
- Create Youtube's subtitles using this comment. (I personally find the auto-generated text to be horrible)
- Add TODOs for pending answers and iterate (as discussed with @mark-i-m and folks in WG-Learning meeting on 2019-06-11)
This issue has been assigned to @amanjeev via this comment.
I would add this as a subsection under the Debugging the Compiler chapter in Part 1.
I would add this as a subsection under the
Debugging the Compilerchapter in Part 1.
Now that I look at this, I wonder if it is ok as a subsection, given this is pretty long.
I mean, still in it's own file as it currently is, just indexed under the debugging chapter.
| #### Parser extensions |
|---|
| Expression parser has a couple of extensions [TODO: Where are the extensions???] in it |
| to facilitate features that you cannot do with Rust [TODO: CHECK: Find out what cannot be done?]. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what cannot be done but this was mentioned by @tromey in the video. Perhaps he did explain later which I have noted in this document below, but I still am not sure if there is something more to this.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gdb's Rust extensions and limitations are documented in the gdb manual: https://sourceware.org/gdb/onlinedocs/gdb/Rust.html -- however, this neglects to mention that gdb convenience variables and registers follow the gdb $ convention, and that the Rust parser implements the gdb @ extension.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
however, this neglects to mention that gdb convenience variables and registers follow the gdb $ convention, and that the Rust parser implements the gdb @ extension.
@tromey do you think we should mention this part in the GDB-Rust document rather than this document so there is no duplication etc.?
| #### Name mangling changes |
|---|
| * New demangler in `libiberty` (gcc source tree). |
| * New demangler in LLVM or LLDB [TODO: CHECK: where is the demangler these days] |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tromey could you please help me find where this demangler is at the moment? Or do we even have one? Checking because you say @michaelwoerister (I think) says that we should change Rust's name mangling.
Very amateur question - What's the best way to turn off linkchecker while working with a document? It takes forever to reload the page with the changes locally.
@amanjeev Thanks :) I will try to get to this soon. It looks like there have already been some comments, so I will try to make it a quick review
Also, you have a merge conflict
@mark-i-m Sorry, I will try and resolve the conflicts and push again. I used to think I was good at this. lol
Not sure what's going on here. I see this build error but the pages exist. Do we need to increase the timeout maybe? Please help.
appendix/code-index.md#11: There was an error while fetching "https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html", https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html: timed out```
Yes, I’ve been seeing a lot of those timeouts recently. I think it is travis rate limiting us. It seems to be a different link every time. @pietroalbini any ideas?
Seems I cannot re-run Travis builds without a commit? What are some of the other options to do that?
I can rerun travis builds, but I tried that on a previous PR and it doesn't solve the problem (there will be a timeout on another link). I would like to hear if the infra team has any ideas here.
Yes, I’ve been seeing a lot of those timeouts recently. I think it is travis rate limiting us. It seems to be a different link every time. @pietroalbini any ideas?
Those are spurious network issues, we also see them on rustc when talking with AWS (like S3 or a CloudFront-backed domain like doc.rust-lang.org). They're aware of it as far as I can tell, but there doesn't seem to be that much progress.
So meanwhile someone will be sitting at their desk clicking the "Re-run build" button. I do not envy you @mark-i-m 😄
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@amanjeev Thanks for your patience and your hard work. Overall LGTM. I left a bunch of small nits. After those are fixed, r=me :)
Also watch out because github likes to "Helpfully" collapse comments...
@mark-i-m I am unaware of what r=me means but this is all yours now, I think. Please check.
@amanjeev It looks good to me! Let's ship it 
I am unaware of what r=me means...
In the rust-lang/rust repo, where bors controls the PR queue, reviewers leave comments like @bors r+ or @bors r=mark-i-m to indicate that they approve the PR and it should be merged by bors. Thus it became a convention that r=me means "I will approve this" usually with some small request attached (e.g. rust-lang/rust#61626 (review)).
@amanjeev I tried to rebase and resolve the conflicts, but somewhere along the way there were a few very weird merge conflicts, so I just squashed all commits and rebased on the current master. When travis turns green, I will merge.
@mark-i-m thank you so much! I am so happy this is merged! 🎉
