[musl] Building for m68k

[musl] Building for m68k

[Tom Storey]

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

Hi all.

Is anyone out there particularly familiar with building musl for the m68k?

I was able to successfully build it, but then later discovered that it
would appear to be targeting 68020+ processors more specifically. I would
like to build for the earlier 680[01]0's.

Specific examples are to do with (at least) aio where some atomic
instructions are used (e.g. cas - compare and swap) which only exist for
the 68020 and later, but not for earlier processors.

https://git.musl-libc.org/cgit/musl/tree/src/aio/aio.c#n375
https://git.musl-libc.org/cgit/musl/tree/arch/m68k/atomic_arch.h

Thus, adding -m68000 to the CFLAGS env variable when trying to do a rebuild
results in a failure complaining that the 68020+ is required. I dont know
what else is hiding away in the rest of it that will also be
incompatible... :-)

Any suggestions, pointers, tips would be greatly appreciated.

Thanks
Tom

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

Re: [musl] Building for m68k

[Rich Felker]

On Thu, Apr 23, 2020 at 12:05:27PM +1000, Tom Storey wrote:
> Hi all.
> 
> Is anyone out there particularly familiar with building musl for the m68k?
> 
> I was able to successfully build it, but then later discovered that it
> would appear to be targeting 68020+ processors more specifically. I would
> like to build for the earlier 680[01]0's.
> 
> Specific examples are to do with (at least) aio where some atomic
> instructions are used (e.g. cas - compare and swap) which only exist for
> the 68020 and later, but not for earlier processors.
> 
> https://git.musl-libc.org/cgit/musl/tree/src/aio/aio.c#n375
> https://git.musl-libc.org/cgit/musl/tree/arch/m68k/atomic_arch.h
> 
> Thus, adding -m68000 to the CFLAGS env variable when trying to do a rebuild
> results in a failure complaining that the 68020+ is required. I dont know
> what else is hiding away in the rest of it that will also be
> incompatible... :-)
> 
> Any suggestions, pointers, tips would be greatly appreciated.

To answer this I think we need to know how Linux support for these
models is meant to work (if it even is meant to). If Linux does
trap-and-emulate (I'm not aware of any other mechanism it has by which
it could make this work) then it might just amount to passing the
right -Wa,... to make the assembler accept instructions not supported
in the target ISA level. But it could mean there are missing
prerequisites that have to be fixed on the kernel side before anything
can actually work.

Rich

Re: [musl] Building for m68k

[Tom Storey]

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

Hi Rich,

Sorry, I should perhaps mention that I am looking to "build for bare
metal", if that matters? Im not a particular expert in all of this. :-)

Basically, my situation is that Im a hobbyist, and have plans to build a
computer around the m68k. Not looking to run Linux or anything on it, but
dont want to be stuck with writing assembly. I was hoping to have libc
available just to have access to some standard functions if needed.

Or, perhaps Im complicating things for my intended use? The older CPUs
might not be supported due to lack of MMU, and libc is really only meant
for use within an OS environment? Could I perhaps be better off writing my
own implementations of libc things if/when I need them?


On Thu, 23 Apr 2020 at 12:32, Rich Felker <dalias@libc.org> wrote:

