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

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

[Alexander Ivchenko]

Hi,

Have a little question about gold and strip, I have a linked by gold
binary with:

>readelf -S out/test_binary
 ....
  [18] .got              PROGBITS        00003f30 002f30 000024 00  WA  0   0  4
  [19] .got.plt          PROGBITS        00003f54 002f54 0000a8 00  WA  0   0  4
  [20] .bss              NOBITS          00004000 003000 000010 00  WA  0   0  8
  [21] .comment          PROGBITS        00000000 003000 000010 01  MS  0   0  1
  [22] .debug_info       PROGBITS        00000000 003010 00db90 00      0   0  1
  [23] .debug_abbrev     PROGBITS        00000000 010ba0 000b66 00      0   0  1
  [24] .debug_loc        PROGBITS        00000000 011706 000fc7 00      0   0  1
 ....

Then I strip it (with trunk strip):
>strip-new --strip-debug out/test_binary -o out/test_binary_stripped

>readelf -S out/test_binary_stripped

 ....
  [18] .got              PROGBITS        00003f30 002f30 000024 00  WA  0   0  4
  [19] .got.plt          PROGBITS        00003f54 002f54 0000a8 00  WA  0   0  4
  [20] .bss              NOBITS          00004000 002ffc 000010 00  WA  0   0  8
  [21] .comment          PROGBITS        00000000 002ffc 000010 01  MS  0   0  1
  [22] .note.gnu.gold-ve NOTE            00000000 00300c 00001c 00      0   0  4
 ....

 As you can see the offset of .bss is changed now (it is equal now to
the offset of got.plt+size of gol.plt).
Is it criminal? I don't see anything wrong with gold inserting a
padding between .got.plt and .bss, why strip do not honor it?

 I believe that it can cause troubles later on for me when I start to
debug the application.
The fact that I linked with gold could be accidental, however when I
do the same with bfd the debuging is OK for me (but the addresses of
the sections are the same there).

thanks,
Alexander

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

[Alan Modra]

On Fri, Nov 29, 2013 at 03:49:18PM +0400, Alexander Ivchenko wrote:
>  As you can see the offset of .bss is changed now (it is equal now to
> the offset of got.plt+size of gol.plt).
> Is it criminal? I don't see anything wrong with gold inserting a
> padding between .got.plt and .bss, why strip do not honor it?

strip should not be doing this.  Please post the pre-stripped binary,
so someone can take a look, or better, open a bug report.

-- 
Alan Modra
Australia Development Lab, IBM

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

[Cary Coutant]

>>  As you can see the offset of .bss is changed now (it is equal now to
>> the offset of got.plt+size of gol.plt).
>> Is it criminal? I don't see anything wrong with gold inserting a
>> padding between .got.plt and .bss, why strip do not honor it?
>
> strip should not be doing this.  Please post the pre-stripped binary,
> so someone can take a look, or better, open a bug report.

It looks like only the file offset changed, and the file offset is
irrelevant for a BSS section. I don't think strip is doing any harm
here. While it would be nice for it to preserve as much as possible
from the input file (cf. the recent discussion about the PF_W flag on
PF_GNU_RELRO segments), I suspect the structure of BFD strip would
make it difficult in this case.

-cary

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

[Alan Modra]

On Mon, Dec 02, 2013 at 02:09:53PM -0800, Cary Coutant wrote:
> >>  As you can see the offset of .bss is changed now (it is equal now to
> >> the offset of got.plt+size of gol.plt).
> >> Is it criminal? I don't see anything wrong with gold inserting a
> >> padding between .got.plt and .bss, why strip do not honor it?
> >
> > strip should not be doing this.  Please post the pre-stripped binary,
> > so someone can take a look, or better, open a bug report.
> 
> It looks like only the file offset changed, and the file offset is
> irrelevant for a BSS section. I don't think strip is doing any harm
> here.

Oh right.  I misread the readelf fields, for some reason thinking that
offset came first.

-- 
Alan Modra
Australia Development Lab, IBM

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

[Alexander Ivchenko]

If you think that it is ok, I'll take a deeper look at my problem with
debugging (bfd linked is ok, gold linked is not), may be it is a
gdb<->gdbserver issue.

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.

I also do not understand the reasons behind gold inserting this
padding in the first place; if strip is allowed with no further
consequences to delete the padding, it looks like it is a good idea
for gold to just stop inserting it to save a few bits (and plus there
is the compatibility between bfd and gold, because it seems that bfd
does not insert it) .

--Alexander

2013/12/3 Alan Modra <amodra@gmail.com>:
> On Mon, Dec 02, 2013 at 02:09:53PM -0800, Cary Coutant wrote:
>> >>  As you can see the offset of .bss is changed now (it is equal now to
>> >> the offset of got.plt+size of gol.plt).
>> >> Is it criminal? I don't see anything wrong with gold inserting a
>> >> padding between .got.plt and .bss, why strip do not honor it?
>> >
>> > strip should not be doing this.  Please post the pre-stripped binary,
>> > so someone can take a look, or better, open a bug report.
>>
>> It looks like only the file offset changed, and the file offset is
>> irrelevant for a BSS section. I don't think strip is doing any harm
>> here.
>
> Oh right.  I misread the readelf fields, for some reason thinking that
> offset came first.
>
> --
> Alan Modra
> Australia Development Lab, IBM

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

