From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C777F24C81 for ; Wed, 8 May 2024 19:39:45 +0200 (CEST) Received: (qmail 18428 invoked by uid 550); 8 May 2024 17:39: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 18387 invoked from network); 8 May 2024 17:39:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715189970; x=1715794770; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2BO9Cgm/iQVELWBs9JjOiffk+6yDXJyD3EiHReoaHFE=; b=Wsqe6YTOTAqx7py1KQOknSI0n4vVL9Si/PmRDuFem0fDjkvjeDS2eTknkNwTsrBqo0 erNcD6DD3U5zLo5eI9PmBWOGYwFoem2RTPL9nL4EdWx3UvClB600cCUwT0KIeY6Ge91G u/UZsj6kj2w8MpXFI3vKsDp1eZRWhw//6jXdXSXXvBumhwafI692CkVzW04gqH3K767k cK07EYf8yMHpUL0I459EoHQL8C8j0Pzc+OFdyA06Lzf7ZT8GtPND6lDywcK8e0hBofKo 8TA2XBEcv07G854u/xYLJQOL3Bg7GGdCpKN2pJSKtY+T1gHEm+Lptql9HbFgPMbrCVB+ HzlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715189970; x=1715794770; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2BO9Cgm/iQVELWBs9JjOiffk+6yDXJyD3EiHReoaHFE=; b=hQm2Q7sajA6FP9gmkuRCqNiyxh+85rlCkzCgdI4vO/V21TjOT73HLEV7bGnU4fdECU IcRZy9cVI1lvMTXnH5Bvtu1NTvDm/7URnXkKQTCP5mP7M4E5egyboPqrApXqU0TdHahi AhJK47g0ukmOdq76jP0+YVijm6dXquo1XdvZvsCGqaCQBRSpxkUlkseo88dZGOxgs7r+ nl7SsK0bFdqJhqWch5hrmh3rJ2gcFneZ2e8JrgrRv5bu5Zm1Lqtsq+i5a7Nx6emnVYmK Xv9onMnHbU8Kdxx6wu3E5SMFHxAglDBA8Zjwvla9qhujDaRheDe96VOJZyQIPb5lQpXF 8oew== X-Gm-Message-State: AOJu0Yxo0z5SXiHCPEl0uF4FoJWftamS3xOrh/rgMc14J9ixI2HynACE wvU7QUWgHbgYcFfgq/mTeCjpiG5RuMyHIzuTufR4G3ty2/PKoVUAhgxMAr/QF5pQIActVCOXu/k x71NbLWjXt75Nd7WT2d2Yr1H3zfxqAQ== X-Google-Smtp-Source: AGHT+IEAcZe4yTNRCz4O2IouPQVfhUhmEPbRhEJeRAfEiZrcf1ck2+2GE62U/qgVj9TeC8RI7/lkIVJ5qIHGO+Zanog= X-Received: by 2002:a17:90a:7e13:b0:29b:c9ac:c563 with SMTP id 98e67ed59e1d1-2b6165a44d0mr3039579a91.19.1715189970472; Wed, 08 May 2024 10:39:30 -0700 (PDT) MIME-Version: 1.0 References: <20240506205819.GI10433@brightrain.aerifal.cx> <20240506221524.GJ10433@brightrain.aerifal.cx> <20240506225524.GK10433@brightrain.aerifal.cx> <20240506235901.GL10433@brightrain.aerifal.cx> <20240507013758.GM10433@brightrain.aerifal.cx> <20240507162707.GP10433@brightrain.aerifal.cx> In-Reply-To: From: Max Filippov Date: Wed, 8 May 2024 10:39:18 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [RFC v3 1/1] xtensa: add port On Tue, May 7, 2024 at 11:41=E2=80=AFAM Max Filippov w= rote: > On Tue, May 7, 2024 at 9:26=E2=80=AFAM Rich Felker wrot= e: > > On Tue, May 07, 2024 at 08:30:57AM -0700, Max Filippov wrote: > > > I believe that in accordance with how Tensilica treats xtensa cores, > > > core configuration should be one of the linkage boundaries, along wit= h > > > the FDPIC/non-FDPIC and call0/windowed. So ldso names would look > > > like xtensa-dc233c-fdpic. > > > > Is there actually anything about the dc233c cpu variant that makes up > > part of the linkage boundary? > > It's a particular feature set, instruction set and instruction encoding r= ules. > Toolchain components will be configured for this core and there's no plan > to support linking objects built for different configurations. I thought about it for a bit and it seems to me that adding configuration name to the ABI tag makes both of the following possible: - a range of "standard" configurations can be defined. The end users may choose a configuration that is compatible with their hardware and use a toolchain with that tag. - but they don't have to. If they prefer having their own ABI tag they're also free to do it. Either way the decision about the compatibility is left to the end user and when there's no compatibility with the standard variants or such compatibility is not desired there's still a way to get a working system without a name conflict. --=20 Thanks. -- Max