1791321 – gcc: weakref attribute introduces the need for copy or text relocations on ppc64

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1791321 - gcc: weakref attribute introduces the need for copy or text relocations on ppc64

Summary: gcc: weakref attribute introduces the need for copy or text relocations on ppc64

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	gcc
Sub Component:
Version:	7.9
Hardware:	ppc64
OS:	Linux
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Marek Polacek
QA Contact:	Alexandra Petlanová Hájková
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2020-01-15 14:13 UTC by Florian Weimer
Modified:	2020-10-05 08:31 UTC (History)
CC List:	7 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2020-04-28 19:42:58 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Bugzilla	1790475	0	unspecified	CLOSED	glibc: BIND_NOW is incompatible with copy relocations on ppc64	2021-02-22 00:41:40 UTC
Sourceware	25384	0	P2	RESOLVED	Copy relocations and BIND_NOW on POWER ELFv1 results in crashes	2020-04-28 15:58:34 UTC

Internal Links: 1790475

Description Florian Weimer 2020-01-15 14:13:04 UTC

This is essentially a clone of bug 1790475, filed for tracking purposes.

This program:

static void alias (void) __attribute__ ((weakref ("implementation")));
const void *const ptr = alias;

Produces this construct:

        .section        ".toc","aw"
        .align 3
        .section        ".text"
        .machine power7
        .globl ptr
        .weakref        alias, implementation
        .section        .rodata
        .align 3
        .type   ptr, @object
        .size   ptr, 8
ptr:
        .quad   alias
        .ident  "GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-39)"
        .section        .note.GNU-stack,"",@progbits

The problem is that with the POWER ELFv1 ABI, the address of implementation cannot be resolved by the link editor. It can live in a DSO.  Until recently, binutils ld would produce a copy relocation for the OPD entry to cope with that, but those only work with lazy binding (see the binutils ld bug or bug 1790475). With the binutils fix, we get a text relocation instead. But that this is not an improvement.

With GCC 7, I get this instead, which avoids the problem entirely:

        .section        ".text"
        .globl ptr
        .weakref        alias, implementation
        .section        .data.rel.ro,"aw",@progbits
        .align 3
        .type   ptr, @object
        .size   ptr, 8
ptr:
        .quad   alias
        .ident  "GCC: (GNU) 7.3.1 20180303 (Red Hat 7.3.1-5)"
        .section        .note.GNU-stack,"",@progbits

I think we should verify that this is really fixed in later GCC versions which are included in DTS, so that we can safely pick up the upstream binutils fix there eventually, without generating text relocations.

I don't know if we should backport that fix into system GCC, but we should at least consider it.

Comment 2 Jakub Jelinek 2020-01-15 18:42:58 UTC

This got fixed with https://gcc.gnu.org/r206784 aka https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01169.html
Although it seems that the patch was written mainly with the other direction in mind, i.e. that even when
TREE_PUBLIC (tem) && targetm.binds_local_p (tem) (such as when the decl is hidden visibility) we could use reloc & 1
rather than reloc & 2, the weakref case is when !TREE_PUBLIC (tem) && !targetm.binds_local_p (tem) and in that case
it is just local convention that TREE_PUBLIC is clear, because the weakref target might not bind locally and so we need it in
writable or relro section rather than rodata.
So, I think we want to stay on the safe side, we could always patch it to
  if (TREE_PUBLIC (tem) || !targetm.binds_local_p (tem))
    reloc |= 2;
  else
    reloc |= 1;

Note You need to log in before you can comment on or make changes to this bug.