musl - Re: [PATCH 2/2] add powerpc64 port

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56F9B890.9010409@gmail.com>
Date: Tue, 29 Mar 2016 10:04:48 +1100
From: Patrick Oppenlander <pattyo.lists@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/2] add powerpc64 port

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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.