Uh oh!
There was an error while loading. Please reload this page.
[AVR] Correctly set the pointer address space when constructing pointers to functions - #73270
Merged
Merged
Conversation
rust-highfive
commented
Jun 12, 2020
Contributor
(rust_highfive has picked a reviewer for you, use r? to override) |
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
June 12, 2020 07:16
ea88e97 to
eba247cComparedylanmckay
commented
Jun 12, 2020
Uh oh!
There was an error while loading. Please reload this page.
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
June 12, 2020 07:35
eba247c to
70b3f99CompareUh oh!
There was an error while loading. Please reload this page.
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
June 12, 2020 11:51
70b3f99 to
da62082Comparerust-highfive
commented
Jun 12, 2020
Contributor
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
This was referenced Jun 14, 2020
Uh oh!
There was an error while loading. Please reload this page.
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
4 times, most recently
from
June 19, 2020 08:13
5a05b41 to
da4e901Comparerust-highfive
commented
Jun 19, 2020
Contributor
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
2 times, most recently
from
June 19, 2020 13:05
326b9d8 to
c44ea2cComparedylanmckay
marked this pull request as ready for review
June 19, 2020 13:06
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
June 19, 2020 13:26
c44ea2c to
9df636eComparebors
commented
Jun 19, 2020
Collaborator
☔ The latest upstream changes (presumably #73504) made this pull request unmergeable. Please resolve the merge conflicts. |
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
June 19, 2020 16:29
9df636e to
336322cComparebors
commented
Jun 20, 2020
Collaborator
☔ The latest upstream changes (presumably #73528) made this pull request unmergeable. Please resolve the merge conflicts. |
shepmaster
commented
Jun 20, 2020
Member
Can we remove the hacks we made to the formatters with this PR? |
dylanmckay
marked this pull request as draft
June 23, 2020 05:35
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
June 23, 2020 07:17
a3ff396 to
43d0a3aComparedylanmckay
commented
Jun 23, 2020
ContributorAuthor
I reverted 91bff8c from Rust master locally on top of this patch but then it breaks libcore So it looks like we cannot remove the hacks we made to the formatters in 91bff8c with this PR. |
dylanmckay
marked this pull request as ready for review
June 23, 2020 09:41
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
July 1, 2020 11:35
075eb4a to
d348ecaComparedylanmckay
marked this pull request as draft
July 1, 2020 11:40
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
July 1, 2020 11:47
d348eca to
5a3f398CompareContributorAuthor
NOTE: I'm keeping tags of all of the iterations of this patch so we can compare and/or pull anything back in. https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 |
Member
@dylanmckay is this still a draft? The implementation looks good to me… on a quick skim, anyway. |
dylanmckay
commented
Jul 15, 2020
ContributorAuthor
@nagisa I haven't got around to writing it up properly, but yeah the implementation is no longer a draft - this is about as minimal as I could get the patch using the "stop using pointercast, always use bitcast" approach. I prefer this current approach to the boilerplate-heavy one located at the The only thing left before sending this PR back to review is... writing tests for it. I will flip this out of draft once that is done. |
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
July 21, 2020 08:53
5a3f398 to
97b6b9bComparedylanmckay
marked this pull request as ready for review
July 21, 2020 17:14
…ers to functions This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch, the `type_i8p` method implcitily assumed the default address space, which is not a safe transformation on all targets, namely AVR. The Rust compiler already has support for tracking the "instruction address space" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation, around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch, the address space is always either 1) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there, or 2) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default, "data" address space.
…tated with the correct space Before this patch, a function pointer stored within an aggregate like a struct or an enum would always have the default address space `0`. This patch removes this assumption and instead, introspects the inner type being pointed at, storing the target address space in the PointeeInfo struct so that downstream users may query it.
dylanmckayforce-pushed
the
avr-use-correct-addrspace
branch
from
July 21, 2020 17:19
97b6b9b to
5581ce6Comparedylanmckay
commented
Jul 21, 2020
ContributorAuthor
I've added a few tests. Whilst writing the tests, I noticed that I no longer needed to apply @eddyb's suggestion that changed all Back to review. |
nagisa
commented
Jul 21, 2020
Member
@bors r+ |
bors
commented
Jul 21, 2020
Collaborator
📌 Commit 5581ce6 has been approved by |
Manishearth added a commit
to Manishearth/rust
that referenced
this pull request
Jul 22, 2020
…e, r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch, the `type_i8p` method implcitily assumed the default address space, which is not a safe transformation on all targets, namely AVR. The Rust compiler already has support for tracking the "instruction address space" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation, around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch, the address space is always either 1) explicitly preserved from the input type, or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there, or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default, "data" address space.
bors
commented
Jul 22, 2020
Collaborator
bors
commented
Jul 22, 2020
Collaborator
☀️ Test successful - checks-actions, checks-azure |
Comment on lines
+2185
to
+2186
| size: layout.size, | ||
| align: layout.align.abi, |
Member
There was a problem hiding this comment.
FWIW this makes very little sense. This sets the pointee size and alignment of function pointers to be the pointer size and alignment, i.e. on x86-64 this will be size 8 alignment 8, which is just completely wrong -- function pointers do not point to 8-aligned data.
Luckily these two fields are, from what I can tell, completely unused if safe is None (which does make me wonder why they are not inside the same Option).
Member
There was a problem hiding this comment.
Actually sounds like the entire approach of using PointeeInfo to carry address space information is fundamentally broken; see this Zulip discussion.
| unsafe { | ||
| STORAGE_FOO(&1, &mut buf); | ||
| } | ||
| } |
Member
There was a problem hiding this comment.
What happens when you store a function pointer in a type like Result<&'static u8, fn()>? (Example due to @eddyb)
In LLVM this type gets translated as { i64, ptr }, where the first field indicates Ok vs Err and the 2nd field contains the data (&u8 or fn(), depending on the first field). So it is fundamentally impossible to have a dedicated function pointer address space here. Doesn't sound like the approach taken in this PR can possibly work here?
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
NOTE: Pull request iterations:
This patch extends the existing
type_i8pmethod so that it requires anexplicit address space to be specified. Before this patch, the
type_i8pmethod implcitily assumed the default address space, which isnot a safe transformation on all targets, namely AVR.
The Rust compiler already has support for tracking the "instruction
address space" on a per-target basis. This patch extends the code
generation routines so that an address space must always be specified.
In my estimation, around 15% of the callers of
type_i8pproducedinvalid code on AVR due to the loss of address space prior to LLVM final
code generation. This would lead to unavoidable assertion errors
relating to invalid bitcasts.
With this patch, the address space is always either 1) explicitly preserved
from the input type, or 2) explicitly set to the instruction address
space because the logic is dealing with functions which must be placed
there, or 3) explicitly set to the default address space 0 because the
logic can only operate on data space pointers and thus we keep the
existing semantics of assuming the default, "data" address space.