[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130211130906.GE6181@port70.net>
Date: Mon, 11 Feb 2013 14:09:07 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/3] Have different definitions of
__pthread_tsd_main agree in size
* Jens Gustedt <jens.gustedt@...ia.fr> [2013-02-11 13:51:24 +0100]:
> > and in case of static linking -fdata-sections
> > and -ffunction-sections just makes the elfheader
> > bigger and the linking slower (sum size of sections
> > may be a bit smaller or bigger because of alignment
> > things)
>
> Still I have good experience by using it on another library that
> defines a lot of weak symbols that aren't used.
>
i've just tried it and the .a just got bigger
and size reports minimal difference probably
due to alignment differences, which does not matter
$ size libc.a.sections |awk '{s+=$4}END{print s}'
410638
$ size libc.a |awk '{s+=$4}END{print s}'
410698
> The only real problem I have for libmusl.so is "environ", as of my
> other patch. There is probably a good reason that this is made
> weak. But why must it be realized as an alias? Wouldn't it be
> sufficient to just have it as a weak symbol? something like
>
> // implementation header file
> extern char **__environ __attribute__((__weak ));
>
> //__environ.c
> char **environ __attribute__((__weak )) = 0;
> weak_alias(environ, ___environ);
> weak_alias(environ, __environ);
> weak_alias(environ, _environ);
>
there are posix requirements for environ so it must be weak
i'm not sure about the alias though
> > so these flags may be useful for building .so
>
> As I said in my previous mail:
>
> > Also I observed that the .so when compiled with -O3 and -flto is
> > smaller than with the default build options.
>
> this is true even without the gc-section stuff. So this is perhaps a
> thing to consider.
>
yes, it is known
but before adding -flto the code should be audited for correctness
(there might be missing barriers where the code works now because
without lto the optimizer cannot reorder code around extern functions,
this probably affects math functions that access fenv, note that
c99 FENV_ACCESS pragma is not respected by gcc and if float operations
are reordered around fe* functions the behaviour changes)
and of course all these flags are fairly recent so they need
configure script changes (and they might be broken so they
need testing)
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.
