[llvm-commits] [PATH] Fix unwind info in x86 JIT for functions without stack space

Zoltan Varga vargaz at gmail.com
Sun Aug 2 14:49:38 PDT 2009


Hi,

  In that case, shouldn't the DW_CFA_offset instructions contain positive
offsets, since
sp points at the last saved register (%rbx) ?

                            Zoltan

On Sun, Aug 2, 2009 at 11:12 PM, Bill Wendling <isanbard at gmail.com> wrote:

> Correct, because it's using the %esp register unmodified as the CFA
> offset, so it doesn't need to use DW_CFA_def_cfa_offset to define a
> new one. Here's the DWARF definition of DW_CFA_def_cfa_offset:
>
> "DW_CFA_def_cfa_offset
>
> The DW_CFA_def_cfa_offset instruction takes a single unsigned LEB128
> operand representing a (non-factored) offset. The required action is
> to define the current CFA rule to use the provided offset (but to keep
> the old register)."
>
> In other words, the DW_CFA_def_cfa_offset isn't be needed in this case.
>
> -bw
>
> On Aug 2, 2009, at 6:03 AM, Zoltan Varga wrote:
>
> > Hi,
> >
> >   Attached an .ll file which reproduces this on x86-64. Compile it
> > using:
> >
> > llvm-as -f empty.ll && llc -f empty.bc && as empty.s
> >
> > The prolog of the 'stelemref' function looks like this:
> >
> > 0000000000000000 <stelemref>:
> >    0:   41 57                   push   %r15
> >    2:   41 56                   push   %r14
> >    4:   53                      push   %rbx
> >
> > While the unwind info looks like this:
> >
> > 00000018 00000014 0000001c FDE cie=00000000 pc=00000000..00000045
> >   DW_CFA_advance_loc: 5 to 00000005
> >   DW_CFA_offset: r3 (rbx) at cfa-32
> >   DW_CFA_offset: r14 (r14) at cfa-24
> >   DW_CFA_offset: r15 (r15) at cfa-16
> >
> > Notice that there is no DW_CFA_def_cfa_offset instruction.
> >
> >                     Zoltan
> >
> >
> > On Sun, Aug 2, 2009 at 1:48 PM, Bill Wendling <isanbard at gmail.com>
> > wrote:
> > On Jul 31, 2009, at 10:56 AM, Zoltan Varga wrote:
> > > Hi,
> > >
> > > This is a resend of a patch sent earlier which got lost in the ml
> > > traffic.
> > >
> > >   The x86 jit doesn't generate a def_cfa_offset unwind instruction
> > > after the
> > > pushes in the function prolog if the function doesn't
> > >
> > > have any stack space, i.e. for a prolog like:
> > >
> > > 0x40011870:     push %r15
> > >
> > > 0x40011872:     push %r14
> > >
> > > 0x40011874:     push %rbx
> > >
> > > The attached patch fixes this.
> > >
> > Hi Zoltan,
> >
> > (Sorry it took me a while to look at this email.)
> >
> > I don't think that this patch is the correct solution. The unwind info
> > for callee-saved registers should be emitted in this code:
> >
> >   // Skip the callee-saved push instructions.
> >   bool RegsSaved = false;
> >   while (MBBI != MBB.end() &&
> >          (MBBI->getOpcode() == X86::PUSH32r ||
> >           MBBI->getOpcode() == X86::PUSH64r)) {
> >     RegsSaved = true;
> >     ++MBBI;
> >   }
> >
> >   if (RegsSaved && needsFrameMoves) {
> >     // Mark end of callee-saved push instructions.
> >     unsigned LabelId = MMI->NextLabelID();
> >     BuildMI(MBB, MBBI, DL, TII.get(X86::DBG_LABEL)).addImm(LabelId);
> >
> >     // Emit DWARF info specifying the offsets of the callee-saved
> > registers.
> >     emitCalleeSavedFrameMoves(MF, LabelId, HasFP ? FramePtr :
> > StackPtr);
> >   }
> >
> > The code you modified is placing a label/machine-move after the "subl
> > X, %esp" instruction when there isn't a frame pointer. (N.B., this
> > instruction won't exist if NumBytes == 0.)
> >
> > Do you have a code example for me to look at?
> >
> > -bw
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> > <empty.ll>_______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090802/9438ce28/attachment.html>


More information about the llvm-commits mailing list