[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.

-- 
Alan Modra
Australia Development Lab, IBM

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

[Alexander Ivchenko]

2013/12/3 Alan Modra <amodra@gmail.com>:
> 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

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

[Alexander Ivchenko]

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 <aivchenk@gmail.com>:
> 2013/12/3 Alan Modra <amodra@gmail.com>:
>> 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

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

[Alexander Ivchenko]

> 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

sorry: I've accidentally sent it before finishing. I meant that if I
firstly objcopy the linked binary (thus, erasing
 the padding between .got.plt and .bss) and then strip it, then
gdbserver<->gdb are successfully loading the debug info even for
gdbserver < 7.6.
That's cause in this case the addresses of all remained sections in
stripped and not stripped binaries are the same.

--Alexander

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

[Ian Lance Taylor]

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

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

[H.J. Lu]

On Mon, Dec 9, 2013 at 4:44 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
>> 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
>
> sorry: I've accidentally sent it before finishing. I meant that if I
> firstly objcopy the linked binary (thus, erasing
>  the padding between .got.plt and .bss) and then strip it, then
> gdbserver<->gdb are successfully loading the debug info even for
> gdbserver < 7.6.
> That's cause in this case the addresses of all remained sections in
> stripped and not stripped binaries are the same.
>

Please open a bug report with a testcase to show
the actual problem with GDB.  I will take a look.

Thanks.

-- 
H.J.

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

[Cary Coutant]

This sounds related to PR gdb/11786:

   https://sourceware.org/bugzilla/show_bug.cgi?id=11786

-cary


On Mon, Dec 9, 2013 at 8:04 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Dec 9, 2013 at 4:44 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
>>> 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
>>
>> sorry: I've accidentally sent it before finishing. I meant that if I
>> firstly objcopy the linked binary (thus, erasing
>>  the padding between .got.plt and .bss) and then strip it, then
>> gdbserver<->gdb are successfully loading the debug info even for
>> gdbserver < 7.6.
>> That's cause in this case the addresses of all remained sections in
>> stripped and not stripped binaries are the same.
>>
>
> Please open a bug report with a testcase to show
> the actual problem with GDB.  I will take a look.
>
> Thanks.
>
> --
> H.J.

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

[H.J. Lu]

On Mon, Dec 9, 2013 at 9:43 AM, Cary Coutant <ccoutant@google.com> wrote:
> This sounds related to PR gdb/11786:
>
>    https://sourceware.org/bugzilla/show_bug.cgi?id=11786

Hasn't that been fixed in GDB?

> -cary
>
>
> On Mon, Dec 9, 2013 at 8:04 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Dec 9, 2013 at 4:44 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
>>>> 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
>>>
>>> sorry: I've accidentally sent it before finishing. I meant that if I
>>> firstly objcopy the linked binary (thus, erasing
>>>  the padding between .got.plt and .bss) and then strip it, then
>>> gdbserver<->gdb are successfully loading the debug info even for
>>> gdbserver < 7.6.
>>> That's cause in this case the addresses of all remained sections in
>>> stripped and not stripped binaries are the same.
>>>
>>
>> Please open a bug report with a testcase to show
>> the actual problem with GDB.  I will take a look.
>>
>> Thanks.
>>
>> --
>> H.J.



-- 
H.J.

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

[Cary Coutant]

>> This sounds related to PR gdb/11786:
>>
>>    https://sourceware.org/bugzilla/show_bug.cgi?id=11786
>
> Hasn't that been fixed in GDB?

It has, for the specific cases where the PF_W bit for the PT_GNU_RELRO
segment was changed by strip, and where the p_align value was changed.
But this is yet another instance where strip changes something
unexpected and innocuous, and GDB thinks the binaries don't match even
when the two are effectively equivalent.

-cary

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

[H.J. Lu]

On Mon, Dec 9, 2013 at 10:58 AM, Cary Coutant <ccoutant@google.com> wrote:
>>> This sounds related to PR gdb/11786:
>>>
>>>    https://sourceware.org/bugzilla/show_bug.cgi?id=11786
>>
>> Hasn't that been fixed in GDB?
>
> It has, for the specific cases where the PF_W bit for the PT_GNU_RELRO
> segment was changed by strip, and where the p_align value was changed.
> But this is yet another instance where strip changes something
> unexpected and innocuous, and GDB thinks the binaries don't match even
> when the two are effectively equivalent.
>

A bug report is needed to investigate it.


-- 
H.J.

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

[Alexander Ivchenko]

2013/12/9 Ian Lance Taylor <iant@google.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?

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:
> 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.

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
similar.

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.


thanks,
Alexander

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

[H.J. Lu]

On Tue, Dec 10, 2013 at 5:10 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
> 2013/12/9 Ian Lance Taylor <iant@google.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?
>
> 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:
>> 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.
>
> 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..

This is a bug and should be fixed.  Please open a bug report
with a testcase.

>
>> 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
> similar.
>
> 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.
>


-- 
H.J.

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

[Alexander Ivchenko]

Bug report 16317

--Alexander

2013/12/10 H.J. Lu <hjl.tools@gmail.com>:
> On Tue, Dec 10, 2013 at 5:10 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
>> 2013/12/9 Ian Lance Taylor <iant@google.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?
>>
>> 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:
>>> 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.
>>
>> 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..
>
> This is a bug and should be fixed.  Please open a bug report
> with a testcase.
>
>>
>>> 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
>> similar.
>>
>> 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.
>>
>
>
> --
> H.J.

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

[H.J. Lu]

On Mon, Dec 9, 2013 at 7:58 AM, Ian Lance Taylor <iant@google.com> wrote:
> 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.
>

I did some investigation.  I think gold is wrong.  I
opened:

https://www.sourceware.org/bugzilla/show_bug.cgi?id=16321
https://www.sourceware.org/bugzilla/show_bug.cgi?id=16320



-- 
H.J.

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

[Cary Coutant]

> I did some investigation.  I think gold is wrong.  I
> opened:
>
> https://www.sourceware.org/bugzilla/show_bug.cgi?id=16321
> https://www.sourceware.org/bugzilla/show_bug.cgi?id=16320

If, by "wrong", you mean "different from Gnu ld", then sure. But I
don't think it's doing anything wrong in either case. The file offset
for a BSS section is completely meaningless, so whether we plug in the
next available value before or after aligning it is irrelevant. For
the TLS segment, including the padding in memsz but not in filesz is
also irrelevant, and should be harmless, although I'll admit that it
might be worth fixing that just for consistency's sake.

In my opinion, the real problems are: (a) strip basically re-draws the
file, and since it uses the same underlying framework as Gnu ld, it
produces the same output that Gnu ld would have produced; and (b) GDB
concludes that the stripped and unstripped files don't match just
because of irrelevant differences caused by (a). I think it's
impractical to insist that gold produce the same bits in all such
cases (keeping in mind that I'm sure we haven't found the last of
them).

-cary

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

[H.J. Lu]

On Wed, Dec 11, 2013 at 2:04 PM, Cary Coutant <ccoutant@google.com> wrote:
>> I did some investigation.  I think gold is wrong.  I
>> opened:
>>
>> https://www.sourceware.org/bugzilla/show_bug.cgi?id=16321
>> https://www.sourceware.org/bugzilla/show_bug.cgi?id=16320
>
> If, by "wrong", you mean "different from Gnu ld", then sure. But I
> don't think it's doing anything wrong in either case. The file offset
> for a BSS section is completely meaningless, so whether we plug in the
> next available value before or after aligning it is irrelevant. For

That is true.  It makes no difference if 0 or -1 is used.

> the TLS segment, including the padding in memsz but not in filesz is
> also irrelevant, and should be harmless, although I'll admit that it

It may be harmless, but it is waste of address space.

> might be worth fixing that just for consistency's sake.
>
> In my opinion, the real problems are: (a) strip basically re-draws the
> file, and since it uses the same underlying framework as Gnu ld, it
> produces the same output that Gnu ld would have produced; and (b) GDB

Not always.  I personally fixed a couple strip bugs :-(.

> concludes that the stripped and unstripped files don't match just
> because of irrelevant differences caused by (a). I think it's
> impractical to insist that gold produce the same bits in all such
> cases (keeping in mind that I'm sure we haven't found the last of
> them).
>

I don't think gold should generate the same layout as ld.
But for TLS segment, it makes no sense to have memsize
> filesize when there is no .tbss section.

-- 
H.J.

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

[H.J. Lu]

On Wed, Dec 11, 2013 at 2:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Dec 11, 2013 at 2:04 PM, Cary Coutant <ccoutant@google.com> wrote:
>>> I did some investigation.  I think gold is wrong.  I
>>> opened:
>>>
>>> https://www.sourceware.org/bugzilla/show_bug.cgi?id=16321
>>> https://www.sourceware.org/bugzilla/show_bug.cgi?id=16320
>>
>> If, by "wrong", you mean "different from Gnu ld", then sure. But I
>> don't think it's doing anything wrong in either case. The file offset
>> for a BSS section is completely meaningless, so whether we plug in the
>> next available value before or after aligning it is irrelevant. For
>
> That is true.  It makes no difference if 0 or -1 is used.
>
>> the TLS segment, including the padding in memsz but not in filesz is
>> also irrelevant, and should be harmless, although I'll admit that it
>
> It may be harmless, but it is waste of address space.
>
>> might be worth fixing that just for consistency's sake.
>>
>> In my opinion, the real problems are: (a) strip basically re-draws the
>> file, and since it uses the same underlying framework as Gnu ld, it
>> produces the same output that Gnu ld would have produced; and (b) GDB
>
> Not always.  I personally fixed a couple strip bugs :-(.

I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=16323

strip changes PL_LOAD segment generated by gold.


-- 
H.J.