<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hello everyone,<div><br></div><div>Excuzes moi for digging up this amost 2 year old thread.</div><div>I actually created the functionality mentioned in my opening post at the end of 2014.</div><div>At my company we have been using it for nearly a year now with great satisfaction.</div><div>Together with FFF (fake functon framework) and some preprocessor metaprogramming it becomes a really powerfull method to make legacy C code testable.</div><div>We are running almost 900 tests with google-test and easy-test-seam on both Windows and an embedded Linux platform everytime one of our engineers commits new code.</div><div><br></div><div>I ended up using the clang driver and mimicing the FixItRecompile functionality with the rewriters. The functionality can be toggled by adding -inject-test-seams on the commandline.</div><div>The implementation can be found at <a href="https://github.com/ivankoster/clang/commit/e56887a20c3cd076db27b377c92eaa0096eaefcd" target="_blank">https://github.com/ivankoster/<wbr>clang/commit/<wbr>e56887a20c3cd076db27b377c92eaa<wbr>0096eaefcd</a> (I extended clang 3.7 and clang 3.8 with it)</div><div><br></div><div>Unfortunately, since i based it on FixItRecompile, easy-test-seam generates the AST twice in one compiler invocation.</div><div>In my benchmarks on our code base this means a running time increase of about 66%. </div><div>This doesn't sound strange if you know that the AST is generated, a bunch of files are rewritten and copied for the next AST generation to use it, then the AST is generated a 2nd time.</div><div>Lately this performance loss has been starting to bug me a bit. I'd like to save as much of my time as well as my fellow colleagues time :)</div><div><br></div><div>I'm wondering if something like easy-test-seam is also possible to do with just one AST generation, by just generating the AST I want in the first place, without source rewriting.</div><div>I imagine this being a lot more complex then how it works right now.</div><div>I also have no clue where to start. Creating easy-test-seam in the first place wasn't that easy since I knew nothing about the clang codebase :)</div><div><br></div><div>So, does anyone have an idea if this is remotely possible in one AST generation, and if so, can point me into the right direction?</div><div>Or maybe someone is interested in this idea and wants to help create it?</div><div><br></div><div>Kind regards,</div><div><br></div><div>Ivan Koster</div><div> </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-12-22 16:06 GMT+01:00 Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><span>On Mon Dec 22 2014 at 3:56:44 PM Ivan Koster <<a href="mailto:ivankoster@gmail.com" target="_blank">ivankoster@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Allright, so if I don't call Rewriter::overwriteChange<wbr>dFiles() it won't change the files.<div><br></div><div>I've been getting a bit lost in the clang api forest, but if I want to do the above described with my own compiled clang-cl.exe, I guess I'll have to insert a 2nd CompileJobAction after the actionlist is made by TheDriver.BuildCompilation(arg<wbr>v) in clang\tools\driver\driver.cpp?</div><div>How would one let this 2nd CompileJobAction use the input source file that is still in memory after the 1st compile action is finished?</div></div></blockquote><div><br></div></span><div>I think you don't want to use the driver in that case - you want to write your own little tool, and that can do the compilation and the rewriting and otherwise look just like the driver. That way you control all the buffers for all the files. libTooling has some stuff to make life easier there...</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks,</div><div><br></div><div>Ivan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 21, 2014 at 5:24 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div><div>On Sat Dec 20 2014 at 12:26:08 PM Ivan Koster <<a href="mailto:ivankoster@gmail.com" target="_blank">ivankoster@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello all,<div><br></div><div>I want to create a tool that facilitates easy test seam injection in legacy C code.</div><div>The reason for this is many colleagues (including myself) finding it very tedious and maintenance intensive to create stubs / mocks for our legacy C code base. This causes us to write less unittests than we want to. We currently use a routing mechanism with #defines in a .h file that reroutes functions to stubs/mocks and is included when we compile for unittesting.</div><div><br></div><div>I have been researching several ways of creating test seams, and have settled on a method which leverages function pointers. A welcome help was the article at <a href="http://meekrosoft.wordpress.com/2012/07/20/test-seams-in-c-function-pointers-vs-preprocessor-hash-defines-vs-link-time-substitution/" target="_blank">http://meekrosoft.wordpress.co<wbr>m/2012/07/20/test-seams-in-c-<wbr>function-pointers-vs-preproces<wbr>sor-hash-defines-vs-link-time-<wbr>substitution/</a></div><div>But to make it truly easy, I need the compiler to do it for me. This is were clang/llvm comes in.</div><div><br></div><div>What I want is the following. Given the following 2 files:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>// interface.h</div></div><div><div>__attribute__((easy_test_seam)<wbr>)</div></div><div><div>int foo(void);</div></div><div><div><br></div></div><div><div>// implementation.c</div></div><div><div>int foo(void)</div></div><div><div>{</div></div><div><div> return 2;</div></div><div><div>}</div></div></blockquote><div><br></div><div>I actually want it to be compiled as:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>// interface.h</div></div><div><div>extern int (*foo)(void);</div></div><div><div><br></div></div><div><div>// implementation.c</div></div><div><div>int foo_orig(void)</div></div><div><div>{</div></div><div><div> return 2;</div></div><div><div>}</div></div><div><div>int (*foo)(void) = foo_orig;</div></div></blockquote><div><br></div><div>In a later stage we could also add standard stub generation, maybe an attribute like:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>__attribute__((easy_test_seam(<wbr>5)))</div><div>int foo(void);</div></blockquote><div>Which would also create a standard stub that returns 5;<br></div><div><br></div><div>I see this method as a huge relief. It's maintenance friendly, we only have to add the attribute to the legacy interfaces. We will only act on the attribute if we compile for unittesting. Since we then won't have changed production code it also won't mess up static analysis of production code and won't fool IDE's jump to definition functionality.</div><div><br></div><div>The last few days I have been researching how to do this.</div><div><br></div><div>I have seen many suggest source-to-source transformation using the clang Rewriter class. This is not my preferred choice, I don't have the need to edit the *.c and *.h files, I just want them compiled differently. I would also have to extend our build system to clone my *.c and *.h files, run them through the source-to-source transform tool, and then compile the resulting .c and .h files. This is not insurmountable, but not trivial either.</div></div></blockquote><div><br></div></div></div><div>It is pretty much the same as editing the AST directly. You can do all the source editing in memory in a single tool, *and* do the compile step on the changed source from the same tool; no need to write anything to disk (in fact, the rewriting tools all have the source in memory before they edit the files on disk).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr"><div><br></div><div>I've seen some suggestions against changing the clang AST, because it's supposed to be immutable and is hard.</div><div><br></div><div>I've also seen some suggestions to do LLVM IR transform passes, but I haven't dived deep enough in LLVM IR to determine if this can work or not.</div><div><br></div><div>I'm very new to clang and LLVM, can you guys help me determine which of the three ways would be the way to go? Or maybe there is another way?</div><div><br></div><div>Thanks in advance!</div><div><br></div><div>Regards,</div><div><br></div><div>Ivan</div><div><br></div><div><br></div></div></span>
______________________________<u></u><wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<wbr>an/listinfo/cfe-dev</a><br>
</blockquote></div>
</blockquote></div><br></div>
</blockquote></div></div></div>
</blockquote></div><br></div>
</div></div></div><br></div>