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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE 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 C072625CA4 for ; Wed, 7 Feb 2024 18:55:05 +0100 (CET) Received: (qmail 28542 invoked by uid 550); 7 Feb 2024 17:52:19 -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 28504 invoked from network); 7 Feb 2024 17:52:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707328491; x=1707933291; darn=lists.openwall.com; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sLkaNB8yhAHsIU4nrkWgCwa5C5DC0I8qQ6OsJjbFFVQ=; b=hMSHhNRrZF+ICaMsW4nlnYkbcBiXXYTTIAuPtR1YtTYOzCiqlqioLNUiREQf5uMvP/ ZX5aN1YJYRKnjdiNhiqq1vBZGql7Hp+rrYZBfKCLVd/pMQH0NURAsfIE/LgICUvSaWJw mdWKYGsWgAT89jUWN3LuwlE35xAD2gWhM0HKHKNQEn1bhmFYnL9C+nxiFRO3Tc0YbexE JHcrQGxa2K2BE6fAEfRMIeDsCUxUv+fvvn3orlBpfaTv+qisY05+wff+cejI7hVusZ4+ OmQyORIMiJD/5lDTkvZNlLwGY+iSptjJ6fOt0+t/NDttfcURvc/u2hqjERTtpUxjkLLs Kzog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707328491; x=1707933291; h=content-transfer-encoding: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=sLkaNB8yhAHsIU4nrkWgCwa5C5DC0I8qQ6OsJjbFFVQ=; b=pvU8pbT9WdwZU6WrAc9Gsv5gg3jvQU6Hc3YPIny2F/B5rJ8KxMg43LT1NTBjxPwd/9 l0vEhhyHDiON7LPd/KQHhe9yPQIjIKx0bwbRcBRcpwe35Phjnb+dEfb/rYhMBQXHTIGA 01RWfY7OdiIeT/nKOfaNkQx29HG+il/Xak66mpslpLNkpqg9kbusrDiLb0PpnAQhMCwj 7K/EHpLXlI0oph3LiU/U65sdocPzfFgAarS0LTx07a1je0nywthf1Gm7XRJu8JzJDeNB 1IkfjCGP1/wwf62A4apO8zZxSvIxobtv4IDVuJN/cZSuAXkEGWvVWvY5x6/DTZf2Obzo IOjg== X-Gm-Message-State: AOJu0YyILWabn48SHlOa5ydDFXLby/rQNOohjN5+gqg7rL4xDOilHdRv m/XgV/jbaGFrfrnI+SJW69/r/NQYWJ29+90QxMGIELxV8+NRD2OgHVdovzb6mi33jsH0MoKMAXt kvsWVHqlB4zW/8d+QF3wL7yXjDBD+mL0CzqtVSfHNBFJ1tANSQ4q0 X-Google-Smtp-Source: AGHT+IEIzeXpnNM1grPMvBJ5fG91UaraOZQFfNWWMELnFf5qi+t9GdEEVMYAJ0xYfUHI8KZP8xbOUuQ9lFdPXGuIw4k= X-Received: by 2002:ad4:5c89:0:b0:68c:6f8c:6741 with SMTP id o9-20020ad45c89000000b0068c6f8c6741mr8665940qvh.11.1707328491362; Wed, 07 Feb 2024 09:54:51 -0800 (PST) MIME-Version: 1.0 References: <20240207012247.1121273-1-mmayer@broadcom.com> In-Reply-To: From: enh Date: Wed, 7 Feb 2024 09:54:40 -0800 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH 0/1] ldso: continue searching if wrong architecture is found On Wed, Feb 7, 2024 at 9:17=E2=80=AFAM Thorsten Glaser wrote= : > > enh dixit: > > >helpful in catching cases where people had libraries for the wrong > >_architecture_, not just the wrong bitness. "with enough users, all > >errors are common" :-) ) > > But are these errors? well, that's the philosophical question that brings us here today :-) > On Debian, with Multi-Arch and qemu-user and whatnot, that would not > even be unusual, if perhaps not common. > > I=E2=80=99m mildly tending towards ignoring objects that are not valid > shared objects of the current architecture and ABI. i think the strongest argument we heard in favor of ignoring this is the "what about a 64-bit process that exec()s a 32-bit process, or vice versa?". on Android that's probably also a bug. having the _libraries_ for two bitnesses isn't unusual (or "wasn't" anyway --- in 2024 we're getting to the point where low-end is 32-only and the rest 64-only, but 32/64 was common for the last decade), but _executables_ (other than the two zygotes) was probably a bug, and encouraging apps not to have 64-bit helpers in addition to 64-bit libraries was only going to cause us trouble for the inevitable _switch_ to 64-only when arm64 hardware dropped 32-bit support. moreover, getting a _correct_ value of LD_LIBRARY_PATH on Android is non-trivial anyway, given the split between system and vendor code. but, yeah, if you're mainly thinking about x86-64, that doesn't seem likely to ever drop 32-bit support, so your "transition" might be something you never come out of. > bye, > //mirabilos > -- > Support mksh as /bin/sh and RoQA dash NOW! > =E2=80=A3 src:bash (429 (458) bugs: 0 RC, 295 (315) I&N, 134 (143) M&W, 0= F&P) + 209 > =E2=80=A3 src:dash (90 (104) bugs: 0 RC, 51 (54) I&N, 39 (50) M&W, 0 F&P)= + 62 ubu > =E2=80=A3 src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P) > dash has two RC bugs they just closed because they don=E2=80=99t care abo= ut quality=E2=80=A6