From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9760 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 2/2] add powerpc64 port Date: Mon, 28 Mar 2016 18:10:52 -0400 Message-ID: <20160328221052.GJ21636@brightrain.aerifal.cx> References: <1459113619-24090-1-git-send-email-koorogi@koorogi.info> <1459113619-24090-3-git-send-email-koorogi@koorogi.info> <20160327233709.GE21636@brightrain.aerifal.cx> <56F9A973.2040809@gmail.com> 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 1459203073 4190 80.91.229.3 (28 Mar 2016 22:11:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2016 22:11:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9773-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 29 00:11:12 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1akfNO-0001oD-3r for gllmg-musl@m.gmane.org; Tue, 29 Mar 2016 00:11:10 +0200 Original-Received: (qmail 1579 invoked by uid 550); 28 Mar 2016 22:11:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1561 invoked from network); 28 Mar 2016 22:11:05 -0000 Content-Disposition: inline In-Reply-To: <56F9A973.2040809@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9760 Archived-At: On Tue, Mar 29, 2016 at 09:00:19AM +1100, Patrick Oppenlander wrote: > On 28/03/16 10:37, Rich Felker wrote: > >This is kind of the reason why I was hesitant to add .S support for so > >long. :-) > > > >I don't want to reject it outright, but the idea of adding .S support > >was just to allow conditional compilation, not to do condensed > >assembly sources that require macro expansion. I can see where the > >code might be unwieldy without this though. Anyone else have opinions? > > IMHO .S support is worthwhile just to be able to use constant > definitions in assembly. > > For example, > > __unmapself: > mov r7,#SYS_munmap > svc 0 > mov r7,#SYS_exit > svc 0 > > Is a clearer than: > > __unmapself: > mov r7,#91 > svc 0 > mov r7,#1 > svc 0 > > Especially when approaching the source for the first time. Are there any asm source files making syscalls where it's not obvious from the public contract for the function(s) being implemented which syscall they're making? I think it's just as easy to add a comment with the syscall name if it's unclear, and then the actual number is present too which is nice because it matches the dissembly. The time when it would actually improve things to have symbolic constants in asm files is for places where the constant can actually vary, e.g. due to being derived from an offset in an implementation internal structure or such (like struct __pthread). But preprocessor macros cannot represent that in asm source files anyway. :( Rich