[lldb-dev] multiple DW_TAG_compile_unit in 1 ir file

[Carlo Kok]

Op 24-10-2012 01:57, Greg Clayton schreef:
>
> On Oct 23, 2012, at 7:48 AM, Carlo Kok <ck at remobjects.com> 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"

----------------------------------------------------------------------
  File: /Users/ck/Library/Application Support/RemObjects 
Software/Oxygene/CrossBox/c30b0ae7-8aaf-4ea4-b102-845951c60691/Build/CocoaApplication1.o 
(x86_64)
----------------------------------------------------------------------
Verifying Compile Unit Header chain..... ok
Verifying .debug_info... ok

The reason it looks truncated is because of:
0x00000000:     Abbreviation code note found in 'debug_abbrev' class for 
code: 100

the LLVM I use uses a dwarf3 attribute that dwarfdump doesn't support yet.

>
>
>
>
>>
>> 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?

dsymutil: http://pastebin.com/Ju91RHaj

.pas is the extension for the source files my uses.