multiple DW_TAG_compile_unit in 1 ir file

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

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 oke)

nm of the mach-o executable looks wrong:
http://pastebin.com/EyiWc4Dj

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

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?

Op 24-10-2012 01:57, Greg Clayton schreef: