[PATCH] D32202: [XRay][compiler-rt] Fix up CFI annotations and stack alignment

[Dean Michael Berris via Phabricator via llvm-commits]

dberris added a comment.

In https://reviews.llvm.org/D32202#731056, @eugenis wrote:

> In https://reviews.llvm.org/D32202#730125, @dberris wrote:
>
> > In https://reviews.llvm.org/D32202#730098, @dberris wrote:
> >
> > > In https://reviews.llvm.org/D32202#730089, @eugenis wrote:
> > >
> > > > FunctionEntry does not look right. It has the frame of 216 bytes (return address + rbp + 184), which is not a multiple of 16. The same with ArgLoggerEntry.
> > >
> > >
> > > So adjusting this just another 8 bytes artificially would be fine, yes?
> >
> >
> > Looked into this a bit more and because rbp + 184 + address is really just 208, we're fine (it's 16-byte aligned ).
>
>
> I think we are both wrong: rbp + 184 + address is 200, and it's not 16-byte aligned.
>  Does it work because the instrumentation calls this trampoline with 16+8 aligned stack?


Ah, well, what happens is this:

- On function entry, offset is already at 8 (frame of the instrumented function). At runtime when we patch, we turn the entry sled into some instructions then a call, which will add another 8 bytes onto the stack (this is the return instruction pointer).
- When we enter this trampoline, we push 8 bytes for rbp (8 + 8 = 16)
- We then use another 184 bytes onto the stack (184 + 16 = 200)
- Then we call the installed handler, it will add 8 bytes onto the stack (return instruction pointer) (200 + 8 = 208)

So by the time the handler function is called we're already on a 16-byte aligned address on the stack.

Does this make more sense?


Repository:
  rL LLVM

https://reviews.llvm.org/D32202