> On Thu, Apr 23, 2020 at 12:05:27PM +1000, Tom Storey wrote:
> > Hi all.
> >
> > Is anyone out there particularly familiar with building musl for the
> m68k?
> >
> > I was able to successfully build it, but then later discovered that it
> > would appear to be targeting 68020+ processors more specifically. I would
> > like to build for the earlier 680[01]0's.
> >
> > Specific examples are to do with (at least) aio where some atomic
> > instructions are used (e.g. cas - compare and swap) which only exist for
> > the 68020 and later, but not for earlier processors.
> >
> > https://git.musl-libc.org/cgit/musl/tree/src/aio/aio.c#n375
> > https://git.musl-libc.org/cgit/musl/tree/arch/m68k/atomic_arch.h
> >
> > Thus, adding -m68000 to the CFLAGS env variable when trying to do a
> rebuild
> > results in a failure complaining that the 68020+ is required. I dont know
> > what else is hiding away in the rest of it that will also be
> > incompatible... :-)
> >
> > Any suggestions, pointers, tips would be greatly appreciated.
>
> To answer this I think we need to know how Linux support for these
> models is meant to work (if it even is meant to). If Linux does
> trap-and-emulate (I'm not aware of any other mechanism it has by which
> it could make this work) then it might just amount to passing the
> right -Wa,... to make the assembler accept instructions not supported
> in the target ISA level. But it could mean there are missing
> prerequisites that have to be fixed on the kernel side before anything
> can actually work.
>
> Rich
>

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

Re: [musl] Building for m68k

[Rich Felker]

On Thu, Apr 23, 2020 at 03:04:15PM +1000, Tom Storey wrote:
> Hi Rich,
> 
> Sorry, I should perhaps mention that I am looking to "build for bare
> metal", if that matters? Im not a particular expert in all of this. :-)
> 
> Basically, my situation is that Im a hobbyist, and have plans to build a
> computer around the m68k. Not looking to run Linux or anything on it, but
> dont want to be stuck with writing assembly. I was hoping to have libc
> available just to have access to some standard functions if needed.
> 
> Or, perhaps Im complicating things for my intended use? The older CPUs
> might not be supported due to lack of MMU, and libc is really only meant
> for use within an OS environment? Could I perhaps be better off writing my
> own implementations of libc things if/when I need them?

It's possible to do a bare-metal port of musl, or to use unmodified or
minimally-modified musl with bare-metal by implementing the syscall
ABI for at least a minimal set of syscalls for things you need. In the
m68k case the latter would also involve the trap handler emulating the
cas instruction. If doing your own more extensive port, you could do
something more elaborate but less costly, or on nommu something simple
like cli;nonatomic_op;sti.

Any of these options is going to be a lot less work than writing a
significantly functional libc from scratch.

Rich


> On Thu, 23 Apr 2020 at 12:32, Rich Felker <dalias@libc.org> wrote:
> 
> > On Thu, Apr 23, 2020 at 12:05:27PM +1000, Tom Storey wrote:
> > > Hi all.
> > >
> > > Is anyone out there particularly familiar with building musl for the
> > m68k?
> > >
> > > I was able to successfully build it, but then later discovered that it
> > > would appear to be targeting 68020+ processors more specifically. I would
> > > like to build for the earlier 680[01]0's.
> > >
> > > Specific examples are to do with (at least) aio where some atomic
> > > instructions are used (e.g. cas - compare and swap) which only exist for
> > > the 68020 and later, but not for earlier processors.
> > >
> > > https://git.musl-libc.org/cgit/musl/tree/src/aio/aio.c#n375
> > > https://git.musl-libc.org/cgit/musl/tree/arch/m68k/atomic_arch.h
> > >
> > > Thus, adding -m68000 to the CFLAGS env variable when trying to do a
> > rebuild
> > > results in a failure complaining that the 68020+ is required. I dont know
> > > what else is hiding away in the rest of it that will also be
> > > incompatible... :-)
> > >
> > > Any suggestions, pointers, tips would be greatly appreciated.
> >
> > To answer this I think we need to know how Linux support for these
> > models is meant to work (if it even is meant to). If Linux does
> > trap-and-emulate (I'm not aware of any other mechanism it has by which
> > it could make this work) then it might just amount to passing the
> > right -Wa,... to make the assembler accept instructions not supported
> > in the target ISA level. But it could mean there are missing
> > prerequisites that have to be fixed on the kernel side before anything
> > can actually work.
> >
> > Rich
> >

Re: [musl] Building for m68k

[Tom Storey]

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

Thanks Rich.

Just for gits and shiggles I tried #ifdef'ing out the cas.l instruction in
the atomic_arch.h file for 68020+ processors, and compilation then
proceeded along very smoothly for a while, but then hit another roadblock
in src/setjmp/m68k/longjmp.s where it tries to execute a floating point
instruction, and then subsequently fails with a "needs M68K fpu" error
message. So maybe there was a way to work around that, but FPU adds another
dimension to this problem.

Trying to make this work is probably more than I'm really willing to take
on for this project, so I may put it on the back burner and perhaps look at
it another time. In the meantime I will look at copying in the source I
require into my own "kind of mini-libc". I can't imagine I'm going to use a
large percentage of what's there anyway, so maybe just cherry picking the
bits I want is a better way forward for now.

If I get really adventurous maybe I'll look into using a 68020 or above
processor, but for now I would like to stick with the simpler 68000. At
that point I could probably look at running more of a full blown Linux. :-)

Cheers.

On Fri, 24 Apr 2020 at 02:30, Rich Felker <dalias@libc.org> wrote:

> On Thu, Apr 23, 2020 at 03:04:15PM +1000, Tom Storey wrote:
> > Hi Rich,
> >
> > Sorry, I should perhaps mention that I am looking to "build for bare
> > metal", if that matters? Im not a particular expert in all of this. :-)
> >
> > Basically, my situation is that Im a hobbyist, and have plans to build a
> > computer around the m68k. Not looking to run Linux or anything on it, but
> > dont want to be stuck with writing assembly. I was hoping to have libc
> > available just to have access to some standard functions if needed.
> >
> > Or, perhaps Im complicating things for my intended use? The older CPUs
> > might not be supported due to lack of MMU, and libc is really only meant
> > for use within an OS environment? Could I perhaps be better off writing
> my
> > own implementations of libc things if/when I need them?
>
> It's possible to do a bare-metal port of musl, or to use unmodified or
> minimally-modified musl with bare-metal by implementing the syscall
> ABI for at least a minimal set of syscalls for things you need. In the
> m68k case the latter would also involve the trap handler emulating the
> cas instruction. If doing your own more extensive port, you could do
> something more elaborate but less costly, or on nommu something simple
> like cli;nonatomic_op;sti.
>
> Any of these options is going to be a lot less work than writing a
> significantly functional libc from scratch.
>
> Rich
>
>
> > On Thu, 23 Apr 2020 at 12:32, Rich Felker <dalias@libc.org> wrote:
> >
> > > On Thu, Apr 23, 2020 at 12:05:27PM +1000, Tom Storey wrote:
> > > > Hi all.
> > > >
> > > > Is anyone out there particularly familiar with building musl for the
> > > m68k?
> > > >
> > > > I was able to successfully build it, but then later discovered that
> it
> > > > would appear to be targeting 68020+ processors more specifically. I
> would
> > > > like to build for the earlier 680[01]0's.
> > > >
> > > > Specific examples are to do with (at least) aio where some atomic
> > > > instructions are used (e.g. cas - compare and swap) which only exist
> for
> > > > the 68020 and later, but not for earlier processors.
> > > >
> > > > https://git.musl-libc.org/cgit/musl/tree/src/aio/aio.c#n375
> > > > https://git.musl-libc.org/cgit/musl/tree/arch/m68k/atomic_arch.h
> > > >
> > > > Thus, adding -m68000 to the CFLAGS env variable when trying to do a
> > > rebuild
> > > > results in a failure complaining that the 68020+ is required. I dont
> know
> > > > what else is hiding away in the rest of it that will also be
> > > > incompatible... :-)
> > > >
> > > > Any suggestions, pointers, tips would be greatly appreciated.
> > >
> > > To answer this I think we need to know how Linux support for these
> > > models is meant to work (if it even is meant to). If Linux does
> > > trap-and-emulate (I'm not aware of any other mechanism it has by which
> > > it could make this work) then it might just amount to passing the
> > > right -Wa,... to make the assembler accept instructions not supported
> > > in the target ISA level. But it could mean there are missing
> > > prerequisites that have to be fixed on the kernel side before anything
> > > can actually work.
> > >
> > > Rich
> > >
>

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

