From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2851 invoked from network); 8 Sep 2020 07:01:06 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 Sep 2020 07:01:06 -0000 Received: (qmail 7569 invoked by uid 550); 8 Sep 2020 07:01:02 -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 7539 invoked from network); 8 Sep 2020 07:01:02 -0000 X-Gm-Message-State: AOAM530OHYro/NpVfdgdRWPdWSaGqc6NOnYgBlJTjv6knMdCBQHfMH+C ol/OGS03LIk/Fz2iexUs5xXMajYJ81y0X9VqvtE= X-Google-Smtp-Source: ABdhPJyX3sKgGUAPD7UkPDGkg5P706a5YTHLtQWT7JHbr7oZQYH4us2tzAMAf21JPcUnW/4RcYJ/oV0ocIMjWyrscFk= X-Received: by 2002:a05:620a:15a7:: with SMTP id f7mr15025313qkk.3.1599548449311; Tue, 08 Sep 2020 00:00:49 -0700 (PDT) MIME-Version: 1.0 References: <68b5e735-45be-413f-8153-cb97dd5967cd@www.fastmail.com> <20200907180636.GM3265@brightrain.aerifal.cx> <20200907214554.GO3265@brightrain.aerifal.cx> <20200907221151.GP3265@brightrain.aerifal.cx> <20200908010254.GQ3265@brightrain.aerifal.cx> In-Reply-To: <20200908010254.GQ3265@brightrain.aerifal.cx> From: Arnd Bergmann Date: Tue, 8 Sep 2020 09:00:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:GOF7Om5lwPTlZ8mkJQj92RCDv5/lvyzm/4Wk7ll1DmCuAMqp1sU Hl15+IcoAg6ZII7RqZuzCtzJAhIddne1ArXMmKLRoDPINPkKIUTkYyTkP3idd3MEd7eL3+R t8kwGumHXW3YEp96H2hSMLJ/Cg/n5m+68Kc1wvNIOeXHeOD6D2FZXQ0CTjG8eWthUIBnSg1 aQ/8TvIpblrzY+NOpinlA== X-UI-Out-Filterresults: notjunk:1;V03:K0:tErzAQH3dK4=:0GnrT8e7OgfvyVCtvTTSSd 9XDG6oIzlYytmR2CFj2aI6RnspkheUHZJwVr8KLsXDNDKeAJme9R/yGCxvVZLtl8JrzpBnhfa jBde50kIM4iR2iJC/kFaOIAlo9I0FW8t22x6/Q0hNs93wIaySSngzhoL7YRlAUDGwNTI5Kv0l 7FKkuvtJCYEcDRx1hJJDu8kvhFqv0HKhBSgzb1HaxTxAN+gyi1T/QJNMw5XyXDH9YCZ3d3NKg edU5qr5Hr5PVg8U17mlXVxLX6R0/r5aX6ERofQ0XIwMptJNf+eAfyAhFvY/KtslQo9JH4QyUn BcqVredoEzl/7olxngGZnHH0QlOBTZ2tJtWIZ528MLa4m1FNrzF8IcaNcTKaT6DfFX0Y1t10S M3SI9JaXcA1MrI07w44UiKua92f41dw7pImhqibpvNWNZQ1VvBcKUq81XutDv4naCxhtDxOch UmODW5gEiCQSO2qd3Gs+VeF8M7pATvc5B9lTA4WyRJgDcCW9V0GWKHCHtzg7+0qs6UTo8wdJ0 JIdNWKonx6/LeQvCuS7BS+vDgGeKDslE7jLkWJebSpeYugGuB112JooGCPf60BicGELoofySP CuDfudohhyeQkGKI5aOr6WcwdvY3uvGkoOeutX8N9pk2AtfZx3NChnnF5SXw5+K39VON+zxs0 2W4mv/MqxOiT21JHl4ElI07t+phTWyzNjL8pynYgCVurq4/vG1h7IuigY1NNgQw33/GrpSr8U lJfLZMfOajQ2Am8SQvhY9j9X3dge0cE1D5FWBzSR1ZM10YrnRqmgwdEb0IVGeeMy7ud5k+XSn ZAPjiaHnPwUNSMW3F0Imvcczj6SJ4vMz1WdDRIdRYQSvL2oLKT3kVXBCyGptBN718QdoEFK Subject: Re: [musl] riscv32 v2 On Tue, Sep 8, 2020 at 3:03 AM Rich Felker wrote: > > On Tue, Sep 08, 2020 at 12:30:27AM +0200, Arnd Bergmann wrote: > > On Tue, Sep 8, 2020 at 12:12 AM Rich Felker wrote: > > > As an aside, I should probably cleanup the current definition > > > framework where IPC_64==0x100 is the default and archs that want 0 > > > have to define it explicitly. It looks like, for the most part, IPC_64 > > > is needed iff SYS_ipc is defined. > > > > Right, there are no architectures that provide sys_ipc and want the > > flag to be zero. > > > > > Of the archs we support, arm > > > (32-bit) and mips{n32,64} seem to be the only ones that lack SYS_ipc > > > but need the IPC_64 bit set. Does this agree with your assessment? > > > > I think microblaze is in the same group. Note that for odd reasons it > > has always defined the __NR_ipc macro to 117 but hooked it up > > to -ENOSYS instead of sys_ipc in the kernel. I'm never quite sure > > whether we should treat that as a bug in the header file that we want > > to fix, or whether we should keep such constants around in new > > headers that were present in older ones. > > Oh, really? In that case musl's almost surely broken on microblaze, > and yes it would be another exception. There was (very briefly) a sys_ipc implementation on microblaze in 2009 as the architecture got merged, but this was never part of a released kernel as far as I can tell. I'm not surprised that this was never caught though, as sysvipc is not that common on the super-small softcore implementations that microblaze tends to be used for. On sparc32, sysvipc had been broken in a slightly different way in the kernel for over 11 years without anyone complaining (it was working in compat mode on 64-bit kernels though). For future 64-bit microblaze, we will have to decide which ABI to use, I'd probably go with the new variant (only split calls, no IPC_64 flag). Arnd