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.
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
i#3699 ARM: Add padding to priv_mcontext_t for 8-byte alignment. #7191
i#3699 ARM: Add padding to priv_mcontext_t for 8-byte alignment. #7191
Changes from 7 commits
df170af
c5435b5
3f087b2
a53fcb8
fab4f04
f26be17
c7b93b0
cb72c38
7f3a6a7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes it sound like we appended padding to the end where a recompile is enough; but really we inserted padding in between fields, so any code such as generated machine instructions for instrumentation has to be updated as the field offsets have changed. I think this needs to explicitly say that some field offsets have changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've improved the change log ... and I've just realised that I hadn't actually made
priv_mcontext_t
8-byte aligned! I'd changed its size to a multiple of 8, and in the places where it is allocated in assembly on the stack it is 8-byte aligned because SP is 8-byte aligned, and it would be automatically 8-byte aligned if someone were to usemalloc
, but apriv_mcontext_t
local variable might not be 8-byte aligned as it was. So I've added auint64 _unused
in an anonymous union in the struct definition. Do you think that's the thing to do and the right way to do it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use
ALIGN_VAR(8)
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you marked
priv_mcontext_t
asALIGN_VAR
, so it won't be aligned, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I may have been a bit hasty in merging that, and the change log entry is unclear: I think I honestly meant "it" to refer to the "size" when I wrote that but readers will, of course, understand "it" to refer to the struct!
Enforcing alignment seems to cause a problem with cross-compilation that I'm not yet set up to reproduce on a local machine: #7196.
We must either debug that cross-compilation problem and enforce alignment, or correct that log message to make it clear that all we have done is make the size a multiple of 8 in order to facilitate alignment.
(The cross-compilation problem seems rather interesting. If there are lingering alignment issues in the code I wonder if #7161 will turn out to be alignment-related.)