You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rollup merge of rust-lang#37410 - TimNN:gdb-next-gen, r=alexcrichton
Support GDB with native rust support
This PR aims at making the debuginfo tests pass with the newer GDB versions which have native rust support (RGDB)
To that end debuginfo tests now support three GDB prefixes:
- `gdb` applicable to both GDB varieties
- `gdbg` (**G**eneric) only applicable to the old GDB
- `gdbr` (**R**ust) only applicable to the new RGDB
Whether the GDB has rust support is detected based on it's version: GDB >= 7.11.10 is considered to have rust support.
---
**Test updates**
All tests have been updated to the new GDB version. Note that some tests currently require the GDB trunk<sup>1</sup>.
---
**How to move forward with this PR:**
I propose the following steps for moving forward with this PR:
- [x] Validate the general approach of this PR (the `gdb-`, `gdbg-` and `gdbr-` split)
- [x] Validate the approach taken for updating the debuginfo tests (I've checked this since there's (almost) no `set language c` left, which was my main concern)
- [x] Determine how to distinguish between the new and old GDB (and implement that)
- [ ] Add one or more non-gating build bots with the new GDB (blocked on the previous item, can happen after this PR has been merged)
- [ ] If the new bots pass the tests, gate on them
- [x] \(Maybe) update the remaining tests to run without `set syntax c` (in a separate PR)
- [ ] \(Maybe) add tests specifically for the new GDB (in a separate PR / open an issue about this)
I'm not completely sure about the build bot related steps (cc @alexcrichton), the current approach was suggested to prevent any downtime / broken build time between a new GDB gating builder being added and this PR being merged.
---
**Suboptimal RGDB Output**
I've found several places where the output of RGDB is not ideal. They are tagged with `// FIXME`, here is an overview:
- [x] Trait references are not syntactically correct: `type_names::&Trait2<...>` (**WontFix**: the issue is minor and from @Manishearth below: "to properly address the trait issue we should wait for trait object support")
- [x] Univariant enums are printed as `<error reading variable>` (**Fixed** in GDB trunk<sup>1<sup>)
- [x] Unions are printed as `<error reading variable>` (**Fixed** in GDB trunk<sup>1</sup>)
- [x] "Nil Enums" (`enum Foo {}`) are printed as `<error reading variable>` (**WontFix**: the are not supposed to exist)
- [x] I have found no alternative for `sizeof(var)` in rust mode, so had to resort to `set language c` (**Fixed** in GDB trunk<sup>1</sup>)
- [x] I have found not way of interpreting a value as a specific enum variant, so had to resort to `set language c` (**Fixed** in GDB trunk<sup>1</sup>)
- [x] Before the initial `run` command, gdb does not realise it should be in rust mode (thus, if one want's to print statics before the run one has to explicitly `set language rust`) (maybe this is intended / expected behaviour, if so, someone please tell me ;) (**"Expected"** / current behaviour of GDB: picks up jemalloc, see rust-lang#37410 (comment))
<sup>1</sup>: Or rather in @Manishearth's trunk, waiting to be merged upstream.
---
cc @alexcrichton, @michaelwoerister, rust-lang#36323
0 commit comments