[Lldb-commits] [PATCH] D53086: [PDB] Fix flaky `variables-locations.test` after PR38857

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Oct 15 12:15:27 PDT 2018


labath added a comment.

In https://reviews.llvm.org/D53086#1261704, @aleksandr.urakov wrote:

> As for aligned stack cross-platform problems, I mean also problems with stack unwinding. They seem to appear on non-Windows too. It's because `x86AssemblyInspectionEngine` doesn't support stack alignment now. I've made some changes locally to fix it, but they are still raw to publish. The main idea is to save one more frame address (along with CFA) for every row of an unwind plan (I've called this AFA - aligned frame address), and add an analysis for `and esp, ...` etc. to `x86AssemblyInspectionEngine`. What do you think about a such approach?


I am not sure I fully understand the discussion here (I got lost in the windows-specific jargon), but are we talking about the situation where a function re-aligns it's stack pointer on entry via some sequence like:

  mov %esp, %ebp
  and %-8, %esp
  ...
  mov %ebp, %esp
  ret

?

If so, then I don't see why the instruction emulator should have a problem with this sequence, because after `mov %esp, %ebp` it will conclude that the frame of this function is ebp-based, and use that for unwinding (I know there were some issues here in the past, but I hope I have fixed those already). Or are you saying that your compiler manages to align the stack without producing a frame pointer? I think that would be very tricky, as the function itself needs to restore the original %esp value somehow so it can return properly. Can you show me the disassembly of the function in question?


https://reviews.llvm.org/D53086





More information about the lldb-commits mailing list