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.1 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,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 5B8A02A401 for ; Wed, 28 Feb 2024 20:41:56 +0100 (CET) Received: (qmail 5714 invoked by uid 550); 28 Feb 2024 19:38:14 -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 5673 invoked from network); 28 Feb 2024 19:38:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709149301; x=1709754101; 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=CaYvVtuGx7niP4EAzPEMH7FcrBsF7NkUhay1W1nKuqc=; b=GGm0vz500UFYmhlFp8/nCa2YEBeuPGlxqK7w2I2Trf0m8T7KCNtPMbyyXfNMHPueM3 sgI7BOPcIHcLrFTbuRIA3YADUkEXkIHja0IYVZ5SjVMFi32Dr5mnQu+AOXzmOeFS7l47 aOAFnICmKZWyHiyQkVGj3+4E0sPGlpQDvA8q3Pvr/ra/6nqHoqJTEHBDFRieU8dgHqRa PCDjxbyDc6RZU6hvutl5WaC84X0tzKocEZhB6diCSZ4MzHkwIhzP0REHu3Zog+lC9DJT +lDaA6tko7U/Eo7oRDCKmIzmoGNqnYN5RxbABzZ/hakiSRJbvtO9F5Tt1EDmX/CNeDzF /7QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709149301; x=1709754101; 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=CaYvVtuGx7niP4EAzPEMH7FcrBsF7NkUhay1W1nKuqc=; b=RnkyHTWTko/c1t1xlu+XYLBaleDT8DkZZ9LdZeLJCy3xT+U60aCy8VfAKvT2LS880S tWpwH8ejmpWXaPXNKhNkx/i7wBgQ/Zc9HOhqY+zYJUu4RXDqvt8gRm2m4kFBw8usdo3Z tHCVPwZPf0ys0WubhlZPO13s9t4lG6zf0QrkBFGTP6YXAO/v36RfP3rhBUtZtpr9xLWr r02c3DjJVAwG6iWljG5GY+jILqOrWf3BLZ6MH8Pqjj2t/6YsixxMHU2BvkIGjTr+iBjr g5yCKAEF7QPdw1hVCI8tAob3UVmSbHcRvqcAmpkSZ08L2GgLCqqXbWr9j9dh5DJQrMSk RPvg== X-Gm-Message-State: AOJu0Yzo6ysOdtw6YAGNelvd+BEozsUBEPBR3N9qDZAGfjkybM+qrSn9 9k8wtuyylVnj1nS6JRXf5HbkxsGvoaj64Rpa3OrQPG6w+bXbSedcYoX97LSI9/XN9lHTjpjUpkq 0uYz3hnVKXHKTcoehE935Alnr84BP5N/fb4M= X-Google-Smtp-Source: AGHT+IEOfHaN+1KZIHEggwlLg7Unt9Ia2nRrCODQMWC0FuvIOdXucKjj4chr5XDlwc2VRytZJOdwqiHSGlMTOg50mbY= X-Received: by 2002:a17:90a:a893:b0:29a:f991:dcc1 with SMTP id h19-20020a17090aa89300b0029af991dcc1mr158410pjq.1.1709149301279; Wed, 28 Feb 2024 11:41:41 -0800 (PST) MIME-Version: 1.0 References: <20240227232430.GM4163@brightrain.aerifal.cx> <20240228001303.GN4163@brightrain.aerifal.cx> <20240228183032.GO4163@brightrain.aerifal.cx> <20240228183700.GP4163@brightrain.aerifal.cx> In-Reply-To: From: Max Filippov Date: Wed, 28 Feb 2024 11:41:30 -0800 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] Initial xtensa/fdpic port review On Wed, Feb 28, 2024 at 11:34=E2=80=AFAM Max Filippov = wrote: > > On Wed, Feb 28, 2024 at 10:36=E2=80=AFAM Rich Felker wr= ote: > > On Wed, Feb 28, 2024 at 01:30:32PM -0500, Rich Felker wrote: > > > On Wed, Feb 28, 2024 at 09:20:33AM -0800, Max Filippov wrote: > > > > > > > > > > p->relocated =3D 1; > > > > > > } > > > > > > @@ -1485,7 +1487,7 @@ void __libc_exit_fini() > > > > > > if (dyn[0] & (1< > > > > > size_t n =3D dyn[DT_FINI_ARRAYSZ]/sizeof(= size_t); > > > > > > size_t *fn =3D (size_t *)laddr(p, dyn[DT_= FINI_ARRAY])+n; > > > > > > - while (n--) ((void (*)(void))*--fn)(); > > > > > > + while (n--) fpaddr(p, *--fn)(); > > > > > > > > > > If this is fixable on the tooling side it really should be fixed > > > > > there. init/fini arrays should have actual language-level functio= n > > > > > addresses (descriptor addresses on fdpic), not instruction addres= ses. > > > > > > > > I read libgcc code at > > > > https://github.com/jcmvbkbc/gcc-xtensa/blob/xtensa-14-8789-fdpic/= libgcc/crtstuff.c#L498-L503 > > > > and the way it's written suggests that this was done on purpose. > > > > I put it into the WIP pile to figure out later what the purpose was= . > > > > I thought that SH might not have this issue because it just didn't > > > > use the .array_init/.array_fini. > > > > > > I'm pretty sure we're using it -- musl-cross-make always forces it on > > > via the gcc configure command line -- but it's possible there's some > > > override disabling it for sh. I'll try some test cases and confirm > > > whether sh is doing it right. Maybe the arm folks will have input on > > > this too..? > > > > Confirmed both that it works, and that it's working via init_array. > > GCC emits: > > > > .section .init_array,"aw" > > .align 2 > > .long foo@FUNCDESC > > > > for > > > > __attribute__((__constructor__)) > > void foo() { ... } > > > > Oh, no doubt that that C code generates a function descriptor, it > works for xtensa too. But the piece of libgcc quoted above specifically > puts a pointer to an object, not to a function into the .init_array. It was introduced to gcc by the ARM FDPIC series: https://github.com/jcmvbkbc/gcc-xtensa/commit/11189793b6ef60645d5d1126d0bd9= d0dd83e6583 This is the second change that I find made by the ARM FDPIC series that appears to be not right for other FDPIC ports, first being this change to the C++ unwinding code: https://github.com/jcmvbkbc/gcc-xtensa/commit/67b0605494f32811364e25328d352= 2467aaf0638 --=20 Thanks. -- Max