Another chapter in the long saga of trying to get source-level debugging working :)<div><br></div><div>I've switched over to using the direct object-file generation instead of generating assembly in hopes of getting around the "<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Fatal error: duplicate .debug_line sections" binutils bug.</span><div>

<font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">I now have 4 different tools for dumping the DWARF info for an object module: dwarfdump, objdump, readelf, and pydevtools. Curiously, they don't all agree on what debugging information is present in an LLVM-generated object file.</span></font></div>

<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">First let me explain what's in the executable. There are several parts:</span></font></div>

<div><ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">First, there are a bunch of .bc files that are generated by my frontend, and which contain debugging metadata (I checked using llvm-dis and the metadata appears to be OK). These are then combined by my linker, tartln, which combines the functions of 'opt' and 'llc', as well as having some custom passes for reflection and garbage collection. (In fact, about half of the source code for tartln was lifted directly from opt and llc, although this cut & paste operation occurred somewhere around the 2.5 timeframe, and I've tried to keep the code up to date since then.)</span></font></li>

<ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">The output of this compilation phase is a .o file.</span></font></li></ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Second, there are some .cpp files that were compiled with gcc. These contain a few runtime support routines for the language, such as stderr output and the code to walk the stack frame (which requires inline assembly.) No, I'm not using clang, as I am trying to minimize build dependencies.</span></font></li>

<ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">The output of this stage is a static library.</span></font></li></ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Finally, the .o and the static libraries are linked together by passing them to gcc. (I wanted to use ld directly, but when I do I get undefined symbol errors for all of the libunwind functions....more detail on that in another thread if anyone is interested. I know that the unwind functions are in some default-linked library, unfortunately which library is not obvious - there's no file named libunwind anywhere in my library path)</span></font></li>

<ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">The result of this stage is an executable.</span></font></li></ul></ul><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Now, when I attempt to dump the debugging info, the following happens:</span></font></div>

</div><div><ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">With dwarfdump -a, I only seem to get a small number of subprogram definitions in the output: 25 total. However, with dwarfdump -i, I get 6141 subprogram defenitions. This is strange given that the docs for dwarfdump claim that -a is a superset of -i.</span></font></li>

<li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">With "readelf --debug-dump" and "objdump --dwarf" I get 6170 subprogram definitions.</span></font></li>

<li><span class="Apple-style-span" style="font-family: arial, sans-serif; border-collapse: collapse; ">pydevtools simply crashes when fed my executable. This may be a bug in pydevtools. It's hard to tell what's going on here, I've debugged it a bit, and it seems like pydevtools is blowing up because the list of ELF sections that it reads is an empty list.</span></li>

<ul><li><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">It would be great if I could get pydevtools working, because it has a GUI browser view for the debugging information - that would be a big help tracking down these problems. Oh well.</span></font></li>

</ul></ul></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">When I attempt to debug this in gdb, it acts as if it can only 'see' the debug definitions coming from gcc, and not any of the ones from my frontend. Doing a stack dump during execution shows symbolic information for the gcc-created functions, and bare machine addresses for the other stuff.</span></font></div>

<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Note that all of the above is on Linux - on OS X I get a completely different set of errors.</span></font></div>

<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">At this point I'd pay money to get this solved....it stopped being fun, oh, about a year ago :)</span></font></div>

<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div>-- <br>-- Talin<br>
</div></div>