Avoid some bus erroring unaligned memory accesses. #7128
Merged
Conversation
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
alignas(1) makes no change to btree_internal_pair -- its member btree_key_t, or its being packed, already has that effect.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description
This is a best effort fix to avoid some unaligned memory accesses that have cropped up in testing 32-bit ARM code. This avoids crashes that occur when running 32-bit ARM binaries on a 64-bit kernel.
This will probably improve the performance of 32-bit ARM on a 32-bit Linux kernel, because supposedly the kernel traps the error and fixes up the memory read. Or so I've read. That could matter if anybody has that running on some rPi somewhere.
I checked by disassembly -- this does not affect x86-64 code generation on g++, except maybe for copy() calls in debug mode -- nor would we expect it to.
With this fix I got 32-bit ARM debug binaries to run successfully on a 64-bit ARM system.
For what it's worth, I ran into some unrelated issue with release binaries, possibly some sort of cross-compiling/linking snafu as it was a segfault in libc, so I didn't test that.
It also should be noted that I built with
-DRDB_NO_BACKTRACES=1to avoid another libc (or libexecinfo?) segfault in the debug binary, which calls libc or libexecinfo'sbacktrace()preemptively in some cases (for debugging purposes).