Skip to content
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

Don't merge vtables when full debuginfo is enabled. #107373

Merged

Conversation

michaelwoerister
Copy link
Member

This PR makes the compiler not emit the unnamed_addr attribute for vtables when full debuginfo is enabled, so that they don't get merged even if they have the same contents. This allows debuggers to more reliably map from a dyn pointer to the self-type of a trait object by looking at the vtable's debuginfo.

The PR only changes the behavior of the LLVM backend as other backends don't emit vtable debuginfo (as far as I can tell).

The performance impact of this change should be small as measured in a previous PR.

@rustbot
Copy link
Collaborator

rustbot commented Jan 27, 2023

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 27, 2023
@WaffleLapkin
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jan 27, 2023

📌 Commit e5995e6 has been approved by WaffleLapkin

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 27, 2023
@Mark-Simulacrum
Copy link
Member

@michaelwoerister are we at all concerned that this makes it more likely that enabling debug info changes behavior, e.g., if investigating a bug related to vtable deduplication (such as when hashing pointers)?

@michaelwoerister
Copy link
Member Author

Interesting question -- I don't think we can guarantee that the difference in behavior won't ever make debugging a vtable-related compiler bug a bit harder. But it also doesn't seem like an obvious footgun to me. Do you have a concrete scenario in mind?

@Mark-Simulacrum
Copy link
Member

Not in particular, more of a vague worry when we make debug differ from optimized builds. It's probably unlikely to be a huge problem.

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 28, 2023
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#107022 (Implement `SpecOptionPartialEq` for `cmp::Ordering`)
 - rust-lang#107100 (Use proper `InferCtxt` when probing for associated types in astconv)
 - rust-lang#107103 (Use new solver in `evaluate_obligation` query (when new solver is enabled))
 - rust-lang#107190 (Recover from more const arguments that are not wrapped in curly braces)
 - rust-lang#107306 (Correct suggestions for closure arguments that need a borrow)
 - rust-lang#107339 (internally change regions to be covariant)
 - rust-lang#107344 (Minor tweaks in the new solver)
 - rust-lang#107373 (Don't merge vtables when full debuginfo is enabled.)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit c89bb15 into rust-lang:master Jan 28, 2023
@rustbot rustbot added this to the 1.69.0 milestone Jan 28, 2023
@michaelwoerister
Copy link
Member Author

I understand the concern. The behavior can easily be changed if it turns out to be a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants