From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 12780 invoked from network); 24 Apr 2020 00:36:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 24 Apr 2020 00:36:51 -0000 Received: (qmail 29846 invoked by uid 550); 24 Apr 2020 00:36:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29828 invoked from network); 24 Apr 2020 00:36:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snnap-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I6illDKKG4auRQ8qoQ3csKhRLqOJByq1C00ACxIVh0M=; b=GOBoLZZQFT/8+phGdDJoLM/pZP7/BXcYzSvhlqTRNaGUPs62Wr0Djg/Yl2gIzKQEAX WlDsOmVg8g7FJHoLm5mOt4kwASv6k+yhL1c5sYy5zix6SnFtHRzwKVcL+cHTMN+KvRRU ojzOtfOKLGq4T371J7rWr7otCpJ7Stvkxyde6OJH+MWFbghpuPU7gAsLsZRB0lv68bCb i2cGpmyEqubl74MSQZT10cg2qR34HlI1DJYXbVTJ1q9tdrtvFG/YFEGB1httGWFhn0h5 qtuTG09fp5pfIfUohA/MKCgnPyRiFOmdWTKumPQV2AR5k/fbDj8Pn11HERN9D6iYReJG IPzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I6illDKKG4auRQ8qoQ3csKhRLqOJByq1C00ACxIVh0M=; b=SF682Sbo4kgDCBNWZg8AmvBhMcIoy57ohWJ/l1hPE/5CJVJduABLmO5JU2dGJVZIDD BmaSh2H0JW3QQmWTu0EkNoGjizrbvs7gBflEQG0AjtEHagtLgdTmmC43sBNT1dK7vXUq nr62cF3FDcRVzD0hk+GpgyHA//l2yvIOMpZy83Ck6BBO2zmwSqirbYGsosaAb7UnBETw g4w4D51i0Uk48A0TXaxDTEeK+yKagPGJ6odhZwOfTal6Wz9ig3hU5jIdpgjEmNHzX4Al HPDlVKWDS37EC40ynk421n9mfWvyk2AC8U6ngK4GgwBuXBe/Olioc4x6i4+DdY9Sh42L v6ow== X-Gm-Message-State: AGi0PuZffEQRUyW7kITiPrF4EsLCXUKoegc3ZCrGChizDq8PTnmAeXGp IDyJ9pLTikMK60nZ1/s63l2mUiItkGVk5m/0QCS23g== X-Google-Smtp-Source: APiQypJRgJj6WL6UBwe6e8pxngMBJcjVHxwwFX7Zpnr2LBKtfTj/TIqm7DnDmQ1RJHkhlMnoy5I2ZMgpHMhQ1XwljqE= X-Received: by 2002:a67:7fd1:: with SMTP id a200mr5695909vsd.114.1587688594010; Thu, 23 Apr 2020 17:36:34 -0700 (PDT) MIME-Version: 1.0 References: <20200423023255.GO11469@brightrain.aerifal.cx> <20200423163016.GW11469@brightrain.aerifal.cx> In-Reply-To: <20200423163016.GW11469@brightrain.aerifal.cx> From: Tom Storey Date: Fri, 24 Apr 2020 10:36:23 +1000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000a90e4c05a3fe8e16" Subject: Re: [musl] Building for m68k --000000000000a90e4c05a3fe8e16 Content-Type: text/plain; charset="UTF-8" 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 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 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 > > > > --000000000000a90e4c05a3fe8e16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rich.

Just for gits and shiggles= =C2=A0I tried #ifdef'ing=C2=A0out the cas.l instruction in the atomic_a= rch.h file for 68020+ processors, and compilation then proceeded along very= smoothly for a while, but then hit another roadblock in=C2=A0src/setjmp/m6= 8k/longjmp.s where it tries to execute a floating point instruction, and th= en subsequently fails with a "needs M68K fpu" error message. So m= aybe there was a way to work around that, but FPU adds another dimension to= this problem.

Trying to make this work is probabl= y more than I'm really willing to take on for this project, so I may pu= t it on the back burner and perhaps look at it another time. In the meantim= e 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 percentag= e of what's there anyway,=C2=A0so maybe just cherry picking the bits I = want is a better way forward for now.

If I get rea= lly 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 c= ould 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 b= are
> metal", if that matters? Im not a particular expert in all of thi= s. :-)
>
> 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 mea= nt
> for use within an OS environment? Could I perhaps be better off writin= g 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<= br> 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 discover= ed that it
> > > would appear to be targeting 68020+ processors more specific= ally. I would
> > > like to build for the earlier 680[01]0's.
> > >
> > > Specific examples are to do with (at least) aio where some a= tomic
> > > instructions are used (e.g. cas - compare and swap) which on= ly 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 thes= e
> > 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 suppo= rted
> > in the target ISA level. But it could mean there are missing
> > prerequisites that have to be fixed on the kernel side before any= thing
> > can actually work.
> >
> > Rich
> >
--000000000000a90e4c05a3fe8e16--