This is the mail archive of the
mailing list for the binutils project.
Re: [gold, strip] Question about the changed offset when stripping
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Alexander Ivchenko <aivchenk at gmail dot com>, Cary Coutant <ccoutant at google dot com>, binutils <binutils at sourceware dot org>
- Date: Wed, 11 Dec 2013 13:29:30 -0800
- Subject: Re: [gold, strip] Question about the changed offset when stripping
- Authentication-results: sourceware.org; auth=none
- References: <CACysShjNGcO=Y5ZU=QDLWetw31FRZUu7ZYbvo2DyJWZ+eOZZ2Q at mail dot gmail dot com> <20131129134722 dot GN9211 at bubble dot grove dot modra dot org> <CAHACq4qbwykqOcTjuQovsqoE0d2dC4FAAtfZOxr=0XrYsViJqw at mail dot gmail dot com> <20131203100957 dot GA3306 at bubble dot grove dot modra dot org> <CACysShi4sKtg_R6RAhGmgKs0qRuvbsU3fLpC-Hz27YMy-sGtrA at mail dot gmail dot com> <20131203112323 dot GC3306 at bubble dot grove dot modra dot org> <CACysShiAr=iLP2Ju2dWsubV5USXxDhQitmydvRfC2=b07Fp7hA at mail dot gmail dot com> <CACysShiCkBdFOx233aBu02esXboe0dBTgf92grxUoEWRbNgUDQ at mail dot gmail dot com> <CAKOQZ8z9yGYXmdL3ieAFp_OpQcca7vNC4Db3VuA-PV+Sku_o=Q at mail dot gmail dot com>
On Mon, Dec 9, 2013 at 7:58 AM, Ian Lance Taylor <firstname.lastname@example.org> wrote:
> On Mon, Dec 9, 2013 at 4:33 AM, Alexander Ivchenko <email@example.com> wrote:
>> 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:
>> LOAD 0x003d60 0x00004d60 0x00004d60 *0x002a0* 0x002b0 RW 0x1000
>> LOAD 0x003d60 0x00004d60 0x00004d60 *0x0029c* 0x002b0 RW 0x1000
> I assume this is readelf -l output on your binary. It looks like the
> file size of the data segment has been changed by strip. That does
> seem odd, though since the memory size is unchanged it's not
> necessarily a problem. It depends on whether any initialized symbol
> is defined in those missing 4 bytes.
>> Still, one thing I still worry about. I see that gold is intentionally
>> making this padding.
>> I see in the code:
>> // 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?
> The relro data area must end at a page boundary, or the dynamic linker
> will not be able to mark it as read-only. Are you sure that is the
> problem, though? What does the GNU_RELRO program segment look like?
> That padding code in gold was added here:
> https://sourceware.org/ml/binutils/2010-10/msg00234.html . Part of
> the code is clearly required. I'm not sure it is essential to pad the
> relro size to a maximum of the section alignment, though in general it
> can't hurt.
> If the only change that strip introduces is a change in the file size
> of the data segment, and if no symbol refers to those bytes, and if
> the symbol values are unchanged, and if the RELRO segment is
> unchanged, then I would expect the resulting executable to work
> But I agree it is odd for strip to be changing something here.
I did some investigation. I think gold is wrong. I