On 2017-04-26 19:56, Eric Christopher wrote:> That's really weird. I'm quite surprised that the entry block was moved > so much later in the function but haven't had a chance to look more at > it. Probably want to take a look and find out where that's happening and > why.From irc, thegameg helped me find the -enable-shrink-wrap=false, which "fixes" this, although this option doesn't seem to have a switch from code, only from the llc command line. Unless I'm missing something obvious, this will always screw up debug info on Windows 32bits. The check in code to enable this calls: bool usesWindowsCFI() const { return ExceptionsType == ExceptionHandling::WinEH && (WinEHEncodingType != WinEH::EncodingType::Invalid && WinEHEncodingType != WinEH::EncodingType::X86); } Where EncodingType::X86: //Windows x86, uses no CFI, just EH tables The comment seems to imply there are EH tables for i386 Windows, however I can't find them. -- Carlo Kok RemObjects Software
Eric Christopher via llvm-dev
2017-Apr-26 18:43 UTC
[llvm-dev] no-frame-pointer-elim & optimized
Adding Quentin here... On Wed, Apr 26, 2017 at 11:31 AM Carlo Kok <ck at remobjects.com> wrote:> > > On 2017-04-26 19:56, Eric Christopher wrote: > > That's really weird. I'm quite surprised that the entry block was moved > > so much later in the function but haven't had a chance to look more at > > it. Probably want to take a look and find out where that's happening and > > why. > > From irc, thegameg helped me find the -enable-shrink-wrap=false, which > "fixes" this, although this option doesn't seem to have a switch from > code, only from the llc command line. > >This is a good point. I've not overly thought about how shrink wrapping is going to correlate with entry/exit blocks and prologues. That said, the whole point of shrink wrapping is that the stack adjustments are hidden. I'd have to page in that code to make more than a hand wavy "here's how you'll fix this" though. More thoughts right below though...> Unless I'm missing something obvious, this will always screw up debug > info on Windows 32bits. > >It's pretty much everywhere and just means that the debugger will have some weird state until you actually hit that point. in the code. The problem is that you probably want the debugger to stop at the "beginning" of the function, but with shrink wrapping you won't have stack adjustments at all for that code and if you wait and put the prologue end at the end of the "stack adjustments" then you likely won't stop at all in the function. Tricky. At the moment I'm inclined to believe that this is "correct", but that we really need a better way of distinguishing these entry points. Adrian/Dave: Any other ideas here? -eric> The check in code to enable this calls: > > > bool usesWindowsCFI() const { > return ExceptionsType == ExceptionHandling::WinEH && > (WinEHEncodingType != WinEH::EncodingType::Invalid && > WinEHEncodingType != WinEH::EncodingType::X86); > } > > Where EncodingType::X86: //Windows x86, uses no CFI, just EH tables > > The comment seems to imply there are EH tables for i386 Windows, however > I can't find them. > > -- > Carlo Kok > RemObjects Software >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170426/854925a2/attachment.html>
David Blaikie via llvm-dev
2017-Apr-26 19:33 UTC
[llvm-dev] no-frame-pointer-elim & optimized
On Wed, Apr 26, 2017 at 11:43 AM Eric Christopher <echristo at gmail.com> wrote:> Adding Quentin here... > > On Wed, Apr 26, 2017 at 11:31 AM Carlo Kok <ck at remobjects.com> wrote: > >> >> >> On 2017-04-26 19:56, Eric Christopher wrote: >> > That's really weird. I'm quite surprised that the entry block was moved >> > so much later in the function but haven't had a chance to look more at >> > it. Probably want to take a look and find out where that's happening and >> > why. >> >> From irc, thegameg helped me find the -enable-shrink-wrap=false, which >> "fixes" this, although this option doesn't seem to have a switch from >> code, only from the llc command line. >> >> > This is a good point. I've not overly thought about how shrink wrapping is > going to correlate with entry/exit blocks and prologues. That said, the > whole point of shrink wrapping is that the stack adjustments are hidden. > > I'd have to page in that code to make more than a hand wavy "here's how > you'll fix this" though. More thoughts right below though... > > >> Unless I'm missing something obvious, this will always screw up debug >> info on Windows 32bits. >> >> > It's pretty much everywhere and just means that the debugger will have > some weird state until you actually hit that point. in the code. The > problem is that you probably want the debugger to stop at the "beginning" > of the function, but with shrink wrapping you won't have stack adjustments > at all for that code and if you wait and put the prologue end at the end of > the "stack adjustments" then you likely won't stop at all in the function. > > Tricky. > > At the moment I'm inclined to believe that this is "correct", but that we > really need a better way of distinguishing these entry points. > > Adrian/Dave: Any other ideas here? >My guess (& this is more a "if someone wants to write patches for this, this is the direction I'd suggest" - since it's not a priority for me to do this work) would be that once the prologue is sunk beneath instructions with other debugloc lines (I think the current theory is that prologue locations have no debugloc at all - so basically as soon as you hit any debugloc) - it's no longer really the prologue. At that point emit the DWARF prologue - describe the value of parameters based on where they are at that point (registers, stack offsets, etc) and if you later reach a prologue that stuffs the values into stack, etc - emit a new location for the variables at that point. - Dave> > -eric > > >> The check in code to enable this calls: >> >> >> bool usesWindowsCFI() const { >> return ExceptionsType == ExceptionHandling::WinEH && >> (WinEHEncodingType != WinEH::EncodingType::Invalid && >> WinEHEncodingType != WinEH::EncodingType::X86); >> } >> >> Where EncodingType::X86: //Windows x86, uses no CFI, just EH tables >> >> The comment seems to imply there are EH tables for i386 Windows, however >> I can't find them. >> >> -- >> Carlo Kok >> RemObjects Software >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170426/b5df48ef/attachment.html>