Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Oct 2015 17:01:24 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] configure: add gcc flags for better link-time
 optimization

On Tue, Oct 27, 2015 at 08:09:28PM +0100, Denys Vlasenko wrote:
> On Tue, Oct 27, 2015 at 2:21 AM, Rich Felker <dalias@...c.org> wrote:
> > On Fri, Oct 23, 2015 at 03:12:02PM +0200, Szabolcs Nagy wrote:
> >> * Denys Vlasenko <vda.linux@...glemail.com> [2015-10-23 14:30:26 +0200]:
> >> > libc.so size reduction:
> >> >
> >> >    text        data     bss     dec     hex filename
> >> >  564099        1944   11768  577811   8d113 libc.so.before
> >> >  562277        1924   11576  575777   8c921 libc.so
> >> >
> >>
> >> i assume this is x86_64, nice improvement.
> >
> > I suspect all of this difference comes from optimizing out dummy weak
> > functions that are replaced by strong versions in other files.
> 
> No, it does not look that way. These options don't give linker
> any extra freedom to eliminate anything.
> 
> "nm --size-sort -D libc.so" shows no differences after
> 
>    --sort-section=alignment --sort-common
> 
> were added to ld command line.

Oh, sorry, I misread which change that difference was coming from. In
that case it's a pleasant surprise.

> After -ffunction-sections -fdata-sections are added to gcc command line,
> "nm" output does change, the entire difference is as follows:
> 
> --- libc.so.nm.OLD       2015-10-27 19:57:52.971964518 +0100
> +++ libc.so.nm  2015-10-27 19:58:28.544115009 +0100
> @@ -18,7 +18,6 @@
>  0000000000000001 T setutxent
>  0000000000000001 W updwtmp
>  0000000000000001 T updwtmpx
> -0000000000000002 T dlclose
>  0000000000000002 T __stack_chk_fail
>  0000000000000003 T catclose
>  0000000000000003 T dirfd
> @@ -84,6 +83,7 @@
>  0000000000000005 T catopen
>  0000000000000005 T creall
>  0000000000000005 T dladdr
> +0000000000000005 T dlclose
>  0000000000000005 T dlinfo
>  0000000000000005 T __fbufsize
>  0000000000000005 T __freadptrinc
> @@ -328,7 +328,6 @@
>  000000000000000b T recv
>  000000000000000b T send
>  000000000000000b T setprotoent
> -000000000000000b T tfind
>  000000000000000b T __xstat
>  000000000000000b W __xstat64
>  000000000000000c T __acquire_ptc
> @@ -417,6 +416,7 @@
>  000000000000000e T tcflow
>  000000000000000e T tcflush
>  000000000000000e T tcsendbreak
> +000000000000000e T tfind
>  000000000000000f T dcgettext
>  000000000000000f T execv
>  000000000000000f T execvp
> @@ -986,8 +986,6 @@
>  0000000000000032 T pthread_rwlock_init
>  0000000000000032 T putchar_unlocked
>  0000000000000032 T sem_init
> -0000000000000032 T __stdio_exit
> -0000000000000032 W __stdio_exit_needed
>  0000000000000032 T wcschr
>  0000000000000033 T pthread_rwlock_tryrdlock
>  0000000000000033 T pthread_setcanceltype
> @@ -1011,6 +1009,8 @@
>  0000000000000035 T pthread_sigmask
>  0000000000000035 T pwritev
>  0000000000000035 W pwritev64
> +0000000000000035 T __stdio_exit
> +0000000000000035 W __stdio_exit_needed
>  0000000000000035 W thrd_detach
>  0000000000000035 T __tre_mem_destroy
>  0000000000000035 T tsearch
> 
> As you see, not a single label was eliminated.
> 
> 
> The visible small differences in size for a few functions are caused
> by the need to always use "near" jumps (not "short" ones)
> for tail call optimizations now, since they now jump across sections:
> 
> Before:
> 00000000000274a6 <dlclose>:
>    274a6:       eb c8                   jmp    27470 <__reset_tls+0x1f0>
> After:
> 000000000002795f <dlclose>:
>    2795f:       e9 c5 ff ff ff          jmpq   27929 <__reset_tls+0x1f0>

I see. That's probably not a big deal.

Did you see any symbols disappear when adding --gc-sections?

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.