[lldb-dev] Problem with large sym files (dsymutil speed)

[Greg Clayton]

No, I know why things are failing: we are hitting the limits of the mach-o file format. There isn't anything we can do other than try the:

-flimit-debuginfo 

compiler flag. Add this to your builds (if you are using clang or llvm-gcc) and let me know how things work??

Greg


On Sep 26, 2011, at 1:49 PM, Somorjai, Akos wrote:

> One more thing: the .o files for the main executable only are nearly 8 GBs
> in size; am I allowed to upload such amount to radar?
> 
> Best,
> 
> Ákos 
> 
> 
> 
> On 9/26/11 7:09 PM, "Greg Clayton" <gclayton at apple.com> wrote:
> 
>> Ok, run the commands on your main executable that looks at all .o files
>> and let me know what sizes it comes up with. I am guessing you probably
>> can't file a bug and attach your executable and .o files? (no source
>> would be needed). If I can reproduce the issue, I can fix it.
>> 
>> Greg Clayton
>> 
>> On Sep 26, 2011, at 10:03 AM, Somorjai, Akos wrote:
>> 
>>> It's at least 39 MB-s; I can't tell exactly because dsymutil bails out
>>> (the original problem).
>>> I have a feeling that we are going in circles :)
>>> 
>>> Best, Ákos
>>> 
>>> 2011.09.26. dátummal, 18:57 időpontban "Greg Clayton"
>>> <gclayton at apple.com> írta:
>>> 
>>>> If you are linking a single architecture, unfortunately there isn't
>>>> much you can do. Linking DWARF is a serialized process where we take
>>>> DWARF from a bunch of .o files and then make a single out file. All
>>>> DWARF sections have to be appended to one another and they have
>>>> interdependencies, so even though dsymutil does use multi-threading to
>>>> parse 8 .o files ahead, it doesn't help in the long run. clang and
>>>> llvm-gcc make debug info that is around 4 times bigger that gcc, so
>>>> this probably makes things worse for you guys.
>>>> 
>>>> How big is your dSYM file?
>>>> 
>>>> On Sep 26, 2011, at 6:38 AM, Somorjai, Akos wrote:
>>>> 
>>>>> Greg,
>>>>> 
>>>>> Another issue is dsymutil's speed; it takes about 10 minutes to run
>>>>> it on
>>>>> our main executable, which is more than unbearable. Is their anything
>>>>> we
>>>>> can do to reduce that time?
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Akos
>>>>> 
>>>> 
>> 
>