* [gold, strip] Question about the changed offset when stripping @ 2013-11-29 11:57 Alexander Ivchenko 2013-11-29 18:55 ` Alan Modra 0 siblings, 1 reply; 22+ messages in thread From: Alexander Ivchenko @ 2013-11-29 11:57 UTC (permalink / raw) To: binutils, Ian Lance Taylor, Cary Coutant 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-11-29 11:57 [gold, strip] Question about the changed offset when stripping Alexander Ivchenko @ 2013-11-29 18:55 ` Alan Modra 2013-12-02 22:10 ` Cary Coutant 0 siblings, 1 reply; 22+ messages in thread From: Alan Modra @ 2013-11-29 18:55 UTC (permalink / raw) To: Alexander Ivchenko; +Cc: binutils, Ian Lance Taylor, Cary Coutant 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-11-29 18:55 ` Alan Modra @ 2013-12-02 22:10 ` Cary Coutant 2013-12-03 10:10 ` Alan Modra 0 siblings, 1 reply; 22+ messages in thread From: Cary Coutant @ 2013-12-02 22:10 UTC (permalink / raw) To: Alexander Ivchenko, binutils, Ian Lance Taylor, 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-02 22:10 ` Cary Coutant @ 2013-12-03 10:10 ` Alan Modra 2013-12-03 10:30 ` Alexander Ivchenko 0 siblings, 1 reply; 22+ messages in thread From: Alan Modra @ 2013-12-03 10:10 UTC (permalink / raw) To: Cary Coutant; +Cc: Alexander Ivchenko, binutils, Ian Lance Taylor 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-03 10:10 ` Alan Modra @ 2013-12-03 10:30 ` Alexander Ivchenko 2013-12-03 11:23 ` Alan Modra 0 siblings, 1 reply; 22+ messages in thread From: Alexander Ivchenko @ 2013-12-03 10:30 UTC (permalink / raw) To: Cary Coutant, Alexander Ivchenko, binutils, Ian Lance Taylor 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-03 10:30 ` Alexander Ivchenko @ 2013-12-03 11:23 ` Alan Modra 2013-12-03 11:40 ` Alexander Ivchenko 0 siblings, 1 reply; 22+ messages in thread From: Alan Modra @ 2013-12-03 11:23 UTC (permalink / raw) To: Alexander Ivchenko; +Cc: Cary Coutant, binutils, Ian Lance Taylor 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-03 11:23 ` Alan Modra @ 2013-12-03 11:40 ` Alexander Ivchenko 2013-12-09 12:33 ` Alexander Ivchenko 0 siblings, 1 reply; 22+ messages in thread From: Alexander Ivchenko @ 2013-12-03 11:40 UTC (permalink / raw) To: Alexander Ivchenko, Cary Coutant, binutils, Ian Lance Taylor 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-03 11:40 ` Alexander Ivchenko @ 2013-12-09 12:33 ` Alexander Ivchenko 2013-12-09 12:45 ` Alexander Ivchenko 2013-12-09 15:58 ` Ian Lance Taylor 0 siblings, 2 replies; 22+ messages in thread From: Alexander Ivchenko @ 2013-12-09 12:33 UTC (permalink / raw) To: Alexander Ivchenko, Cary Coutant, binutils, Ian Lance Taylor 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 12:33 ` Alexander Ivchenko @ 2013-12-09 12:45 ` Alexander Ivchenko 2013-12-09 16:04 ` H.J. Lu 2013-12-09 15:58 ` Ian Lance Taylor 1 sibling, 1 reply; 22+ messages in thread From: Alexander Ivchenko @ 2013-12-09 12:45 UTC (permalink / raw) To: Alexander Ivchenko, Cary Coutant, binutils, Ian Lance Taylor > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 12:45 ` Alexander Ivchenko @ 2013-12-09 16:04 ` H.J. Lu 2013-12-09 17:43 ` Cary Coutant 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2013-12-09 16:04 UTC (permalink / raw) To: Alexander Ivchenko; +Cc: Cary Coutant, binutils, Ian Lance Taylor 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 16:04 ` H.J. Lu @ 2013-12-09 17:43 ` Cary Coutant 2013-12-09 18:22 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Cary Coutant @ 2013-12-09 17:43 UTC (permalink / raw) To: H.J. Lu; +Cc: Alexander Ivchenko, binutils, Ian Lance Taylor 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 17:43 ` Cary Coutant @ 2013-12-09 18:22 ` H.J. Lu 2013-12-09 18:58 ` Cary Coutant 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2013-12-09 18:22 UTC (permalink / raw) To: Cary Coutant; +Cc: Alexander Ivchenko, binutils, Ian Lance Taylor 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 18:22 ` H.J. Lu @ 2013-12-09 18:58 ` Cary Coutant 2013-12-09 19:09 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Cary Coutant @ 2013-12-09 18:58 UTC (permalink / raw) To: H.J. Lu; +Cc: Alexander Ivchenko, binutils, Ian Lance Taylor >> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 18:58 ` Cary Coutant @ 2013-12-09 19:09 ` H.J. Lu 2013-12-10 13:10 ` Alexander Ivchenko 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2013-12-09 19:09 UTC (permalink / raw) To: Cary Coutant; +Cc: Alexander Ivchenko, binutils, Ian Lance Taylor 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 19:09 ` H.J. Lu @ 2013-12-10 13:10 ` Alexander Ivchenko 2013-12-10 13:34 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Alexander Ivchenko @ 2013-12-10 13:10 UTC (permalink / raw) To: H.J. Lu; +Cc: Cary Coutant, binutils, Ian Lance Taylor 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-10 13:10 ` Alexander Ivchenko @ 2013-12-10 13:34 ` H.J. Lu 2013-12-11 11:17 ` Alexander Ivchenko 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2013-12-10 13:34 UTC (permalink / raw) To: Alexander Ivchenko; +Cc: Cary Coutant, binutils, Ian Lance Taylor 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-10 13:34 ` H.J. Lu @ 2013-12-11 11:17 ` Alexander Ivchenko 0 siblings, 0 replies; 22+ messages in thread From: Alexander Ivchenko @ 2013-12-11 11:17 UTC (permalink / raw) To: H.J. Lu; +Cc: Cary Coutant, binutils, Ian Lance Taylor 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 12:33 ` Alexander Ivchenko 2013-12-09 12:45 ` Alexander Ivchenko @ 2013-12-09 15:58 ` Ian Lance Taylor 2013-12-11 21:29 ` H.J. Lu 1 sibling, 1 reply; 22+ messages in thread From: Ian Lance Taylor @ 2013-12-09 15:58 UTC (permalink / raw) To: Alexander Ivchenko; +Cc: Cary Coutant, binutils 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-09 15:58 ` Ian Lance Taylor @ 2013-12-11 21:29 ` H.J. Lu 2013-12-11 22:04 ` Cary Coutant 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2013-12-11 21:29 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Alexander Ivchenko, Cary Coutant, binutils 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-11 21:29 ` H.J. Lu @ 2013-12-11 22:04 ` Cary Coutant 2013-12-11 22:29 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Cary Coutant @ 2013-12-11 22:04 UTC (permalink / raw) To: H.J. Lu; +Cc: Ian Lance Taylor, Alexander Ivchenko, binutils > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-11 22:04 ` Cary Coutant @ 2013-12-11 22:29 ` H.J. Lu 2013-12-12 13:54 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2013-12-11 22:29 UTC (permalink / raw) To: Cary Coutant; +Cc: Ian Lance Taylor, Alexander Ivchenko, binutils 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [gold, strip] Question about the changed offset when stripping 2013-12-11 22:29 ` H.J. Lu @ 2013-12-12 13:54 ` H.J. Lu 0 siblings, 0 replies; 22+ messages in thread From: H.J. Lu @ 2013-12-12 13:54 UTC (permalink / raw) To: Cary Coutant; +Cc: Ian Lance Taylor, Alexander Ivchenko, binutils 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-12-12 13:54 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-29 11:57 [gold, strip] Question about the changed offset when stripping Alexander Ivchenko 2013-11-29 18:55 ` Alan Modra 2013-12-02 22:10 ` Cary Coutant 2013-12-03 10:10 ` Alan Modra 2013-12-03 10:30 ` Alexander Ivchenko 2013-12-03 11:23 ` Alan Modra 2013-12-03 11:40 ` Alexander Ivchenko 2013-12-09 12:33 ` Alexander Ivchenko 2013-12-09 12:45 ` Alexander Ivchenko 2013-12-09 16:04 ` H.J. Lu 2013-12-09 17:43 ` Cary Coutant 2013-12-09 18:22 ` H.J. Lu 2013-12-09 18:58 ` Cary Coutant 2013-12-09 19:09 ` H.J. Lu 2013-12-10 13:10 ` Alexander Ivchenko 2013-12-10 13:34 ` H.J. Lu 2013-12-11 11:17 ` Alexander Ivchenko 2013-12-09 15:58 ` Ian Lance Taylor 2013-12-11 21:29 ` H.J. Lu 2013-12-11 22:04 ` Cary Coutant 2013-12-11 22:29 ` H.J. Lu 2013-12-12 13:54 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).