search for: lowertypetest

Hi, I am looking into Control-Flow Integrity for indirect function calls, implemented with jump tables. I want to step through the code that produces these jump tables in GDB. I have built clang and opt from source with debugging symbols. I believe this code lives in llvm/lib/Transforms/LowerTypeTests.cpp, but when I try to debug *opt* by running the command "run -lowertypetests cfi-icall.bc > /dev/null", I am never able to reach this file. Also, I have tried to debug the command "clang -flto -fsanitize=cfi-icall indirect.c -o indirect" (where indirect.c is a C file cont...

Hi, I have made some changes in the LowerTypeTests Pass of opt, and would like to use these changes with the clang version I have downloaded. I compiled clang and llvm from scratch, made my changes in LowerTypeTests.cpp, and recompiled clang and opt. When I run clang with the appropriate flags to invoke the pass, it invokes the pass as originally...

...t; !3 = !{!"foo", i8 0, !4} >> !4 = !{i64 0, !"_ZTSFvE"} > > > Presumably there would be no entries in !cfi.functions for functions defined > in the merged module, as the type metadata would come from the module > itself. Right. The same as with vtable CFI, LowerTypeTests will use !cfi.functions in addition to the regular logic. >> >> >> Each function is described by a tuple of >> * Promoted name as a string > > > I imagine that we would only promote a function if it is address-taken. > Otherwise we could be inhibiting optimizat...

...ZTSFvE"} > >> > >> > >> Presumably there would be no entries in !cfi.functions for functions > defined > >> in the merged module, as the type metadata would come from the module > >> itself. > > > > Right. The same as with vtable CFI, LowerTypeTests will use > > !cfi.functions in addition to the regular logic. > > > >>> > >>> > >>> Each function is described by a tuple of > >>> * Promoted name as a string > >> > >> > >> I imagine that we would only promote...

...!6 = !{i64 0, i64 751454132325070187} “Linkage” is one of: definition, external declaration, external weak declaration. In the merged “merged” module, !cfi.functions may contain multiple entries for each function. We pick one with the strongest linkage (i.e. the definition, if it is available) in LowerTypeTests. The LTO step emits, for a defined function named “f”: declare void f.cfi() .jumptable: … call f.cfi ... f.cfi-jt = alias .jumptable + offset f = alias f.cfi-jt The same for an external (either weak or strong) declaration of a function named “f”: .jumptable: … call f ......

...see what the problem is, it's that we use a custom section name for jump tables. Normally, each function (the jump table for each type is a separate function) gets a separate section, but that isn't the case for functions with custom section names. > > If you comment out this line of LowerTypeTests.cpp: > http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/LowerTypeTests.cpp#1274 > does that help reduce the size of the individual sections? > > Peter > > > > On May 1, 2018, at 11:16 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > > > &...

.... > I see what the problem is, it's that we use a custom section name for jump tables. Normally, each function (the jump table for each type is a separate function) gets a separate section, but that isn't the case for functions with custom section names. If you comment out this line of LowerTypeTests.cpp: http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/LowerTypeTests.cpp#1274 does that help reduce the size of the individual sections? Peter > > > > On May 1, 2018, at 11:16 AM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > > > > > > On Tue, Ma...

...he problem is, it's that we use a custom section name for jump tables. Normally, each function (the jump table for each type is a separate function) gets a separate section, but that isn't the case for functions with custom section names. > > > > If you comment out this line of LowerTypeTests.cpp: > > http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/LowerTypeTests.cpp#1274 > > does that help reduce the size of the individual sections? > > > > Peter > > > > > > > On May 1, 2018, at 11:16 AM, Peter Collingbourne <peter at pcc.me.uk> wrote:...

Taking out that line breaks some LowerTypeTest tests, need to investigate. Runtime compiler-rt all passed. > On May 1, 2018, at 3:11 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > The problem as I recall was that we do not want jumptable sections to appear before __cfi_check, so we gave these jump tables a name so tha...

...test) pattern that WholeProgramDevirt looks for is somewhat fragile, so it needs to see the IR first before one of the other passes can break it. (This is probably something that we want to fix by using a different pattern.) I don't think that the same issue exists with any of the patterns that LowerTypeTests looks for, so it would probably be fine to move it later. > > Moving WholeProgramDevirt breaks some tests. LowerTypeTests seems OK, not sure how much we can trust the tests though ;) > I’ll create a Phab review for this as well. > > Thanks, I'll take a look. > > Peter...

