From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2804 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 0/5] reorganize the use of weak symbols Date: Sat, 16 Feb 2013 00:59:37 -0500 Message-ID: <20130216055937.GC20323@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1360994391 16670 80.91.229.3 (16 Feb 2013 05:59:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Feb 2013 05:59:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2805-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 16 07:00:13 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1U6aok-0005U1-LW for gllmg-musl@plane.gmane.org; Sat, 16 Feb 2013 07:00:10 +0100 Original-Received: (qmail 15668 invoked by uid 550); 16 Feb 2013 05:59:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15657 invoked from network); 16 Feb 2013 05:59:50 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2804 Archived-At: On Sat, Feb 16, 2013 at 12:22:03AM +0100, Jens Gustedt wrote: > Weak symbols are used for several uses that are in fact quite distinct. First some general comments -- I think this patchset might be arising as a result of a clash of style/philosophy. As an analogy, "int" can be be used for several things that are distinct. If there's a possibility that int could be the wrong type on some systems or configurations, it makes sense to use a typedef and a distinct type name. But if int were already the correct type in all cases, using a typedef just creates a barrier to reading comprehension in the code -- the reader has to go lookup what the type is defined as, only to find that it's unconditionally "int". A great example of this kind of obfuscation is glib. In my view, what's going on here is in some ways similar. Weak aliases are the right mechanism in all cases, but if you hide that with different usage-specific macros, you create a barrier to reading where the reader might think there's something more complicated going on behind all the different macros. As for weak functions rather than aliases, it was a conscious choice early on to use a minimum number of gcc- or gnu-linker-specific features. Unlike other weak symbol related features, weak aliases are universally available on all unix-like toolchains; they were even part of SVID, which specifies #pragma weak to define them; a C99 compiler following this practice would necessarily need to support _Pragma weak, which could be used to define the weak_alias macro in a "portable" way. Whether there's any practical value now to minimizing the use of non-essential gcc features is open to question, but I see no need to gratuitously increase the number used. With that said, one thing I highly agree with in your patchset is documenting the different weak alias tricks used in musl -- specifically, commenting on which weak aliases are expected to be replaced by strong definitions, and under what conditions those strong definitions come into place. I also can see some use for having common dummy functions, but I'd have to review how you're proposing to do it because I remember looking into this before and finding that it didn't work as I expected. However, the savings are likely to be very small, since dummy functions are typically just 1-2 bytes on x86 (depending on the -mtune mode) and 4 bytes on risc archs. I'll give a more detailed review of individual patches later; I just wanted to get this email off so you have ideas early on where you're probably going to run into differences of opinion. Rich