[PATCH] Add an intrinsic for creating jump-instruction table entries

[Tom Roeder]

Thanks very much for looking at this.

Given the comments on this proposal from Peter on llvmdev, I've changed
this mechanism a fair bit. I just posted a patch to llvm-commits that gives
one option that uses intrinsics only for the jmp-statement lowering. And
I'm going to revise that patch as per more comments from Peter to do the
actual generation in the AsmPrinter. So, you can consider this patch
obsolete. :)

Tom


On Thu, Apr 3, 2014 at 4:58 AM, Eric Christopher <echristo at gmail.com> wrote:

> Seems interesting, haven't looked too much, but I'm in favor of
> anything that stops people from writing inline asm from passes :)
>
> Nick? Chris?
>
> -eric
>
> On Thu, Mar 20, 2014 at 4:15 PM, Tom Roeder <tmroeder at google.com> wrote:
> > On Thu, Mar 20, 2014 at 2:37 PM, Tom Roeder <tmroeder at google.com> wrote:
> >>
> >> Hi,
> >>
> >> This patch adds an intrinsic for creating jump-instruction table entries
> >> of the form:
> >>
> >>   .type f_JT, at function
> >>   f_JT:
> >>     jmp f at PLT
> >>
> >> It adds an intrinsic void @llvm.jump.instr.table.entry(i8*) and X86
> >> backend support for this intrinsic. The intrinsic takes a bitcast
> function
> >> pointer as input and generates the jump-instruction table entry. Note
> that
> >> while jump tables are supported in CodeGen, they are a different kind of
> >> jump table, AFAICT: one that uses indices rather than one that contains
> jump
> >> instructions.
> >>
> >> This intrinsic would allow me to remove the inline assembly that I
> >> currently use for control-flow integrity (CFI), as discussed on llvmdev;
> >> these intrinsics would be generated by the CFI pass along with
> declarations
> >> of the jump-table functions (required because the CFI pass replaces
> >> address-taken functions with the address of the _JT function).
> >>
> >> I couldn't find any way to do this above the arch-specific Targets,
> given
> >> that it violates the IR branch semantics of jumping to a block; and
> even so,
> >> I had to add a check to one of the X86 optimizations that was assuming
> that
> >> all JMP_4 instructions had a MachineBasicBlock as an operand.
> >>
> >> The patch also adds another kind of label, JUMP_FUNCTION_LABEL, which
> >> produces a label that looks like the start of a function (with
> MCSA_Global
> >> and sometimes MCSA_ELF_TypeFunction). So, the intrinsic lowers to a
> >> JUMP_FUNCTION_LABEL and a JMP_4.
> >>
> >> I was able to do much of the work in the target-independent portions of
> >> the code, so I don't think it will take much effort to add support to
> some
> >> other architectures (like ARM), and I intend to do that if this patch is
> >> acceptable.
> >>
> >> One question: what's the right way to do the mangling (the "_JT") for
> the
> >> jump-table functions? For my purposes in CFI, I'd like to have a way of
> >> naming these jump entries that a pass at the IR level could also
> discover or
> >> reproduce. Is there a standard mangling facility for specialized
> suffixes?
> >>
> >> Please let me know what you think.
> >>
> >> Thanks,
> >>
> >> Tom
> >
> >
> > Just realized that there were a few line-length violations that I hadn't
> > cleaned up in the code. Here's a slightly tweaked patch.
> >
> > Tom
> >
> >
> > _______________________________________________
> > 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/20140404/259e043f/attachment.html>