Hello Aaron,
2010/6/11 Aaron Giles <aa...@aarongiles.com>:
>> > Our project (MAME) recently converted a bunch of C code to C++, and
>> as a result our symbol size has bloated tremendously (EXE is now
>> 280MB(!) with symbols, versus 40MB without), killing our link times.
>> Our cohorts on the Linux side have not noticed any significant
>> difference. After some investigation, it looks like the difference is
>> due to stabs versus DWARF debugging information.
>> >
>> > We are using the sezero builds. I tried forcing mingw-w32 to output
>> DWARF-2 (via -gdwarf-2; also tried -ggdb) but the binary size ends up
>> almost identical. I strongly suspect that the compiler was not built
>> with support for generating DWARF symbols and is just ignoring my
>> pleas.
>> >
>> > I know the DWARF EH model is not supported, but from what I
>> understand, the support for DWARF debugging information is independent
>> of the EH model.
>> >
>> > So basically:
>> >
>> > 1. Can you confirm/deny the existence of DWARF debugging support in
>> current sezero builds?
>> >
>> > 2. Are there other builds of the 4.4.x tree we can use that have this
>> enabled?
>> >
>> > 3. Or alternately, Ozkan, can we convince you to turn this on for
>> your builds? :)
>> >
>> > Thanks,
>> > Aaron
>> >
>>
>> Hi,
>>
>> you are confusing dwarf-2 debug and EH, they are different animals. DW-
>> 2
>> debug is already in use with -gdwarf-2, but DW2 EH on win64 don't work
>> at all.
>>
>> There have been work on SEH but its not in GCC yet.
>
> Actually, no, I'm not confusing them, as I stated above: "I know the DWARF EH
> model is not supported, but from what I understand, the support for DWARF
> debugging information is independent of the EH model."
>
> Regardless, after further investigation, it appears that the dwarf-2
> debugging is the default after all, but interestingly for our case -gstabs
> produces much smaller binaries (132MB versus 280MB). Which is contradictory
> to information I've read in other areas where dwarf is supposed to be much
> more efficient.
>
> I still believe there is a significant size discrepancy between mingw and
> linux here. I will gather more information to understand what is going on.
>
> Aaron
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
It is true that dwarf debugging information is much bigger in size.
But in general you have here different possiblities to solve this.
First of course by the debugging-level switch -g<n>. Additionally you
can use object-copy tool to split debugging information into an
separate file.
The gstabs information isn't possible for x64, so I would recomment
that you stick to the dwarf-2 information. In 4.4.x and 4.5.x series
there are some tweak about debugging information and inlined code. To
avoid this don't use debugging information (or strip them out into
separate debugging file) for optimization levels >= 1.
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
