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 8C96F25872 for ; Wed, 28 Feb 2024 20:34:53 +0100 (CET) Received: (qmail 21828 invoked by uid 550); 28 Feb 2024 19:31:12 -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 21790 invoked from network); 28 Feb 2024 19:31:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709148879; x=1709753679; 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=BtQdP0RHzqKuRrxDKXJK6QRvTLFEOJbjKOCA2tH7wJA=; b=Ui4gmX+ieSpJhgK5kzjV3qaOyJ4wKKHOPxrt4QC9tE1I/QgelVN1/jtA6OFq6LusKL OY/Ug/ScZDjLKKErIOb1sJRXE/PtCyuIpZex0eRk3eoWXqYHFai84jQhkgmIfUnCSIOj 9OvIjnGtbeqV8k3ppbVb6L4FtM9QWUY+cBo2Pbh91gBmgKDD0iv1YdUTnx+ek8AkkVG8 hJG6bg+a7tNWTL6C9jLA2CJdyFNmGvqB7rzs1zLL8NGcsoA/KV83pDKZKOYzEsKM4kxv 7rtO3D/5OGBU09pyzrDNC9FALYLeVsPAgjbU2tuivHwfKY6Kc6mO2zHsCzAuFRrxJV/g HrPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709148879; x=1709753679; 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=BtQdP0RHzqKuRrxDKXJK6QRvTLFEOJbjKOCA2tH7wJA=; b=wLK3ZgG8ISaHrkZ2HUyCWl0xrcpbTKXes5Y/rzzc+8lBsciEiYNanyxvphptjiJvGk fU1y6yPzX2ANKmsVEdkJa2VAhR4sTpaml2fAAOTbve59nxBZ5e+bMX3pwn3KGLYjB0DW 6019982CUlUyXQ407KN0RafVAjkDwhCHmh7e3Z5o+u+lDheY2PCS1116iOFSTvZanxhN kNMac9Q7JL9GyKy/1LTlJKw+238hrCAbXo3HiJVw4XpUlt+/4/zosVCR1O+5dYJ0lesJ 5oyfwwmMp+LFI+OatHoVqObE1x5l60oyNGL4TK3RyAp17qyCDcW8hfeh64Xi+47UR0LQ gnZA== X-Gm-Message-State: AOJu0YzsZ3CnXJOTiDC1viVJSbtRm/LzrGVgEhylCjRvOpp2i277gqyQ LVPGcknONTbNLc5i8C+s7SKQaUr1WJZcV3JR7upp6gbD8+8kaHBrSgXfk9S8vR5nsjfteH/RREf KoY0Q6iHUZC3R781vslKNU03TbWM= X-Google-Smtp-Source: AGHT+IFVSmNXzp5LL3OsLb8kyV/p5H5COfAzQwz48rcUpd9OeynMAYemV7FhaBwO2CK3APhpgf6srTbIWx5S2vD0yKo= X-Received: by 2002:a17:90b:3011:b0:299:a69:1f8b with SMTP id hg17-20020a17090b301100b002990a691f8bmr147495pjb.23.1709148878704; Wed, 28 Feb 2024 11:34:38 -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: <20240228183700.GP4163@brightrain.aerifal.cx> From: Max Filippov Date: Wed, 28 Feb 2024 11:34:27 -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 10:36=E2=80=AFAM Rich Felker wrot= e: > 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(si= ze_t); > > > > > size_t *fn =3D (size_t *)laddr(p, dyn[DT_FI= NI_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 function > > > > addresses (descriptor addresses on fdpic), not instruction addresse= s. > > > > > > I read libgcc code at > > > https://github.com/jcmvbkbc/gcc-xtensa/blob/xtensa-14-8789-fdpic/li= bgcc/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. > Also, FWIW, I believe there's something of an application-facing > contract that you can declare function pointer arrays with > __attribute__((__section__(".init_array"))) and have them work, which > would not work if instruction addresses rather than function addresses > are expected to be there. --=20 Thanks. -- Max