Re: [musl] Building for m68k

[Rich Felker]

On Fri, Apr 24, 2020 at 10:36:23AM +1000, Tom Storey wrote:
> Thanks Rich.
> 
> Just for gits and shiggles I tried #ifdef'ing out the cas.l instruction in
> the atomic_arch.h file for 68020+ processors, and compilation then

That won't work. But for NOMMU without a separate kernel domain it
would work to do cli;nonatomic_cas;sti (not sure what the actual m68k
insns for that are). There are plenty of places where a cas that does
nothing will break code, probably even during common paths in simple
programs.

> proceeded along very smoothly for a while, but then hit another roadblock
> in src/setjmp/m68k/longjmp.s where it tries to execute a floating point
> instruction, and then subsequently fails with a "needs M68K fpu" error
> message. So maybe there was a way to work around that, but FPU adds another
> dimension to this problem.

You can add a softfloat ABI; nominally there even is one, but it's
clearly not working. The setjmp/longjmp files should be made .S
instead of .s with #if around the floating point save/restore
conditioned on being hardfloat ABI.

> Trying to make this work is probably more than I'm really willing to take
> on for this project, so I may put it on the back burner and perhaps look at

You're really probably 90% there to at least having something that'll
build and that should run if you wire up syscalls.

Rich

Re: [musl] Building for m68k

[Tom Storey]

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

Sorry to ask what sounds like a dumb question, but is

cli;nonatomic_cas;sti

basically "disable interrupts, do something equivalent to cas, re-enable
interrupts"?

That is what I had intended to do by ifdefing out the cas instruction
itself. I wasn't going to leave it out because it's obviously there for a
reason. :-)

But simply for testing, it let me get beyond that point to see what else
was hiding away that would cause some problems.

On Fri, Apr 24, 2020, 10:51 Rich Felker <dalias@libc.org> wrote:

> On Fri, Apr 24, 2020 at 10:36:23AM +1000, Tom Storey wrote:
> > Thanks Rich.
> >
> > Just for gits and shiggles I tried #ifdef'ing out the cas.l instruction
> in
> > the atomic_arch.h file for 68020+ processors, and compilation then
>
> That won't work. But for NOMMU without a separate kernel domain it
> would work to do cli;nonatomic_cas;sti (not sure what the actual m68k
> insns for that are). There are plenty of places where a cas that does
> nothing will break code, probably even during common paths in simple
> programs.
>
> > proceeded along very smoothly for a while, but then hit another roadblock
> > in src/setjmp/m68k/longjmp.s where it tries to execute a floating point
> > instruction, and then subsequently fails with a "needs M68K fpu" error
> > message. So maybe there was a way to work around that, but FPU adds
> another
> > dimension to this problem.
>
> You can add a softfloat ABI; nominally there even is one, but it's
> clearly not working. The setjmp/longjmp files should be made .S
> instead of .s with #if around the floating point save/restore
> conditioned on being hardfloat ABI.
>
> > Trying to make this work is probably more than I'm really willing to take
> > on for this project, so I may put it on the back burner and perhaps look
> at
>
> You're really probably 90% there to at least having something that'll
> build and that should run if you wire up syscalls.
>
> Rich
>

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

Re: [musl] Building for m68k

[Rich Felker]

On Fri, Apr 24, 2020 at 11:14:38AM +1000, Tom Storey wrote:
> Sorry to ask what sounds like a dumb question, but is
> 
> cli;nonatomic_cas;sti
> 
> basically "disable interrupts, do something equivalent to cas, re-enable
> interrupts"?

