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=-3.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 544EA22994 for ; Fri, 5 Apr 2024 08:42:31 +0200 (CEST) Received: (qmail 32745 invoked by uid 550); 5 Apr 2024 06:42:27 -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 32700 invoked from network); 5 Apr 2024 06:42:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1712299338; x=1712904138; i=nullplan@gmx.net; bh=rwlXI+iGBnNsATFs/T9lnSohPVexB/FNWJ8tfKPST5E=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=DHwqRcPVUt0Dyho2OV9o4BQzLxwC+xmDE0NXiZW6VnY9yR2teHLn+/OorX59m+vm Mv6oAEUvjs5SCbtOxXhi7SpPwQxehjjW8wMldm14k7KFN0lj3oofkwRTwskmurCyA +BeC5ANuQQdvimUBxJesNIo9DzEU8XbLUMiEnftxxxorbM+LzulW4Tg0QPLf3PmEr WyU4F3gT6+D6LDhMu3L11KmkIHDsFWjcR+vK0K49HhqKwkzvjt0DJa0SCm8dH2mHD kvz4BqKKTL2vlwVobGK1Ux185LrzOrJZBtivbYSAC8R1QDcjbPcDbBjx7mSIs1QFy bi/bpx9Ic0a43s07PQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Fri, 5 Apr 2024 08:42:17 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: 1068350@bugs.debian.org, debian-glibc@lists.debian.org, doko@debian.org Message-ID: References: <20240404105408.GB3766212@port70.net> <20240404202641.GS4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Provags-ID: V03:K1:ob5UDp5bHwRdV/SEEcGsjzbaHIvOZNmM4JLO7ivd0/KvOCIMZ1A Rfn91qAgwjYpQC19bWfXd2g+M9DQTmuMzckQ3vK9uBUQTLNAV6WFEQfe+J3M8cAiCse2ndc NGn4+cW5AiYmFYWW8gA3F7cEE3FJElpX67vLbdnItVjRhbyhzCGYxE3ejpTR+e8dlR8tdpK u0vvpwejKlPOipbuRIp2w== UI-OutboundReport: notjunk:1;M01:P0:qiCEYDkkajk=;eQyVDIbbiXz4HI4sI0WtffaDKlT Hp6utLuM/rqQcmmd73SMaIOJFkHJivovCEggPoG01BF7JHt3JMmmYfMiw2Lt+VXZ5P511isHc vbDrkfYXEq2zXjrmZor1FvjNJxwpJjz9wwpzOU5Bsj3G0cekLst1gtKFn2YGJyjMs+poEj8RU kRqtbKaGvKGknrgkAPA2IfTFDlJslAAV/BbBgv76S8qfnadw1LLHTzDS9BJUFIkH0KPLfQMit Y//rujxDv5TtoPSVNkUj/CVpjpwCHxo7b7A42PD2Uu+MLfhlr3CT8Wg8nzDGv1s+x+X91GWq3 3ZPuUJbCUN4HbGWmW0S0c7zMp8bCE7DYa8W4YD8gn87jC4cZTuzW5sTTFxPbMolqOv8IwlCRY qn3tPvVTQ6H075A8GRJPak6czJrREoyD36idwIepjhHjtp55hodBQ87UPmCkvNDlwwb7c21r/ tHobLbrs3lFfPViOP8rGMisFaBciFhX7iPfMR9687GiFjidNtNZh3hElkTS4vwe8vx0IQpjOu K/HSFy5WjM1QQ/XTX3N3Ojc5m/KvpBsqjoDV7hOdi0SCuAxtlzlQQLRQIDJGpBbsrWv917Dzo B4JreNm2nsu7D/CUjrBYmD+ndVSQGRLPrhqHthgT8m+MTiWeflV3swwPLXI4KExNXQfaZ/REz Ybqf8fMnQc2IlGZO8LaWC0gOF7qb4vR1RzKELJAWBQgXLpudIlcYkVHwfLQ53nmhDShinC5v8 QgYpdZIZP8HVSUM5Lc/zoeNpddT38UqvHNfFwUkV5q4W65Fi83dADWHReUbL8iTZ4l44xblAk 0RcY0rvP1lJbOFWaK8yXrNi+vF58COifsdvMToL7d58x4= Subject: Re: [musl] Re: Bug#1068350: =?utf-8?Q?musl?= =?utf-8?Q?=3A_miscompiles_=28runtime_problems=29_on_riscv64_and_s390x_wit?= =?utf-8?Q?h_static-pie_=E2=86=92_seem?= =?utf-8?Q?s?= to be a toolchain bug after all, it does too hit glibc Am Fri, Apr 05, 2024 at 05:58:15AM +0000 schrieb Thorsten Glaser: > Markus Wichmann dixit: > >In any case, the emission of non-relative relocations is the issue here= , > >and it is coming from the linker. > > They are present in the glibc static-pie binary as well, though. > And tbh they look to me like =E2=80=9Cjust plug the absolute address of > the symbol here, please=E2=80=9D, which is perfectly fine for things lik= e > an array of strings when the actual string has already its own symbol. > > (Disclaimer: I know=E2=80=A6 barely anything about Unix relocation types= , > a bit more about those on DOS and even TOS.) > Then glibc's static-pie startup code also processes symbolic relocations. musl's doesn't. It only processes relative relocations. And changing this would require some massive reworking. We'd somehow have to put stage 2 of the dynamic linker into rcrt1.o. A symbolic lookup doesn't really make sense for a static executable outside of FDPIC. The only difference in address space possible is a relative offset. In order to do a symbolic relocation, you also need the symbol lookup stuff, which - granted - for a static PIE is probably very simple because there can be only one symbol table, but still. I thought the whole point of static-PIE support was to only leave relative relocations around. Ciao, Markus