From: Patrick Oppenlander <pattyo.lists@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [PATCH 2/2] add powerpc64 port
Date: Tue, 29 Mar 2016 10:04:48 +1100 [thread overview]
Message-ID: <56F9B890.9010409@gmail.com> (raw)
In-Reply-To: <20160328221052.GJ21636@brightrain.aerifal.cx>
On 29/03/16 09:10, Rich Felker wrote:
> 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.
I guess the reason I chose that particular example because it was one of
my recent pain points porting musl to a small embedded RTOS.
A comment would probably have been sufficient -- at least then 'grep'
would have found it.
> 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. :(
I have seen a solution to this problem. Can't exactly remember where but
the gist of it was to hack some gcc inline assembly together to generate
the required offset constants:
test.c:
struct test {
int a;
int b;
};
#define offset(def, struct, member) \
__asm__("\n#define " def " %0" :: "i" (__builtin_offsetof(struct,
member)))
void offsets(void)
{
offset("A_OFFSET", struct test, a);
offset("B_OFFSET", struct test, b);
}
compile with gcc -S test.c to generate test.s:
.file "test.c"
.text
.globl offsets
.type offsets, @function
offsets:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
#APP
# 11 "test.c" 1
#define A_OFFSET $0
# 0 "" 2
# 12 "test.c" 1
#define B_OFFSET $4
# 0 "" 2
#NO_APP
nop
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size offsets, .-offsets
.ident "GCC: (GNU) 5.3.0"
.section .note.GNU-stack,"",@progbits
pull out the #defines with sed -ne '/^#define/ s/\$// p' test.s
#define A_OFFSET 0
#define B_OFFSET 4
Somewhat grotesque, but it works.
Patrick
prev parent reply other threads:[~2016-03-28 23:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-27 21:20 [RFC] " Bobby Bingham
2016-03-27 21:20 ` [PATCH 1/2] add 64bit atomics on top of 64bit ll/sc primitives Bobby Bingham
2016-03-27 22:27 ` Rich Felker
2016-03-27 21:20 ` [PATCH 2/2] add powerpc64 port Bobby Bingham
2016-03-27 23:37 ` Rich Felker
2016-03-28 0:32 ` Bobby Bingham
2016-03-28 2:18 ` Rich Felker
2016-03-28 3:27 ` Szabolcs Nagy
2016-04-02 17:02 ` Bobby Bingham
2016-04-03 2:09 ` Rich Felker
2016-04-03 17:10 ` Bobby Bingham
2016-04-03 17:26 ` Rich Felker
2016-04-03 17:50 ` Bobby Bingham
2016-04-04 4:03 ` Bobby Bingham
2016-04-04 10:41 ` Szabolcs Nagy
2016-03-28 22:00 ` Patrick Oppenlander
2016-03-28 22:10 ` Rich Felker
2016-03-28 23:04 ` Patrick Oppenlander [this message]
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=56F9B890.9010409@gmail.com \
--to=pattyo.lists@gmail.com \
--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).