<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 15, 2013 at 3:17 PM, Alireza Moshtaghi <span dir="ltr"><<a href="mailto:Alireza.Moshtaghi@synopsys.com" target="_blank">Alireza.Moshtaghi@synopsys.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
I'm trying to annotate the final assembly output of my llvm codegen with the corresponding input C statements.<br>
It would've been super easy if the source information were included in the IR debug info. But obviously they are not, and there are good reasons why not !<br>
So I'm bound to collecting all my information in the back-end from the existing debug pseudo instructions. As you know, the debug instructions only have file name and line number information. But without actually parsing the input file and collecting the C statement and function start and end line numbers in the file, it would be a non-trivial task to emit proper source line information in the output assembly. Obviously, it is not recommended to use clang objects in the backend either, so I was wondering if anyone in the llvm community has attempted this before. Currently, I'm planning on writing my own parser but if someone has better solutions, please let me know.<br>
</blockquote><div><br></div><div><br></div><div style>What, specifically, do you need a parser for? Specifying file+line pairs in debug info is standard practice. The debugger should then have access to the original C source file to show the code. Including input C code into every binary with debug info would blow up its size considerably (C files include a lot of code from include files...) and is unnecessary. Why is displaying a line of C code corresponding to some file+line pair more than just reading a specific line from a given file?</div>
<div style><br></div><div style>Eli</div><div style><br></div></div></div></div>