Yeah. Basically:

static inline int a_cas(volatile int *p, int t, int s)
{
	__asm__ __volatile__("cli" : : : "memory");
	if (*p==t) *p=s; else t=*p;
	__asm__ __volatile__("sti" : : : "memory");
	return t;
}

where cli and sti are replaced with the m68k instructions for those
operations. Of course if you might have code that already has
interrupts disabled somewhere calling libc stuff, you may need to make
it save the old interrupt state and restore it rather than just sti.
See the sh2 version (runtime selected so it's in __sh_cas_imask in
src/thread/sh/atomics.s and atomic_arch.h just calls the
runtime-selected function) for an example of code doing this

Rich

Re: [musl] Building for m68k

[Tom Storey]

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

Ah yeah. Cool.

I did something similar in a recent Z80 based project, shouldn't be too
difficult to do that on m68k.

Only trouble I can see arising from this is enabling and disabling
interrupts is privileged, and from the 68010 onwards you can't even see the
status register to know if interrupts are on/off outside of supervisor
mode, so you wouldn't be able to execute this code from any application
running in user mode.

I suppose that is why it's better trapped as an invalid instruction and
emulated lower down?


On Fri, Apr 24, 2020, 11:20 Rich Felker <dalias@libc.org> wrote:

> On Fri, Apr 24, 2020 at 11:14:38AM +1000, Tom Storey wrote:
> > Sorry to ask what sounds like a dumb question, but is
> >
> > cli;nonatomic_cas;sti
> >
> > basically "disable interrupts, do something equivalent to cas, re-enable
> > interrupts"?
>
> Yeah. Basically:
>
> static inline int a_cas(volatile int *p, int t, int s)
> {
>         __asm__ __volatile__("cli" : : : "memory");
>         if (*p==t) *p=s; else t=*p;
>         __asm__ __volatile__("sti" : : : "memory");
>         return t;
> }
>
> where cli and sti are replaced with the m68k instructions for those
> operations. Of course if you might have code that already has
> interrupts disabled somewhere calling libc stuff, you may need to make
> it save the old interrupt state and restore it rather than just sti.
> See the sh2 version (runtime selected so it's in __sh_cas_imask in
> src/thread/sh/atomics.s and atomic_arch.h just calls the
> runtime-selected function) for an example of code doing this
>
> Rich
>

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

Re: [musl] Building for m68k

[Rich Felker]

On Fri, Apr 24, 2020 at 12:29:51PM +1000, Tom Storey wrote:
> Ah yeah. Cool.
> 
> I did something similar in a recent Z80 based project, shouldn't be too
> difficult to do that on m68k.
> 
> Only trouble I can see arising from this is enabling and disabling
> interrupts is privileged, and from the 68010 onwards you can't even see the
> status register to know if interrupts are on/off outside of supervisor
> mode, so you wouldn't be able to execute this code from any application
> running in user mode.

Yes, the cli/sti approach only works without separate privilege
domains, which normally corresponds to having an MMU (without MMU
privilege domains are pretty much "cooperative" anyway).

> I suppose that is why it's better trapped as an invalid instruction and
> emulated lower down?

Trap-and-emulate is the easy/clean way to do atomic cas when you do
have a separate kernel privilege domain and can't mask interrupts, but
it's also very inefficient. The efficient way is by having a contract
with the kernel where the kernel can detect interruption of the
critical section and restart it at the beginning if a context switch
interrupted it. Lookup ARM (pre-v6) kuser_helper to see how this
worked. It's a really elegant design (aside from the hard-coded
addresses) and not hard to implement.

SH3/4 also had a similar mechanism but with a different contract where
userspace was responsible for more of it, and that was incompatible
with large address spaces because it assigned special meaning to
"negative" stack pointer values. I wouldn't recommend copying it but
it's possibly worth taking a look and comparing it to the ARM
kuser_helper approach.

Rich