...it's that we use a custom section name for > jump tables. Normally, each function (the jump table for each type is a > separate function) gets a separate section, but that isn't the case for > functions with custom section names. > > > > If you comment out this line of LowerTypeTests.cpp: > > http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/LowerTypeTests.cpp#1274 > > does that help reduce the size of the individual sections? > > > > Peter > > > > > > > On May 1, 2018, at 11:16 AM, Peter Collingbourne <peter at pcc.me.uk> > wrot...

...that we use a custom section name for > jump tables. Normally, each function (the jump table for each type is a > separate function) gets a separate section, but that isn't the case for > functions with custom section names. > > > > > > If you comment out this line of LowerTypeTests.cpp: > > > http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/LowerTypeTests.cpp#1274 > > > does that help reduce the size of the individual sections? > > > > > > Peter > > > > > > > > > > On May 1, 2018, at 11:16 AM, Peter Collingbourne &...

...ese values, the code will be identical to any other check that uses that resolution, modulo the constant values embedded in the code. To expand on what I mean by "constant values", let's look at a typical CFI check in the ByteArray case. Consider this module (based on test/Transforms/LowerTypeTests/simple.ll): @a = constant i32 1, !type !0, !type !2 @b = constant [63 x i32] zeroinitializer, !type !0, !type !1 @c = constant i32 3, !type !1, !type !2 @d = constant [2 x i32] [i32 4, i32 5], !type !3 !0 = !{i32 0, !"typeid1"} !3 = !{i32 4, !"typeid1"} !1 = !{i32 0, !"t...

...test) pattern that WholeProgramDevirt looks for is somewhat fragile, so it needs to see the IR first before one of the other passes can break it. (This is probably something that we want to fix by using a different pattern.) I don't think that the same issue exists with any of the patterns that LowerTypeTests looks for, so it would probably be fine to move it later. Moving WholeProgramDevirt breaks some tests. LowerTypeTests seems OK, not sure how much we can trust the tests though ;) I’ll create a Phab review for this as well. > > Peter > > > > > > > > On Apr 27...

Hello, I am adding to an LLVM pass that requires a filename as input. I am able to input this filename as a command line argument when I invoke this pass using opt, but I ultimately need to pass this argument to my code when I compile code with clang. How can I pass this argument to clang so that I can use it in my LLVM pass? Thanks for your help! Best, Shishir Jessu -------------- next part

...holeProgramDevirt looks for is > somewhat fragile, so it needs to see the IR first before one of the other > passes can break it. (This is probably something that we want to fix by > using a different pattern.) I don't think that the same issue exists with > any of the patterns that LowerTypeTests looks for, so it would probably be > fine to move it later. > > Moving WholeProgramDevirt breaks some tests. LowerTypeTests seems OK, not > sure how much we can trust the tests though ;) > I’ll create a Phab review for this as well. > Thanks, I'll take a look. Peter > &...

...be identical to any other check that uses that > resolution, modulo the constant values embedded in the code. > > To expand on what I mean by "constant values", let's look at a typical CFI > check in the ByteArray case. Consider this module (based on test/Transforms/ > LowerTypeTests/simple.ll): > > @a = constant i32 1, !type !0, !type !2 > @b = constant [63 x i32] zeroinitializer, !type !0, !type !1 > @c = constant i32 3, !type !1, !type !2 > @d = constant [2 x i32] [i32 4, i32 5], !type !3 > > !0 = !{i32 0, !"typeid1"} > !3 = !{i32 4, !&quot...

...test) pattern that WholeProgramDevirt looks for is somewhat fragile, so it needs to see the IR first before one of the other passes can break it. (This is probably something that we want to fix by using a different pattern.) I don't think that the same issue exists with any of the patterns that LowerTypeTests looks for, so it would probably be fine to move it later. Peter > > > > > > On Apr 27, 2018, at 11:04 AM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > > > For the test case below, I get the following IR for main() on entry to > ThinLTO backend...

...dbg.cu LLVM ERROR: Broken module found, compilation aborted! This crash bugpoint itself. Is there away to prevent bugpoint from doing this rather than changing the source code of bugpoint? I tried to run a "bugpoint --help-hidden" and get the following options related to metadata: -lowertypetests - Lower type metadata -disable-namedmd-remove - Do not remove global named metadata -enable-import-metadata - Enable import metadata like 'thinlto_src_module' -enable-noalias-to-m...

...sManagerBuilder implies that this pass needs to run early. Why is it different from full LTO? > On Apr 27, 2018, at 11:04 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > For the test case below, I get the following IR for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > In l...