On 18/09/2013, at 4:22 PM, Konstantin Belousov wrote:
> On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote:
>> [ ... ]
>> Honestly, I think we can assume we'll never reach the point where all
>> the components listed above will properly have all functions
>> partitioned over separate co
On 18/09/2013, at 6:42 PM, Konstantin Belousov wrote:
> On Wed, Sep 18, 2013 at 05:36:40PM +1000, Jan Mikkelsen wrote:
>>
>> On 18/09/2013, at 4:22 PM, Konstantin Belousov wrote:
>>
>>> On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote:
[ ... ]
Honestly, I think we can ass
On 18 Sep 2013, at 07:22, Konstantin Belousov wrote:
> I think this is a wrong direction. First, the split should be done at
> the source level, as it was usually done forever.
Until we are all using toolchains that support LTO (which requires importing a
new linker and will make people who com
On Wed, Sep 18, 2013 at 05:36:40PM +1000, Jan Mikkelsen wrote:
>
> On 18/09/2013, at 4:22 PM, Konstantin Belousov wrote:
>
> > On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote:
> >> [ ... ]
> >> Honestly, I think we can assume we'll never reach the point where all
> >> the components
(Copy for the list, wrong "from" address problem ...)
On 18/09/2013, at 4:22 PM, Konstantin Belousov wrote:
> On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote:
>> [...]
>> Honestly, I think we can assume we'll never reach the point where all
>> the components listed above will properl
On Sun, 15 Sep 2013 19:30:01 -0700
Tim Kientzle wrote:
>
> On Sep 15, 2013, at 2:24 PM, Ed Schouten wrote:
> > GCC and Clang support the -ffunction-sections and -fdata-sections
> > flags. Essentially, these flags force the compiler to put every
> > function and variable in its own section. Thou
On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote:
> Hi Matthew,
>
> 2013/9/16 Matthew Fleming :
> > Would it be possible to enable this only for devd, init, and clang binaries?
> > Or is it a matter of enabling it for library builds that are linked
> > statically with the mentioned bina
On Tue, 2013-09-17 at 16:31 -0700, Adrian Chadd wrote:
> On 17 September 2013 16:22, Ian Lepore wrote:
>
> > On Tue, 2013-09-17 at 14:56 -0700, Adrian Chadd wrote:
> > > ... I'd rather see if we can actually separate out things some more so
> > > these builds can shrink.
> > >
> > > Eg, if there'
On Sep 17, 2013 4:31 PM, "Adrian Chadd" wrote:
>
> On 17 September 2013 16:22, Ian Lepore wrote:
>
> > On Tue, 2013-09-17 at 14:56 -0700, Adrian Chadd wrote:
> > > ... I'd rather see if we can actually separate out things some more so
> > > these builds can shrink.
> > >
> > > Eg, if there's mall
On 17 September 2013 16:22, Ian Lepore wrote:
> On Tue, 2013-09-17 at 14:56 -0700, Adrian Chadd wrote:
> > ... I'd rather see if we can actually separate out things some more so
> > these builds can shrink.
> >
> > Eg, if there's malloc related functions that aren't used, maybe we should
> > brea
On Tue, 2013-09-17 at 14:56 -0700, Adrian Chadd wrote:
> ... I'd rather see if we can actually separate out things some more so
> these builds can shrink.
>
> Eg, if there's malloc related functions that aren't used, maybe we should
> break malloc down into a directory full of functions.
>
Why i
Adrian Chadd wrote this message on Tue, Sep 17, 2013 at 14:56 -0700:
> ... I'd rather see if we can actually separate out things some more so
> these builds can shrink.
>
> Eg, if there's malloc related functions that aren't used, maybe we should
> break malloc down into a directory full of functi
Hi Matthew,
2013/9/16 Matthew Fleming :
> Would it be possible to enable this only for devd, init, and clang binaries?
> Or is it a matter of enabling it for library builds that are linked
> statically with the mentioned binaries?
For it to have effect, it has to be enabled for both the libraries
... I'd rather see if we can actually separate out things some more so
these builds can shrink.
Eg, if there's malloc related functions that aren't used, maybe we should
break malloc down into a directory full of functions.
I'm not surprised libc++ is doing .. that. It's likely better on the
comp
On 16 Sep 2013, at 07:52, Dimitry Andric wrote:
> On Sep 16, 2013, at 03:08, Adrian Chadd wrote:
>>> The results are interesting. On amd64:
>>>
>>> - devd suddenly becomes 500 KB in size, instead of a megabyte,
>>> - init's size drops from 900 KB to 600 KB,
>>> - clang becomes a megabyte smalle
On Sep 16, 2013, at 03:08, Adrian Chadd wrote:
>> The results are interesting. On amd64:
>>
>> - devd suddenly becomes 500 KB in size, instead of a megabyte,
>> - init's size drops from 900 KB to 600 KB,
>> - clang becomes a megabyte smaller.
>>
>
> .. so, I'd like to know specific information
In message
, Ed Schouten writes:
>Thoughts?
Jordan and I would have killed for that 19 years ago...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequ
On Sep 15, 2013, at 2:24 PM, Ed Schouten wrote:
> GCC and Clang support the -ffunction-sections and -fdata-sections
> flags. Essentially, these flags force the compiler to put every
> function and variable in its own section. Though this will blow up the
….
> - devd suddenly becomes 500 KB in siz
>
>
> The results are interesting. On amd64:
>
> - devd suddenly becomes 500 KB in size, instead of a megabyte,
> - init's size drops from 900 KB to 600 KB,
> - clang becomes a megabyte smaller.
>
.. so, I'd like to know specific information as to why these three are now
smaller. So what's going o
On Sun, Sep 15, 2013 at 2:24 PM, Ed Schouten wrote:
> Hi all,
>
> Today I did a tiny experiment and I am not entirely sure what to do.
> Throw away the patch or eventually push it into the tree.
>
> GCC and Clang support the -ffunction-sections and -fdata-sections
> flags. Essentially, these flag
Hi all,
Today I did a tiny experiment and I am not entirely sure what to do.
Throw away the patch or eventually push it into the tree.
GCC and Clang support the -ffunction-sections and -fdata-sections
flags. Essentially, these flags force the compiler to put every
function and variable in its own
21 matches
Mail list logo
