This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [gold, strip] Question about the changed offset when stripping
- From: Ian Lance Taylor <iant at google dot com>
- To: Alexander Ivchenko <aivchenk at gmail dot com>
- Cc: Cary Coutant <ccoutant at google dot com>, binutils <binutils at sourceware dot org>
- Date: Mon, 9 Dec 2013 07:58:16 -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>
On Mon, Dec 9, 2013 at 4:33 AM, Alexander Ivchenko <aivchenk@gmail.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:
>
>
> not_stripped:
> LOAD 0x003d60 0x00004d60 0x00004d60 *0x002a0* 0x002b0 RW 0x1000
>
> stripped:
> 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:
>
> 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?
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
correctly.
But I agree it is odd for strip to be changing something here.
Ian