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 17040 invoked from network); 24 Apr 2020 01:15:06 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 24 Apr 2020 01:15:06 -0000 Received: (qmail 9792 invoked by uid 550); 24 Apr 2020 01:15:04 -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 9771 invoked from network); 24 Apr 2020 01:15:03 -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=YzOuKVsWAcgQI/VHzQEyTge9tSRsOlHfU3Rjwxe8ywY=; b=pe3KfkAosA5jx8eQtkSMvCLuMcaJTzh+LxTRbZr4bZ1daZ3+UGRgCl5wXuyJBicdm+ WOuAR8xUlYx198jopk6ZfNql2RKk3CKLdofYqj2Dx2BAtXoC0WQK/cj2/B4PcJVlyvTn hIo+/qKZZSOSVx9gs1mZPVlEub6IEoWpZdBBHaMgd35K9xIKNWM0Z7YsSDWBQ3HX+6r/ R3SESMyFDsE3vsBjkf1sextpLpKUG4EXz2WA8EtP2pIwg7dZ/c2Wn/p/njORfRcfmnG0 2K55ktAcwYhN4kzoGq8fO1GCAHz/jVzaokEKoj50uSo2tkEkY24qjl6TZb0bHaD+z+Ka g1Bw== 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=YzOuKVsWAcgQI/VHzQEyTge9tSRsOlHfU3Rjwxe8ywY=; b=i6fPwCDX7yTSShRtX5oOHrFgT5Q8UqtjzfzDRf3qIHdhtYqYrVX2o+nhVmSkFX70Zl Ct2seruIorSa6hc/5HQ2IAqUi4cWV5ll8lsCsjq9K/JreaGCjKtO1g6jy7DZwvxk24ar P5xOcewylWVbQ8kpA00X6hYJSgZnfqbQkLODljLxDYywSaxL+lqkrV4mGtKKadFUpGyi Ax2DQnTdY/0ttHMiwk9DVpCtnYy15JX1VPyE5FIZfIi3An5+VGG6FZ69T8Z0tbeZUVIa ZcEUn0/P5VjydbPH5Z4GCnqbufQ4Sr16MOxcga7zek1xqLYHDk2G2MVlSM+FmziTmgKF 82nQ== X-Gm-Message-State: AGi0PuZ96KtD0Y6EvU+jMcjsBKFuqZNyjJnMe2hFZYR75O3Phu7ksHfC Xb9GNDwZ9jC/9erPFNrnvZS+pAWNCHVbEFeiWLdsPPubGEQ= X-Google-Smtp-Source: APiQypJQKRrXKkerT69YfBDZ/pfQpjhhjgJvd9nfnR2e66yZ+Nu6RLKGcEhvjZ/IRA0ubpEOGaPIug5vv1IdmDCn954= X-Received: by 2002:a1f:2f91:: with SMTP id v139mr6048010vkv.22.1587690891213; Thu, 23 Apr 2020 18:14:51 -0700 (PDT) MIME-Version: 1.0 References: <20200423023255.GO11469@brightrain.aerifal.cx> <20200423163016.GW11469@brightrain.aerifal.cx> <20200424005101.GA11469@brightrain.aerifal.cx> In-Reply-To: <20200424005101.GA11469@brightrain.aerifal.cx> From: Tom Storey Date: Fri, 24 Apr 2020 11:14:38 +1000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000095a91e05a3ff17fd" Subject: Re: [musl] Building for m68k --00000000000095a91e05a3ff17fd Content-Type: text/plain; charset="UTF-8" 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 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 > --00000000000095a91e05a3ff17fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry to ask what sounds like a dumb question, but is
cli;nonatomic_cas;sti

basically "disable interru= pts, 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 instru= ction 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 roadbl= ock
> in src/setjmp/m68k/longjmp.s where it tries to execute a floating poin= t
> instruction, and then subsequently fails with a "needs M68K fpu&q= uot; error
> message. So maybe there was a way to work around that, but FPU adds an= other
> 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 lo= ok 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
--00000000000095a91e05a3ff17fd--