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 33AB025A8A for ; Fri, 29 Mar 2024 01:49:15 +0100 (CET) Received: (qmail 16046 invoked by uid 550); 29 Mar 2024 00:44:21 -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 16008 invoked from network); 29 Mar 2024 00:44:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711673342; x=1712278142; 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=u+QCH9Nxdk96ESUUXOhR8WwUjGg46dl/6/RMJPR1/ss=; b=MrPfANcQD9pFtXDS92kp2QYlRqsSoGKgKNwdVEk5vgidmT3trWUC51a1wzPNCgy3Fg LXWSwRK5ohbwFR/3/Dp5boWosjgTACYG+WoVN1DmOnMDHwsUpzwYxylE2/BDmq9kkQau eC1hlfgHz0KQAzt4rg4M7+t43dEJ/P0tdNu3TNLgbOEUZ1FtS8nLTCO13bVPDzDRz3up g+nBQhTr1QFXGeg+kt4yAYfcsV9a7Oe4mnvLOsyiKccxwhuOmRIEtQ2v0wAXAp2j8e89 ugX5FnsnFB7kMcI6SRqwmDrf6aZa+IqDr+Evb1VD7w4w/WGRGCKBReMzNu6/CwXejVFQ WTHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711673342; x=1712278142; 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=u+QCH9Nxdk96ESUUXOhR8WwUjGg46dl/6/RMJPR1/ss=; b=tC/e///vVjumQP2md5H2bV8zw2Phc4Bl0fUlb7npLtHHSG9BZSe/QeGtucBHG0A4X0 jqNYkL1aX/AOLeoomw9x1UJ5p36FN9Y/617n9DxfoK1mD0E/nm39Nqo8rh8YejllgWHo KCMOo97ic2/HdZw3Y/GOJ+cgXaX7+Exo0XmypajR+OuncAaR9JePHf9IJzmd7/Xg/y4Y pz822jJS4zV+s3S9dBuWeqTFN6Y6viqDYK95U0opGWRR/r72i0Zufz5PxZ9FQIFMRoRH 0MFFmARTokx/5ahzgyAaw3h7H3+z5Hx/nh9Ds31x6TphmG8evXRWs2K/VTtOhgYmgGfh sqKA== X-Gm-Message-State: AOJu0YxkikAf+M9kARC6iXL2gHowWvgxoqkdUa/1tXJvP4mUBeKQvqn0 /4wry4LPPr6E1QzkCf3me/Jml5Y69Dg5J7XsjAV/zmzz7QM74DY6zxcF4RgiTL+ySMz9dsoXFV/ h8VRKvdCJpbPEt6leW3HVWRnlSd4= X-Google-Smtp-Source: AGHT+IGfCIwm+cJ1o95+2cYHinWJLfyw/rIuR0MPitofSV5dUwQfrGiQouWAQk4vZHtoy+XZ//FGLsFYlBLu81EXPiM= X-Received: by 2002:a05:6a20:3fa0:b0:1a5:6a94:b487 with SMTP id ay32-20020a056a203fa000b001a56a94b487mr627000pzb.42.1711673341514; Thu, 28 Mar 2024 17:49:01 -0700 (PDT) MIME-Version: 1.0 References: <20240328200319.4016902-1-jcmvbkbc@gmail.com> <20240328230116.GM4163@brightrain.aerifal.cx> In-Reply-To: <20240328230116.GM4163@brightrain.aerifal.cx> From: Max Filippov Date: Thu, 28 Mar 2024 17:48:50 -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 v2 0/2] xtensa FDPIC port On Thu, Mar 28, 2024 at 4:00=E2=80=AFPM Rich Felker wrote= : > On Thu, Mar 28, 2024 at 01:03:17PM -0700, Max Filippov wrote: > > functional/dlopen fails with the > > src/functional/dlopen.c:39: dlsym main failed: (null) > > There's no failure in the dlsym call, but the pointers don't match. > > Is this something related to canonical function descriptors? Is it > musl's fault or a bug in the tooling? I suspect the latter. Yes, dlsym() returns the pointer into def.dso->funcdescs, but (void *)main returns the pointer to the canonical function descriptor. I understand that the linker must use the R_XTENSA_FUNCDESC relocation for the locally defined global symbol instead of the .rofixup entries. > > functional/ and regression/ pthread-related failures are expected > > because the robust list functions are not available in the linux-user > > mode. These particular tests pass in full system emulation. > > > > math tests fail with ULP differences. > > > > I have also added the following changes to the abi tests to fix the > > build: > > > > diff --git a/src/api/sys_sem.c b/src/api/sys_sem.c > > index a473cad0a2aa..bd4df9a4fe70 100644 > > --- a/src/api/sys_sem.c > > +++ b/src/api/sys_sem.c > > @@ -18,7 +18,11 @@ C(SETALL) > > { > > struct semid_ds x; > > F(struct ipc_perm,sem_perm) > > +#ifdef __xtensa__ > > +F(unsigned long, sem_nsems) > > +#else > > F(unsigned short, sem_nsems) > > +#endif > > This is invalid and indicates an error in the port; the whole point of > the tests is to catch that so it can be fixed. POSIX requires I must have misinterpreted that. Will fix it. > sem_nsems to have type unsigned short. I believe Linux has this wrong > on some (most? all?) archs and we just fix it by replacing the rest > with padding. --=20 Thanks. -- Max