On Oct 23, 2012, at 7:48 AM, Carlo Kok <[email protected]> wrote: > Op 22-10-2012 10:43, Carlo Kok schreef: >> LLVM's debug info generator is perfect happy with multiple >> DW_TAG_compile_unit's in 1 IR file. >> >> Even after compiling to .o, the object file contains two of them, >> however when linking with ld (osx) and then loading with LLDB there's >> only one eSymbolTypeObjectFile in the file (Which make sense) and an >> eSymbolTypeSourceFile "source" before that so during debugging, it only >> accepts the first source file for breakpoints. Is there a way to change >> how I emit it in LLVM or fix in LLDB to get this to work properly? >> >> My IR (compiled as x86_64): >> http://pastebin.com/DAF7nhDe > > dwarfdump of the file: > http://pastebin.com/CYarpscv > > (looks ok)
The DWARF is _not_ OK. it is truncated and can't find the abbeviation code for the first DIE inside the compile unit. Try running dwarfdump with the --verify option (if you are running the MacOSX version of dwarfdump: dwarfdump --verify "/Users/ck/Library/Application Support/RemObjects Software/Oxygene/CrossBox/c30b0ae7-8aaf-4ea4-b102-845951c60691/Build/CocoaApplication1.o" > > nm of the mach-o executable looks wrong: > http://pastebin.com/EyiWc4Dj Don't use "nm", it likes to reorder your symbols and the symbol ordering is very important. Try dsymutil with the -s option: dsymutil -s ./c30b0ae7-8aaf-4ea4-b102-845951c60691/CocoaApplication1 It looks ok from what I can tell. Though the ".pas" extension on the source files looks worrysome? > > > one file is seen as a source file while the other is seen as "include" > > SOL AppDelegate.pas << include > SO C:\Users\Carlo\Documents\Visual Studio > 2012\Projects\CocoaApplication1\CocoaApplication1/ > SO Program.pas > > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
