mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: [PATCH 2/3] Have different definitions of __pthread_tsd_main agree in size
Date: Mon, 11 Feb 2013 14:09:07 +0100	[thread overview]
Message-ID: <20130211130906.GE6181@port70.net> (raw)
In-Reply-To: <1360587084.9132.83.camel@eris.loria.fr>

* Jens Gustedt <jens.gustedt@inria.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)


  reply	other threads:[~2013-02-11 13:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-10 22:32 Jens Gustedt
2013-02-11  0:31 ` Rich Felker
2013-02-11  7:40   ` Jens Gustedt
2013-02-11 11:22     ` Szabolcs Nagy
2013-02-11 12:08       ` Szabolcs Nagy
2013-02-11 12:51         ` Jens Gustedt
2013-02-11 13:09           ` Szabolcs Nagy [this message]
2013-02-11 13:38             ` Jens Gustedt
2013-02-11 13:44               ` Rich Felker
2013-02-11 14:07                 ` Jens Gustedt
2013-02-11 14:39                   ` Szabolcs Nagy
2013-02-11 16:30                     ` Jens Gustedt
2013-02-11 17:08                       ` Szabolcs Nagy
2013-02-11 17:21                         ` Jens Gustedt
2013-02-11 21:49                           ` Rich Felker
2013-02-11 21:47                   ` Rich Felker
2013-02-11 21:50                     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130211130906.GE6181@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).