From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E2207389365B; Fri, 29 Jan 2021 19:35:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E2207389365B From: "foom at fuhm dot net" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/27279] New: x86_64 _dl_runtime_resolve should preserve r10/r11 Date: Fri, 29 Jan 2021 19:35:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: foom at fuhm dot net 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 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 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 19:35:25 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27279 Bug ID: 27279 Summary: x86_64 _dl_runtime_resolve should preserve r10/r11 Product: glibc Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: foom at fuhm dot net Target Milestone: --- This is arguably _not_ actually a bug. Yet, I still think it should probabl= y be fixed. The x86-64 abi does not specify which registers should be preserved through= a lazy PLT stub resolution (unlike, say, the AARCH64 psABI which specifies th= at all registers but r16, r17 must be preserved). Thus, it's arguably unaccept= able to use _any_ non-standard calling convention when calling through a PLT that might invoke lazy binding. However, users do this, and expect it to work, and are upset when it doesn't work. Because of that, the current state of x86_64's _dl_runtime_resolve is that = it _does_ preserve nearly every register, even those which are not required by= any specification. This changed most recently in 2017, via bug 21265, after some debate -- seemingly resulting in grudging agreement that supporting other calling conventions was a reasonable thing to do after all (grumble grumble= ). After that change, _almost_ all registers -- vector, float, and GPR -- are = now preserved either explicitly in the assembly code, or implicitly via being callee-save in the C function it calls. But unfortunately, there are two GPRs which still get clobbered: r10 and r1= 1. And, there's a calling convention which expects all GPRs except r11 to be preserved: . This has caused a bug in a piece of software, where the developer didn't realize that the "preserve_most" calling convention was incompatible with c= alls that might go through a PLT stub. So -- since lazy PLT resolution is already _so close_ to saving literally everything, and the cost of additionally saving r10/r11 is so low compared = to everything else it's doing, I'd propose that _dl_runtime_resolve should be modified to save those final 2 still-clobbered GPRs. And thus, finally, be transparent to ANY calling convention anyone might wa= nt to use. --=20 You are receiving this mail because: You are on the CC list for the bug.=