similar to: llvm cfi

2015-09-01 11:38 GMT+08:00 John Criswell <jtcriswel at gmail.com>: > On 8/31/15 10:43 PM, 慕冬亮 via llvm-dev wrote: > > I want to create an experiment to show the effectiveness of cfi : > For example , > I first need a program with vulnerability so that we can hijack its > control flow; > > then I enforce cfi of llvm and we can't hijack its control flow. > >

Ask a simple question : I svn checkout compiler-rt in llvm/project. And I compile llvm through cmake. How can I make for all those testing files? make test? - mudongliang 2015-09-02 0:58 GMT+08:00 Kostya Serebryany <kcc at google.com>: > Take a look at > > clang.llvm.org/docs/ControlFlowIntegrityDesign.html > clang.llvm.org/docs/ControlFlowIntegrity.html > > And the

Hi In my previous mail I mentioned the project on KCoFI( the control FLow integrity methods for commodity hardware http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ). Will it be more helpful to the community if I do the improvements number #1 and #3 mentioned in my previous mail to the mailing list or if i try to port it to arm architecture? I have decided to go ahead with the improvements

Hi I want to pursue a project based to improve the existing KCoFI method which is the Control Flow integrity method for commodity os. Since KCoFI is a llvm based project I plan to undertake the project to improve the existing KCoFI method. Following are the improvements that I want to pursue: 1. To improve the call graph used in KCoFI. Implement a stronger call graph. 2. Port the KCoFI to

I want to transform elf binary to llvm IR, and do some instrumentation based on llvm. Is there any tool which can do the transformation? Thanks in advance. - mudongliang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/abee5f23/attachment.html>

2015-11-30 12:58 GMT+08:00 Chris Bieneman <beanz at apple.com>: > The autotools build system is officially deprecated and will be removed in a > future release. > > CMake is the recommended configuration system, but it is only a > configuration system. It generates build files for multiple different build > systems. One of the most popular build systems is Ninja. You cannot

When I see one book about llvm and choose the building method between autotools, cmake, and ninja building methods, I was confused. Is there any link about this content? Thanks for reply. -- My best regards to you. No System Is Safe! mudongliang

2015-08-29 14:45 GMT+08:00 Martell Malone <martellmalone at gmail.com>: > Why are there two ways to compile LLVM? >> make and cmake! >> What's the difference of those two ways? > > > make and cmake are used together not separately. > cmake is a high level generator that creates a makefile for make > > I compile llvm according to this website(

Hello everyone, I have written simple LLVM passes, but I cannot able to write a MachineFunctionPass pass. I am following the steps form the following link but it is not working: http://www.gabriel.urdhr.fr/2014/09/26/adding-a-llvm-pass/ Please share the sample MachineFunctionPass code or steps to follow to write MachineFunctionPass. Thanks, Bala -- Thanks, Bala IIITA Allahabad --------------

For every level of translation [in terms of "human readable -> machine code translation", not someone translating a literary work from one language to another - although often some subtle details are lost here too], a little bit of the semantic meaning is lost. This means that you can almost never completely reconstruct the code in original form from the machine-code, or the C-code

First you should learn how to write a pass and then a MachineFunctionPass. >From LLVM website, you can refer to http://llvm.org/docs/WritingAnLLVMPass.html And for outside pass, you can refer to http://adriansampson.net/blog/llvm.html It's a great article. And the author put the source code on Github <https://github.com/sampsyo/llvm-pass-skeleton>. 2016-03-01 14:36 GMT+08:00

2015-12-01 1:20 GMT+08:00 Chris Bieneman <beanz at apple.com>: > > On Nov 29, 2015, at 9:09 PM, 慕冬亮 <mudongliangabcd at gmail.com> wrote: > > 2015-11-30 12:58 GMT+08:00 Chris Bieneman <beanz at apple.com>: > > The autotools build system is officially deprecated and will be removed in a > future release. > > CMake is the recommended configuration system,

>> Currently the only two targets that disable CFI are Hexagon and >> powerpc targeting BGP. Is that still correct? >> >> The current integrated assembler is working for PPC, no? > > Yes, and regardless, as far as I'm concerned, the BG/P is now dead. Cool. I have changed the BG/P in r203269. What about hexagon. Do we still need to avoid cfi instructions with it?

Hi Rafael, I've been staring at the CFI directives and have a question. Some background: I want to generate the compact unwind information using just the CFI directives. I *think* that this should be doable. The issue I'm facing right now is that I need to know how much the stack pointer was adjusted. So when I have something like this: .cfi_startproc Lfunc_begin175:

Currently the only two targets that disable CFI are Hexagon and powerpc targeting BGP. Is that still correct? The current integrated assembler is working for PPC, no? For Hexagon, it has been disabled since the initial checkin. There is still no support for cfi? Thanks, Rafael

Hi, I’m working on setting up ThinLTO+CFI for a C application which uses a lot of function pointers. While functionally it appears stable, it’s performance is significantly degraded, to the tune of double digit percentage points compared to regular LTO+CFI. Looking into possible causes I see that under ThinLTO+CFI iCall type checks almost always generate jump table entries for indirect calls,

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is

Hi, I would like to propose extending the Control-Flow Integrity (CFI) mechanism in LLVM/Clang with a feature that allows users to explicitly link classes that have no inheritance link. Usually, if one class is used at locations in code where this class is not expected, this will create a CFI error at runtime, assuming the application is built with CFI enabled. However, in cases where the user

I watched Teresa’s talk on ThinLTO from last year’s CppCon, and it sounded like adding global variable information to the summaries was in the works, or at least in planning. Can someone (Teresa?) please share the current status? If it’s part of future plans, are there any specific proposals that can be picked up and worked on? Thanks! > On Apr 9, 2018, at 6:51 PM, via llvm-dev <llvm-dev

Hi, this is a proposal for the implementation of CFI-icall [1] with ThinLTO. Jumptables are generated in the merged module. To generate a jumptable, we need a list of functions with !type annotations, including (in non-cross-dso mode) external functions. Unfortunately, LLVM IR does not preserve unused function declarations, and we don’t want to copy the actual function bodies to the merged