Thanks Andrew! You get first prize for most informative intelligent answer so far! Careful, you might get second prize too :-)
The problem is that we need to find a way to tell people _what_ is in that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and goes about its business. That's probably why OpenBSD gcc 4.9 binaries are 17MB against the 64MB compiled by gcc 4.9. But that is a really fucking big dwarf they're stuffing in threre. What is the data, really? We can't just say "it's dwarf" because that doesn't really mean a whole lot, does it? Thanks again for your helpful response. This is progress. Ian On Fri, Sep 19, 2014 at 8:04 PM, Andrew Pinski <pins...@gmail.com> wrote: > On Fri, Sep 19, 2014 at 4:52 PM, Ian Grant <ian.a.n.gr...@googlemail.com> > wrote: >> None of this is useful to me. I'm trying to make a case for why people >> should have confidence in GNU software. You are NOT helping me in >> that, I assure you, > > Again, try stripping out debugging information and look at the numbers > again. Or better yet use size printing out all of the sections rather > than the default output which combines some section and does not show > the debugging information, > > From a different email: >> > BTW, if "size" is reporting much smaller size than the executable >> > file itself and that motivates this concern, most of the difference >> > is likely to be debug info, which is bigger since gcc switched to >> > C++. Might want to try "strip". > >> Great. As I said, the exercise we are here engaged in is to convince >> as many people as possible that GCC does NOT suffer from this problem >> on any OS, either OS, Windows, OpenBSD, FreeBSD, Solaris, or Linux on >> any arch., including IBM System z. > > Then don't use size with the default options but rather with the sysv > style output (-A) and look at all of the sections. > > >> >> We need to publish some simple steps that people can take to reassure >> themselves that the 64MB binaries that GCC 4.9 produces on Linux >> systems are normal and nothing to worry about, > > Debugging information is increasing a lot. Writing GCC in C++ has > caused this issue because there is no removing of debugging > information yet in dwarf2/3/4, I think there is plans for it but I > can't remember if it made it into dwarf5 or not. > > Thanks, > Andrew Pinski > >> >> Why is that so hard? Where are the GCC experts on this list. Where are >> the people that actually care about the reputation of the FSF? >> >> Ian >> >> >> On Fri, Sep 19, 2014 at 7:15 PM, Jonathan Wakely <jwakely....@gmail.com> >> wrote: >>> On 20 September 2014 00:01, Jonathan Wakely wrote: >>>> On 19 September 2014 16:21, Ian Grant wrote: >>>>> Thanks. But I asked what the non-vanilla sources were. I know what >>>>> the vanilla sources are, because I'm using them! >>>> >>>> The non-vanilla sources are everything else. That should be pretty obvious. >>> >>> Or as it says in the text you quoted: >>> >>> "This is in contrast to modified source from distribution for instance >>> that will usually add some patches" >>> >>> Vanilla source == unmodified source >>> >>> Non-vanilla source == modified source >>> >>> Any modified source. If OpenBSD modifies the source, it's non-vanilla. >>> If Debian modifies the source, it's non-vanilla. >>> >>> Personally I don't like the terms vanilla and non-vanilla but I think >>> their meanings are fairly clear.
