From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22705 invoked by alias); 9 Dec 2013 12:33:36 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 22694 invoked by uid 89); 9 Dec 2013 12:33:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f172.google.com Received: from Unknown (HELO mail-pd0-f172.google.com) (209.85.192.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 09 Dec 2013 12:33:34 +0000 Received: by mail-pd0-f172.google.com with SMTP id g10so5151420pdj.17 for ; Mon, 09 Dec 2013 04:33:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.68.197.36 with SMTP id ir4mr20422999pbc.96.1386592406545; Mon, 09 Dec 2013 04:33:26 -0800 (PST) Received: by 10.68.226.102 with HTTP; Mon, 9 Dec 2013 04:33:26 -0800 (PST) In-Reply-To: References: <20131129134722.GN9211@bubble.grove.modra.org> <20131203100957.GA3306@bubble.grove.modra.org> <20131203112323.GC3306@bubble.grove.modra.org> Date: Mon, 09 Dec 2013 12:33:00 -0000 Message-ID: Subject: Re: [gold, strip] Question about the changed offset when stripping From: Alexander Ivchenko To: Alexander Ivchenko , Cary Coutant , binutils , Ian Lance Taylor Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00067.txt.bz2 Indeed my problem with debugging was due to those missing 4 bytes between .got.plt and .bss. that lead to differences between stripped/not_stripped program headers of the same binary: not_stripped: LOAD 0x003d60 0x00004d60 0x00004d60 *0x002a0* 0x002b0 RW 0x1000 stripped: LOAD 0x003d60 0x00004d60 0x00004d60 *0x0029c* 0x002b0 RW 0x1000 I didn't look into the code of gdb, but it says in the doc: "The sections of the debugging information file should have the same names, addresses, and sizes as the original file". So, presumably, that includes .bss. However, after updating to gdbserver 7.6 I was able to load the debug info.. Also if I firstly just objcopy the linked binary (thus, erasing the padding between .got.plt and .bss) and then strip Still, one thing I still worry about. I see that gold is intentionally making this padding. I see in the code: Output_segment::set_section_addresses: // Pad the total relro size to a multiple of the maximum // section alignment seen. uint64_t aligned_size = align_address(relro_size, max_align); // Note the amount of padding added after the last relro section. last_relro_pad = aligned_size - relro_size; *has_relro = true ... and then: *poff += last_relro_pad; addr += last_relro_pad; if (this->output_lists_[i].empty()) { // If there is nothing in the ORDER_RELRO_LAST list, // the padding will occur at the end of the relro // segment, and we need to add it to *INCREASE_RELRO. *increase_relro += last_relro_pad; } } Since all stripped binaries in e.g. Android (at least that is true for x86, may be other arch's are also affected), that were linked by gold, are missing that padding, how critical that is? Ian, Carry, could you please comment? thanks, Alexander 2013/12/3 Alexander Ivchenko : > 2013/12/3 Alan Modra : >> On Tue, Dec 03, 2013 at 02:30:48PM +0400, Alexander Ivchenko wrote: >>> Still, it looks a bit strange that strip did the job that it was not >>> asked for: erasing the padding between got.plt and bss. >> >> No, strip didn't change any padding. The VMA is unchanged after strip. >> Since .bss is not loaded from file, the file offset hardly matters. > > Well, still it did change the padding between the "file offset of > .got.plt + size of (.got.plt)" and "file offset of .bss". > Even if it hardly matters, I did not ask strip to do that. But anyway, > I see your point, thanks. > > > --Alexander