[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86
Rainer Orth via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Sep 17 02:08:43 PDT 2020
ro added a comment.
In D87615#2278002 <https://reviews.llvm.org/D87615#2278002>, @joerg wrote:
> I'm still curious about the source of the vptr diff, but that's a minor question, otherwise. LGTM
Thanks. I think I've found what's going on here: the memory ranges are ultimately printed by `compiler-rt/lib/ubsan/ubsan_diag.cpp` (`PrintMemorySnippet`). The crucial snippet is around l.280:
// Emit data.
InternalScopedString Buffer(1024);
for (uptr P = Min; P != Max; ++P) {
unsigned char C = *reinterpret_cast<const unsigned char*>(P);
Buffer.append("%s%02x", (P % 8 == 0) ? " " : " ", C);
}
`Min` is `Loc - 4`, i.e. 4 bytes before the start location. Before my patch (i.e. with 16-byte stack alignment), that was
0xfeffdcf0: note: object is of type 'S'
76 62 92 92 ec 1b 06 08 00 00 00 00 44 de ff fe 30 dd ff fe 00 00 00 00 00 00 00 00 00 00 00 00
i.e. `Loc - 4` wasn't on an 8-byte boundary, thus the line starts with a single blank. With 4-byte aligned stack, I have instead
0xfeffdd34: note: object is of type 'S'
76 62 92 92 ec 1b 06 08 00 00 00 00 78 dd ff fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
i.e. `Loc - 4` **is** on an 8-byte boundary and the line starts with two blanks.
I can't see that the `vptr.cpp` testcase does anything to guarantee a specific alignment here, or depends on one. In fact, AFAICS it's the only ubsan test that looks at that memory dump line at all.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D87615/new/
https://reviews.llvm.org/D87615
More information about the cfe-commits
mailing list