From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 765D53858D1E; Wed, 8 Nov 2023 04:12:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 765D53858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1699416763; bh=MUvzrY/2YsfriTQhDtqVUuX6FJDwKPZHvcfxEk54GMk=; h=From:To:Subject:Date:From; b=K+FLYAmSBjV9W16/ePzzHWTpSgvcCZ8oIYxCqmNmIDbXUJfN5P7dCFoaCbOi7NKdF MxXpMt1CBI6v6iVhRaAWt6wJE/A9buNpWU+GzDHfkyt2e3HrcDaK9JZrcYopGlbIi0 9pimTw9X67bxhO9zkmk2lf31cFCbLQPOUGtUcJEQ= From: "rui314 at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/31042] New: [s390x] .init and .fini padding Date: Wed, 08 Nov 2023 04:12:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rui314 at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31042 Bug ID: 31042 Summary: [s390x] .init and .fini padding Product: glibc Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libc Assignee: unassigned at sourceware dot org Reporter: rui314 at gmail dot com CC: drepper.fsp at gmail dot com Target Milestone: --- I noticed this issue while developing the mold linker for the s390x architecture. The CRT files for glibc/s390x include .init and .fini sections, which conta= in functions for initializing and finalizing a process, respectively. The link= er simply concatenates .init or .fini input sections into a single output sect= ion for each. Upon process startup, the runtime branches to the start of .init = as though it were a single function. The final input .init section contains a = ret instruction to return to the caller. In this setup, there should be no gaps between the input .init/.fini sectio= ns. However, the .init/.fini sections in glibc/s390x may include trailing paddi= ng; each input section is aligned to a 4-byte boundary, but they do not always = end on these boundaries. As a result, padding may occur between sections after = the linker concatenates them. The linker can fill this padding with any value. GNU ld appears to use NOPs= to fill the gaps, which happens to work. However, I believe relying on it is an incorrect approach, or at least a very fragile one. To fix this issue, you could simply add an `.align 4` directive at the end = of each .init/.fini input section. This would prompt GAS to insert NOPs, ensur= ing that each function ends at a 4-byte boundary. https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dsysdeps/s390/s390-64= /crti.S;h=3D11ab75e8d95f86ff225f84673715ff457e8b63cd;hb=3DHEAD https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dsysdeps/s390/s390-64= /crtn.S;h=3D0eabcb346caa843a4657c3fb23739bd7bf166091;hb=3DHEAD --=20 You are receiving this mail because: You are on the CC list for the bug.=