Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
Collaborator

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.

# for free to join this conversation on GitHub. Already have an account? # 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