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 22496 invoked from network); 23 Apr 2020 05:04:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 23 Apr 2020 05:04:41 -0000 Received: (qmail 28647 invoked by uid 550); 23 Apr 2020 05:04:39 -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 28618 invoked from network); 23 Apr 2020 05:04:38 -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=X/ezOATJBn8/0aWxMF6VoCqwuEaksPMOwB3e4n1sUjo=; b=wxISG/F0QNBoYgTFe5l4LvyQOKUDYPbSqaZkh2KXNsyPBW4xNeAWRacHTs+ys9qS0m KXTdpA8UmHAubgH67/8ivtgEcz7fUgcy9ACr+Ow2QI7VdiAifNTEb3HWlWnGICvSs4py 42tCzkn2zCrLue4+Kd34tEu5kMxePSj8O7QEY3K8D/BXV6JxkjMmdozT3wW5B7y3BFLk yZEvfYs1nxb0wwiT2c1Ki6QgUUIzLRzpuxFUpNoP06twN/5mAtebo4AZacBVxC0gQoQR jmIl8JHXUx/Eg/Fq47NVs8WtCz8u2hN5yMKl0ysBST7D2lf8esS9YROB4HjcIfrORLmo eODg== 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=X/ezOATJBn8/0aWxMF6VoCqwuEaksPMOwB3e4n1sUjo=; b=qbeQtOHg0VTHDHGLzIcm62nUCRQVb4HsHgXFQTsiaapbwNaKE+rsfMnwvFMOxNha69 o9hWvH5ka2t1nr+AFp8lWc2PFV5YgINKHPCxvRRTfo/ONay+97eSSfxifUhOFUTQ14N6 qmOF7L4bWCiARg+HfqAAx1KXj+UDjz1wcuSHXvQH9J282sHihrzFQipoltYyyZ0jwgML NNScnfw5VwC+UHW5P6OyHWx+DgBRerUDmCO5e31gvuh2wWLFJSw25Xqkru+DEltEoZAN CAZC+SVckKFvPnJRaklDXDj+8/NobBK94grMVAHWoaYL0MK99b6Mb3OrjAk6e2jlooqT bGTA== X-Gm-Message-State: AGi0PuaKTiA6BjsjmGl0/rcnGg/iSIEuOiou+Pah94eSJjZj3Xuwn8Go ouaEEJ9uRKBHC2x6qlAk+nMdODxIx6qnoxhvzbo1ug== X-Google-Smtp-Source: APiQypKvBehU9pPrzHR48PDIRVaHR9li2FL2z1TdWpIr09GhX6oE3RHj+bD6LA1AIhLHQBm/7JjhEPq49lNKukNc0Ps= X-Received: by 2002:a1f:34c5:: with SMTP id b188mr2016234vka.20.1587618266535; Wed, 22 Apr 2020 22:04:26 -0700 (PDT) MIME-Version: 1.0 References: <20200423023255.GO11469@brightrain.aerifal.cx> In-Reply-To: <20200423023255.GO11469@brightrain.aerifal.cx> From: Tom Storey Date: Thu, 23 Apr 2020 15:04:15 +1000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000d0eb8505a3ee2e4b" Subject: Re: [musl] Building for m68k --000000000000d0eb8505a3ee2e4b Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000d0eb8505a3ee2e4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rich,

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

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

Or, perhaps Im complicating things for my intended u= se? The older CPUs might not be supported due to lack of MMU, and libc is r= eally only meant for use within an OS environment? Could I perhaps be bette= r 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 m= 68k?
>
> I was able to successfully build it, but then later discovered that it=
> would appear to be targeting 68020+ processors more specifically. I wo= uld
> 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 f= or
> 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 re= build
> results in a failure complaining that the 68020+ is required. I dont k= now
> 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<= br> 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
--000000000000d0eb8505a3ee2e4b--