arm asm for vfork

Submitted by Patrick Oppenlander on July 18, 2018, 2:20 a.m.

Details

Message ID CAEg67GnPaf++HTRqbp8=H9-3BwNMXtX1zeiyzWTO8JoYOHhQWw@mail.gmail.com
State New
Series "arm asm for vfork"
Headers show

Commit Message

Patrick Oppenlander July 18, 2018, 2:20 a.m.
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

Patch hide | download patch | download mbox

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


Comments

Rich Felker July 18, 2018, 2:35 a.m.
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
Patrick Oppenlander July 18, 2018, 4:14 a.m.
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
Christopher Friedt July 18, 2018, 1:44 p.m.
I'm actually excited for this, having done something similar with another
embedded libc for cortex-m3 a while back.
Patrick Oppenlander Sept. 6, 2018, 3:02 p.m.
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
Rich Felker Sept. 6, 2018, 3:19 p.m.
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
Rich Felker Sept. 7, 2018, 2:05 a.m.
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
Patrick Oppenlander Sept. 7, 2018, 6:29 a.m.
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