From patchwork Fri Apr 5 15:38:46 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Edelsohn X-Patchwork-Id: 1078505 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-498895-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="B6yC4C8F"; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="XTdyHr3d"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 44bPBB3ZZ7z9sPp for ; Sat, 6 Apr 2019 02:39:12 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:content-type; q= dns; s=default; b=noTyK4+dXlwaaqstAda2VMjsZpFEES1XzDSoWRslwSbEbX YdJhRMzXbs+09V1NPv567pFl8URuOhsArVAS0fZhRa7yFblFBXTiW4cFDBQKaPXO T7y/iWr77UyTOinopiUYOXQpWi1jOvOmPYn8rK0nTxCIl35e2wRwHEWLhlxOs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:content-type; s= default; bh=7pHq7GvdfysjjIlc8MrLRtH+j74=; b=B6yC4C8Fk7pV6DyBphUJ Tc7jjt8g2yyV/4qbCXEaO7mxAOUe6vVz6mDuWt6DpUf4chrrzvHqAgDzDwaP1AnM wilWju1F3d0W4JkUp3x2JLvc37wQeCvLPUmhV89GUwX1jKK4NHrAmlTw9gf1Ntr/ jYOyl3rimXbgo0/g0jvNLPE= Received: (qmail 90547 invoked by alias); 5 Apr 2019 15:39:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 90538 invoked by uid 89); 5 Apr 2019 15:39:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wm1-f47.google.com Received: from mail-wm1-f47.google.com (HELO mail-wm1-f47.google.com) (209.85.128.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Apr 2019 15:39:03 +0000 Received: by mail-wm1-f47.google.com with SMTP id o25so7157369wmf.5 for ; Fri, 05 Apr 2019 08:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Y3g53eFrFADl5hHX0NXOwfSMMxbXuVGjDP9EZYvA4Ys=; b=XTdyHr3d3SqejPYfnOx+zPCTL00cOmnZNQU5FOrJZNFfsx/YEpWvJJ7qW8diR1zCst vezok4UalHAxAwPcnbOEJ9TBfqTpgzHFTPdO3etXIUyxuZB68k4HMQcEAtWVl5BStTl/ n8UVEKt5sNVrzQWZq/FyE/qhxGWPHFKB0LCRpawBwo6/aI2anGWokKfSWldBGV12g/b2 hx9WKaORgP0NmKGcEHVubZA6B5ZlPkjjHLrxZtM7qLxiMV+WyJkG9WPZtDRsiKJGAbjV rV0M+/M7QsE1FpeetPg97yfy9Om8AbdBAXTvCRMtH3sL/6cA56nY/J5N32/luCjMk1GZ spuw== MIME-Version: 1.0 From: David Edelsohn Date: Fri, 5 Apr 2019 11:38:46 -0400 Message-ID: Subject: [PATCH, AIX] Fix private_read_only_data_section definition To: GCC Patches When not using -fdata-sections or when there is no containing name, GCC falls back to a default section name. Because AIX uses XCOFF, it always has generated it's own section (CSECT) names (based on the filename) and not using the GCC defaults. unicode.org icu code has elicited behavior from the GCC AIX backend that generates invalid code https://github.com/unicode-org/icu/blob/master/icu4c/source/i18n/tzfmt.cpp Essentially extern "C++" { namespace icu_64 { static const UChar TZID_GMT[] = {0x0045, 0x0074, 0x0063, 0x002F, 0x0047, 0x004D, 0x0054, 0}; // Etc/GMT selects a read only section whose name matches a read write section name (a CSECT with [RO] mapping matches a CSECT with [RW] mapping). The AIX linker generates an error for this combination. The current algorithm creates a single private data section name, e.g., "_tzfmt.rw_" and uses the one string for the names of both the read write and read only private data sections _tzfmt.rw_[RW] _tzfmt.rw_[RO] Apparently this combination never has been elicited previously over the 20+ years of the port. The most expedient solution is to generate a separate name for private read only data. The GCC XCOFF stabs debugging information will not be correct for this, but, if one examines the current GCC xcoffout.c logic, it never has been correct and always assumed that the section was read write. The focus for AIX is DWARF debugging and this section rarely, if ever, has been emitted. Another solution would be to place private read only data in the private read write data section when the -fdata-section logic is not active or not triggered. Thanks, David Bootstrapped on powerpc-ibm-aix7.2.0.0. * xcoffout.h (xcoff_private_rodata_section_name): Declare. * xcoffout.c (xcoff_private_rodata_section_name): Define. * config/rs6000/rs6000.c (rs6000_xcoff_asm_init_sections): Create read_only_private_data_section using xcoff_private_rodata_section_name. (rs6000_xcoff_file_start): Generate xcoff_private_rodata_section_name. Index: xcoffout.c =================================================================== --- xcoffout.c (revision 270165) +++ xcoffout.c (working copy) @@ -64,6 +64,7 @@ static const char *xcoff_current_function_file; char *xcoff_bss_section_name; char *xcoff_private_data_section_name; +char *xcoff_private_rodata_section_name; char *xcoff_tls_data_section_name; char *xcoff_tbss_section_name; char *xcoff_read_only_section_name; Index: xcoffout.h =================================================================== --- xcoffout.h (revision 270165) +++ xcoffout.h (working copy) @@ -127,6 +127,7 @@ extern const char *xcoff_current_include_file; extern char *xcoff_bss_section_name; extern char *xcoff_private_data_section_name; +extern char *xcoff_private_rodata_section_name; extern char *xcoff_tls_data_section_name; extern char *xcoff_tbss_section_name; extern char *xcoff_read_only_section_name; Index: config/rs6000/rs6000.c =================================================================== --- config/rs6000/rs6000.c (revision 270165) +++ config/rs6000/rs6000.c (working copy) @@ -33866,6 +33866,10 @@ rs6000_xcoff_asm_init_sections (void) rs6000_xcoff_output_readwrite_section_asm_op, &xcoff_private_data_section_name); + read_only_private_data_section + = get_unnamed_section (0, rs6000_xcoff_output_readonly_section_asm_op, + &xcoff_private_rodata_section_name); + tls_data_section = get_unnamed_section (SECTION_TLS, rs6000_xcoff_output_tls_section_asm_op, @@ -33876,10 +33880,6 @@ rs6000_xcoff_asm_init_sections (void) rs6000_xcoff_output_tls_section_asm_op, &xcoff_private_data_section_name); - read_only_private_data_section - = get_unnamed_section (0, rs6000_xcoff_output_readonly_section_asm_op, - &xcoff_private_data_section_name); - toc_section = get_unnamed_section (0, rs6000_xcoff_output_toc_section_asm_op, NULL); @@ -34060,6 +34060,8 @@ rs6000_xcoff_file_start (void) main_input_filename, ".bss_"); rs6000_gen_section_name (&xcoff_private_data_section_name, main_input_filename, ".rw_"); + rs6000_gen_section_name (&xcoff_private_rodata_section_name, + main_input_filename, ".rop_"); rs6000_gen_section_name (&xcoff_read_only_section_name, main_input_filename, ".ro_"); rs6000_gen_section_name (&xcoff_tls_data_section_name,