This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gold, strip] Question about the changed offset when stripping

2013/12/9 Ian Lance Taylor <>:
> On Mon, Dec 9, 2013 at 4:33 AM, Alexander Ivchenko <> 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?

Between the stripped\unstripped versions of the binary that was the
only difference in segments from "readelf -l". The GNU_RELRO looks
like this:
  GNU_RELRO      0x003d60 0x00004d60 0x00004d60 0x002a0 0x002a0 RW  0x20

> That padding code in gold was added here:
> .  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.

I also noticed that after strip the SHF_INFO_LINK flag for .rel.plt disappeared:

before strip:
<   [ 6] .rel.plt          REL             000011c4 0011c4 000138 08
AI  2   7  4
after strip:
>   [ 6] .rel.plt          REL             000011c4 0011c4 000138 08   A  2   7  4

Again, I'm not sure how critical that is..

> But I agree it is odd for strip to be changing something here.
> Ian

Since gdb/gdbserver 7.6 is able to load debug info for those stripped
binaries, I don't know whether the issue that is solved in pr11786 has
something to do with that problem. However it is indeed looks pretty

H.J., I will try to come up with a smaller testcase.

Ideally, strip should not touch the padding after got.plt and any flags.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]