[PATCH] arm asm for vfork

[PATCH] arm asm for vfork

[patrick.oppenlander]

I have an application which requires proper vfork support so I had a go at
adding it to musl.

Hope this is useful,

Patrick

[PATCH] arm asm for vfork

[patrick.oppenlander]

From: Patrick Oppenlander <patrick.oppenlander@gmail.com>

---
 src/process/arm/vfork.s | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 src/process/arm/vfork.s

diff --git a/src/process/arm/vfork.s b/src/process/arm/vfork.s
new file mode 100644
index 00000000..f01fe1d0
--- /dev/null
+++ b/src/process/arm/vfork.s
@@ -0,0 +1,12 @@
+.syntax unified
+.global __vfork
+.weak vfork
+.type __vfork,%function
+.type vfork,%function
+__vfork:
+vfork:
+	mov ip, r7
+	mov r7, 190
+	swi 0
+	mov r7, ip
+	b __syscall_ret
-- 
2.17.0

Re: [PATCH] arm asm for vfork

[Rich Felker]

On Mon, Apr 30, 2018 at 11:36:22AM +1000, patrick.oppenlander@gmail.com wrote:
> From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
> 
> ---
>  src/process/arm/vfork.s | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>  create mode 100644 src/process/arm/vfork.s
> 
> diff --git a/src/process/arm/vfork.s b/src/process/arm/vfork.s
> new file mode 100644
> index 00000000..f01fe1d0
> --- /dev/null
> +++ b/src/process/arm/vfork.s
> @@ -0,0 +1,12 @@
> +.syntax unified
> +.global __vfork
> +.weak vfork
> +.type __vfork,%function
> +.type vfork,%function
> +__vfork:
> +vfork:
> +	mov ip, r7
> +	mov r7, 190
> +	swi 0
> +	mov r7, ip
> +	b __syscall_ret
> -- 
> 2.17.0

Thanks. We'll need this for nommu users; right now that's not so
practical but it will be once we get fdpic added.

I haven't tested, but the patch looks right. Elsewhere we use svc
instead of swi; not sure if that matters.

Rich

Re: [PATCH] arm asm for vfork

[Patrick Oppenlander]

You're right, it's not particularly pleasant. I have an MIMXRT1050-EVK
board which is what this is for -- it's a 600MHz Cortex-M7 with a
32MiB DRAM for about $80USD. More than enough to run my kernel and a
few other bits and pieces for now even with the overhead of copying
the program text.

Are there plans for fdpic in musl as soon as GCC supports it?

SVC is just a name change from SWI. Old habits die hard I guess. In my
brain SWI makes more sense as it really is an interrupt and not a
call.

I won't bother resubmitting a patch for that though.

Patrick




On Mon, Apr 30, 2018 at 12:09 PM, Rich Felker <dalias@libc.org> wrote:
> On Mon, Apr 30, 2018 at 11:36:22AM +1000, patrick.oppenlander@gmail.com wrote:
>> From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
>>
>> ---
>>  src/process/arm/vfork.s | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>  create mode 100644 src/process/arm/vfork.s
>>
>> diff --git a/src/process/arm/vfork.s b/src/process/arm/vfork.s
>> new file mode 100644
>> index 00000000..f01fe1d0
>> --- /dev/null
>> +++ b/src/process/arm/vfork.s
>> @@ -0,0 +1,12 @@
>> +.syntax unified
>> +.global __vfork
>> +.weak vfork
>> +.type __vfork,%function
>> +.type vfork,%function
>> +__vfork:
>> +vfork:
>> +     mov ip, r7
>> +     mov r7, 190
>> +     swi 0
>> +     mov r7, ip
>> +     b __syscall_ret
>> --
>> 2.17.0
>
> Thanks. We'll need this for nommu users; right now that's not so
> practical but it will be once we get fdpic added.
>
> I haven't tested, but the patch looks right. Elsewhere we use svc
> instead of swi; not sure if that matters.
>
> Rich

Re: [PATCH] arm asm for vfork

[Patrick Oppenlander]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

Hi Rich,

