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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
