[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1360589888.9132.104.camel@eris.loria.fr>
Date: Mon, 11 Feb 2013 14:38:08 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/3] Have different definitions of
__pthread_tsd_main agree in size
Am Montag, den 11.02.2013, 14:09 +0100 schrieb Szabolcs Nagy:
> 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
yes, for musl it probably isn't a big deal, because musl is basically
already divided in one compilation unit per function. As I said, the
only unused sections that drop out are those for the weak aliases that
finally have their real symbol linked in.
For other libraries that define weak symbols that are not needed later
this is more relevant. With P99 I have the opposite position to musl
(sort of). Everything are inline functions if possible (so they don't
even define a symbol) only some functions have to be weak because they
access to some static data or use setjmp. (P99 doesn't even have a
libp99.a or libp99.so file).
With the gc-section trick I can suck out the unused symbols from the
executable at the end.
> > 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
Anyhow the use of environ versus __environ was just not consistent
through the rest of musl. I have send another patch that should heal
that.
But thinking of it, I am not sure that the way that is done makes any
sense. If the reason to have environ weak is that the user code could
supply its own environ object, then the use of __environ all over musl
will certainly break things. Then environ and __environ could be two
different objects and the application code and musl would not be
consistent in their access to the environment.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