I saw another thread where it was mentioned you may be doing a 1.20
release some time soon.

Is there any chance this could get merged in time? I've been running
it for months without any issues now.

Attached is an updated patch using svc rather than swi.

Thanks,

Patrick
On Mon, Apr 30, 2018 at 12:32 PM Patrick Oppenlander
<patrick.oppenlander@gmail.com> wrote:
>
> You're right, it's not particularly pleasant. I have an MIMXRT1050-EVK
> board which is what this is for -- it's a 600MHz Cortex-M7 with a
> 32MiB DRAM for about $80USD. More than enough to run my kernel and a
> few other bits and pieces for now even with the overhead of copying
> the program text.
>
> Are there plans for fdpic in musl as soon as GCC supports it?
>
> SVC is just a name change from SWI. Old habits die hard I guess. In my
> brain SWI makes more sense as it really is an interrupt and not a
> call.
>
> I won't bother resubmitting a patch for that though.
>
> Patrick
>
>
>
>
> On Mon, Apr 30, 2018 at 12:09 PM, Rich Felker <dalias@libc.org> wrote:
> > On Mon, Apr 30, 2018 at 11:36:22AM +1000, patrick.oppenlander@gmail.com wrote:
> >> From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
> >>
> >> ---
> >>  src/process/arm/vfork.s | 12 ++++++++++++
> >>  1 file changed, 12 insertions(+)
> >>  create mode 100644 src/process/arm/vfork.s
> >>
> >> diff --git a/src/process/arm/vfork.s b/src/process/arm/vfork.s
> >> new file mode 100644
> >> index 00000000..f01fe1d0
> >> --- /dev/null
> >> +++ b/src/process/arm/vfork.s
> >> @@ -0,0 +1,12 @@
> >> +.syntax unified
> >> +.global __vfork
> >> +.weak vfork
> >> +.type __vfork,%function
> >> +.type vfork,%function
> >> +__vfork:
> >> +vfork:
> >> +     mov ip, r7
> >> +     mov r7, 190
> >> +     swi 0
> >> +     mov r7, ip
> >> +     b __syscall_ret
> >> --
> >> 2.17.0
> >
> > Thanks. We'll need this for nommu users; right now that's not so
> > practical but it will be once we get fdpic added.
> >
> > I haven't tested, but the patch looks right. Elsewhere we use svc
> > instead of swi; not sure if that matters.
> >
> > Rich

