[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

[Rainer Orth via Phabricator via cfe-commits]

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