[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160328221052.GJ21636@brightrain.aerifal.cx>
Date: Mon, 28 Mar 2016 18:10:52 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/2] add powerpc64 port
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
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.
