From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100765 invoked by alias); 22 Oct 2015 15:08:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 100698 invoked by uid 89); 22 Oct 2015 15:08:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f52.google.com Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com) (209.85.192.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 22 Oct 2015 15:08:29 +0000 Received: by qgeo38 with SMTP id o38so59087504qge.0 for ; Thu, 22 Oct 2015 08:08:27 -0700 (PDT) X-Received: by 10.140.238.3 with SMTP id j3mr20118462qhc.88.1445526507695; Thu, 22 Oct 2015 08:08:27 -0700 (PDT) Received: from msticlxl57.ims.intel.com (jfdmzpr02-ext.jf.intel.com. [134.134.137.71]) by smtp.gmail.com with ESMTPSA id g77sm5531371qgd.5.2015.10.22.08.08.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2015 08:08:27 -0700 (PDT) Date: Thu, 22 Oct 2015 15:09:00 -0000 From: Ilya Verbin To: "H.J. Lu" Cc: GCC Patches , Kirill Yukhin Subject: Re: Constify host-side offload data` Message-ID: <20151022150802.GB63867@msticlxl57.ims.intel.com> References: <55A70152.8010702@acm.org> <20151021173350.GA7682@msticlxl57.ims.intel.com> <20151021174252.GB7682@msticlxl57.ims.intel.com> <20151022141138.GA63867@msticlxl57.ims.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg02286.txt.bz2 On Thu, Oct 22, 2015 at 07:35:55 -0700, H.J. Lu wrote: > On Thu, Oct 22, 2015 at 7:11 AM, Ilya Verbin wrote: > > On Wed, Oct 21, 2015 at 10:44:56 -0700, H.J. Lu wrote: > >> On Wed, Oct 21, 2015 at 10:42 AM, Ilya Verbin wrote: > >> > On Wed, Oct 21, 2015 at 10:38:10 -0700, H.J. Lu wrote: > >> >> On Wed, Oct 21, 2015 at 10:33 AM, Ilya Verbin wrote: > >> >> > H.J., > >> >> > Maybe linker should print some warning about joining writable + nonwritable > >> >> > sections? Here is a simple testcase: > >> >> > > >> >> > $ cat t1.s > >> >> > .section ".AAA", "a" > >> >> > .long 0x12345678 > >> >> > $ cat t2.s > >> >> > .section ".AAA", "wa" > >> >> > .long 0x12345678 > >> >> > $ as t1.s -o t1.o > >> >> > $ as t2.s -o t2.o > >> >> > $ ld -shared t1.o t2.o > >> >> > $ ls -lh a.out > >> >> > 2.1M a.out > >> >> > > >> >> > >> >> Does linker make AAA writable? If yes, linker does what it > >> >> is told. > >> > > >> > Yes, it makes it writable, but why it also makes this? > >> > > >> > [Nr] Name Type Address Offset > >> > Size EntSize Flags Link Info Align > >> > [ 0] NULL 0000000000000000 00000000 > >> > 0000000000000000 0000000000000000 0 0 0 > >> > [ 1] .hash HASH 00000000000000b0 000000b0 > >> > 0000000000000028 0000000000000004 A 2 0 8 > >> > [ 2] .dynsym DYNSYM 00000000000000d8 000000d8 > >> > 0000000000000078 0000000000000018 A 3 2 8 > >> > [ 3] .dynstr STRTAB 0000000000000150 00000150 > >> > 0000000000000019 0000000000000000 A 0 0 1 > >> > [ 4] .AAA PROGBITS 0000000000000169 00000169 > >> > 0000000000000008 0000000000000000 WA 0 0 1 > >> > [ 5] .eh_frame PROGBITS 0000000000000178 00000178 > >> > 0000000000000000 0000000000000000 A 0 0 8 > >> > [ 6] .dynamic DYNAMIC 0000000000200178 00200178 <-- ??? > >> > 00000000000000b0 0000000000000010 WA 3 0 8 > >> > [ 7] .shstrtab STRTAB 0000000000000000 00200380 > >> > 0000000000000049 0000000000000000 0 0 1 > >> > [ 8] .symtab SYMTAB 0000000000000000 00200228 > >> > 0000000000000120 0000000000000018 9 9 8 > >> > [ 9] .strtab STRTAB 0000000000000000 00200348 > >> > 0000000000000038 0000000000000000 0 0 1 > >> > > >> > >> Linker groups input sections by section name and ors section > >> flags. > > > > Could you please help figure out how this number 0x200178 is calculated? > > ld -verbose doesn't show anything helpful. It seems that something goes wrong > > during section-to-segment mapping, because when both .AAA have "wa" flags, we > > got small binary with 2 LOAD segments: > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > > 0x00000000000001a8 0x00000000000001a8 R 200000 > > LOAD 0x00000000000001a8 0x00000000002001a8 0x00000000002001a8 > > 0x00000000000000b8 0x00000000000000b8 RW 200000 > > > > But when one .AAA has "a" flag, and another .AAA has "wa" flag, we got huge > > binary with only one big LOAD segment: > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > > 0x0000000000200228 0x0000000000200228 RW 200000 > > > > BTW, gold produces small binary in both cases. > > > > Please open a binutils bug with a testcase. Done: https://sourceware.org/bugzilla/show_bug.cgi?id=19162 -- Ilya