[-- Attachment #2: 0001-arm-asm-for-vfork.patch --]
[-- Type: text/x-patch, Size: 690 bytes --]

From b0e59bb68cb102fa8d397628a3248a2049150d74 Mon Sep 17 00:00:00 2001
From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Date: Tue, 10 Apr 2018 11:01:25 +1000
Subject: [PATCH] arm asm for vfork

---
 src/process/arm/vfork.s | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 src/process/arm/vfork.s

diff --git a/src/process/arm/vfork.s b/src/process/arm/vfork.s
new file mode 100644
index 00000000..db4e7b43
--- /dev/null
+++ b/src/process/arm/vfork.s
@@ -0,0 +1,12 @@
+.syntax unified
+.global __vfork
+.weak vfork
+.type __vfork,%function
+.type vfork,%function
+__vfork:
+vfork:
+	mov ip, r7
+	mov r7, 190
+	svc 0
+	mov r7, ip
+	b __syscall_ret
-- 
2.18.0

Re: [PATCH] arm asm for vfork

[Rich Felker]

On Wed, Jul 18, 2018 at 12:20:00PM +1000, Patrick Oppenlander wrote:
> Hi Rich,
> 
> I saw another thread where it was mentioned you may be doing a 1.20
> release some time soon.
> 
> Is there any chance this could get merged in time? I've been running
> it for months without any issues now.
> 
> Attached is an updated patch using svc rather than swi.

Thanks. One detail:

> diff --git a/src/process/arm/vfork.s b/src/process/arm/vfork.s
> new file mode 100644
> index 00000000..db4e7b43
> --- /dev/null
> +++ b/src/process/arm/vfork.s
> @@ -0,0 +1,12 @@
> +.syntax unified
> +.global __vfork
> +.weak vfork
> +.type __vfork,%function
> +.type vfork,%function
> +__vfork:
> +vfork:
> +	mov ip, r7
> +	mov r7, 190
> +	svc 0
> +	mov r7, ip
> +	b __syscall_ret
> -- 

I think there needs to be a ".hidden __syscall_ret" (by de facto musl
convention, on the line before it's used) here. It *might* be ok
having the reference omit .hidden as long as the definition is hidden
at link-time (which it is), but I'm not convinced the tooling won't
complain about a branch to a destination that's not known to be
link-time constant displacement.

If you have no other changes or comments I'm happy to just --amend
that into the patch when I commit it.

Rich

Re: [PATCH] arm asm for vfork

[Patrick Oppenlander]

On Wed, Jul 18, 2018 at 12:35 PM Rich Felker <dalias@libc.org> wrote:
> I think there needs to be a ".hidden __syscall_ret" (by de facto musl
> convention, on the line before it's used) here. It *might* be ok
> having the reference omit .hidden as long as the definition is hidden
> at link-time (which it is), but I'm not convinced the tooling won't
> complain about a branch to a destination that's not known to be
> link-time constant displacement.

If that's the case  i386, s390x, x86_64 and x32 may need attention in
vfork.s as they're doing it the same way.

> If you have no other changes or comments I'm happy to just --amend
> that into the patch when I commit it.

No problem with that at all.

Thanks,

Patrick

Re: [PATCH] arm asm for vfork

[Christopher Friedt]

[-- Attachment #1: Type: text/plain, Size: 116 bytes --]

I'm actually excited for this, having done something similar with another
embedded libc for cortex-m3 a while back.

[-- Attachment #2: Type: text/html, Size: 145 bytes --]

Re: [PATCH] arm asm for vfork

[Patrick Oppenlander]

On Wed, Jul 18, 2018 at 6:14 AM Patrick Oppenlander
<patrick.oppenlander@gmail.com> wrote:
>
> On Wed, Jul 18, 2018 at 12:35 PM Rich Felker <dalias@libc.org> wrote:
> > I think there needs to be a ".hidden __syscall_ret" (by de facto musl
> > convention, on the line before it's used) here. It *might* be ok
> > having the reference omit .hidden as long as the definition is hidden
> > at link-time (which it is), but I'm not convinced the tooling won't
> > complain about a branch to a destination that's not known to be
> > link-time constant displacement.
>
> If that's the case  i386, s390x, x86_64 and x32 may need attention in
> vfork.s as they're doing it the same way.
>
> > If you have no other changes or comments I'm happy to just --amend
> > that into the patch when I commit it.
>
> No problem with that at all.
>

I guess this one slipped through the cracks for 1.20.

Any chance of you taking a look soon?

Thanks,

Patrick

Re: [PATCH] arm asm for vfork

[Rich Felker]

On Thu, Sep 06, 2018 at 05:02:14PM +0200, Patrick Oppenlander wrote:
> On Wed, Jul 18, 2018 at 6:14 AM Patrick Oppenlander
> <patrick.oppenlander@gmail.com> wrote:
> >
> > On Wed, Jul 18, 2018 at 12:35 PM Rich Felker <dalias@libc.org> wrote:
> > > I think there needs to be a ".hidden __syscall_ret" (by de facto musl
> > > convention, on the line before it's used) here. It *might* be ok
> > > having the reference omit .hidden as long as the definition is hidden
> > > at link-time (which it is), but I'm not convinced the tooling won't
> > > complain about a branch to a destination that's not known to be
> > > link-time constant displacement.
> >
> > If that's the case  i386, s390x, x86_64 and x32 may need attention in
> > vfork.s as they're doing it the same way.
> >
> > > If you have no other changes or comments I'm happy to just --amend
> > > that into the patch when I commit it.
> >
> > No problem with that at all.
> >
> 
> I guess this one slipped through the cracks for 1.20.
> 
> Any chance of you taking a look soon?

Indeed! Sorry about that. I'm in the middle of a big shuffle of messy
stuff in the source tree right now, but ping me again soon if you
don't see action on it in the next couple days.

Rich

Re: [PATCH] arm asm for vfork

[Rich Felker]

On Thu, Sep 06, 2018 at 11:19:14AM -0400, Rich Felker wrote:
> On Thu, Sep 06, 2018 at 05:02:14PM +0200, Patrick Oppenlander wrote:
> > On Wed, Jul 18, 2018 at 6:14 AM Patrick Oppenlander
> > <patrick.oppenlander@gmail.com> wrote:
> > >
> > > On Wed, Jul 18, 2018 at 12:35 PM Rich Felker <dalias@libc.org> wrote:
> > > > I think there needs to be a ".hidden __syscall_ret" (by de facto musl
> > > > convention, on the line before it's used) here. It *might* be ok
> > > > having the reference omit .hidden as long as the definition is hidden
> > > > at link-time (which it is), but I'm not convinced the tooling won't
> > > > complain about a branch to a destination that's not known to be
> > > > link-time constant displacement.
> > >
> > > If that's the case  i386, s390x, x86_64 and x32 may need attention in
> > > vfork.s as they're doing it the same way.
> > >
> > > > If you have no other changes or comments I'm happy to just --amend
> > > > that into the patch when I commit it.
> > >
> > > No problem with that at all.
> > >
> > 
> > I guess this one slipped through the cracks for 1.20.
> > 
> > Any chance of you taking a look soon?
> 
> Indeed! Sorry about that. I'm in the middle of a big shuffle of messy
> stuff in the source tree right now, but ping me again soon if you
> don't see action on it in the next couple days.

I have it queued in my tree now, along with fixing .hidden for the
other archs and the cleanup work I'm doing. Depending on how the rest
of this goes there might still be some delay seeing it, but the risk
of it being forgotten is basically zero now. :-)

Rich

Re: [PATCH] arm asm for vfork

[Patrick Oppenlander]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Fri., 7 Sep. 2018, 04:06 Rich Felker, <dalias@libc.org> wrote:

> On Thu, Sep 06, 2018 at 11:19:14AM -0400, Rich Felker wrote:
> > On Thu, Sep 06, 2018 at 05:02:14PM +0200, Patrick Oppenlander wrote:
> > > On Wed, Jul 18, 2018 at 6:14 AM Patrick Oppenlander
> > > <patrick.oppenlander@gmail.com> wrote:
> > > >
> > > > On Wed, Jul 18, 2018 at 12:35 PM Rich Felker <dalias@libc.org>
> wrote:
> > > > > I think there needs to be a ".hidden __syscall_ret" (by de facto
> musl
> > > > > convention, on the line before it's used) here. It *might* be ok
> > > > > having the reference omit .hidden as long as the definition is
> hidden
> > > > > at link-time (which it is), but I'm not convinced the tooling won't
> > > > > complain about a branch to a destination that's not known to be
> > > > > link-time constant displacement.
> > > >
> > > > If that's the case  i386, s390x, x86_64 and x32 may need attention in
> > > > vfork.s as they're doing it the same way.
> > > >
> > > > > If you have no other changes or comments I'm happy to just --amend
> > > > > that into the patch when I commit it.
> > > >
> > > > No problem with that at all.
> > > >
> > >
> > > I guess this one slipped through the cracks for 1.20.
> > >
> > > Any chance of you taking a look soon?
> >
> > Indeed! Sorry about that. I'm in the middle of a big shuffle of messy
> > stuff in the source tree right now, but ping me again soon if you
> > don't see action on it in the next couple days.
>
> I have it queued in my tree now, along with fixing .hidden for the
> other archs and the cleanup work I'm doing. Depending on how the rest
> of this goes there might still be some delay seeing it, but the risk
> of it being forgotten is basically zero now. :-)
>

Perfect, thanks!

I'm not in a hurry for it (away from dayjob for a month traveling) just
wanted to send a gentle reminder so that it wasn't forgotten.

Patrick

[-- Attachment #2: Type: text/html, Size: 2829 bytes --]