* rebase segfault @ 2013-01-15 8:44 marco atzeri 2013-01-15 10:08 ` Corinna Vinschen 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-15 8:44 UTC (permalink / raw) To: cygwin rebase is segfaulting on two dlls of new package postgresql-contrib-9.2.2-1 Full packages here http://matzeri.altervista.org/cygwin-1.7/postgresql/ Just the two dll's here: http://matzeri.altervista.org/works/rebase/ for i in *.dll; do echo $i ; rebase -O $i ; done dict_snowball.dll Segmentation fault (core dumped) ltree.dll Segmentation fault (core dumped) ltree.dll: file format pei-i386 ltree.dll architecture: i386, flags 0x0000010b: HAS_RELOC, EXEC_P, HAS_DEBUG, D_PAGED start address 0x4ef39370 Characteristics 0x212e executable line numbers stripped symbols stripped large address aware 32 bit words DLL Time/Date Tue Jan 15 09:32:57 2013 Magic 010b (PE32) MajorLinkerVersion 2 MinorLinkerVersion 22 SizeOfCode 00008a00 SizeOfInitializedData 0000ba00 SizeOfUninitializedData 00000200 AddressOfEntryPoint 00009370 BaseOfCode 00001000 BaseOfData 0000a000 ImageBase 4ef30000 SectionAlignment 00001000 FileAlignment 00000200 MajorOSystemVersion 4 MinorOSystemVersion 0 MajorImageVersion 1 MinorImageVersion 0 MajorSubsystemVersion 4 MinorSubsystemVersion 0 Win32Version 00000000 SizeOfImage 00010000 SizeOfHeaders 00000400 CheckSum 00012036 Subsystem 00000003 (Windows CUI) DllCharacteristics 00008000 SizeOfStackReserve 00200000 SizeOfStackCommit 00001000 SizeOfHeapReserve 00100000 SizeOfHeapCommit 00001000 LoaderFlags 00000000 NumberOfRvaAndSizes 00000010 Nothing obvious for me, but I am not a rebase expert... Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: rebase segfault 2013-01-15 8:44 rebase segfault marco atzeri @ 2013-01-15 10:08 ` Corinna Vinschen 2013-01-15 10:36 ` marco atzeri 0 siblings, 1 reply; 41+ messages in thread From: Corinna Vinschen @ 2013-01-15 10:08 UTC (permalink / raw) To: cygwin On Jan 15 09:43, marco atzeri wrote: > rebase is segfaulting on two dlls of new package > > postgresql-contrib-9.2.2-1 > > Full packages here > http://matzeri.altervista.org/cygwin-1.7/postgresql/ > > Just the two dll's here: > http://matzeri.altervista.org/works/rebase/ > > for i in *.dll; do echo $i ; rebase -O $i ; done > > dict_snowball.dll > Segmentation fault (core dumped) > > ltree.dll > Segmentation fault (core dumped) I don't know exactly what's going on here, but there's a common factor: $ objdump -h dict_snowball.dll dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 4ef01000 4ef01000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 4ef18000 4ef18000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 4ef30000 4ef30000 00000000 2**5 ALLOC 3 .edata 00000fe0 4ef31000 4ef31000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000003e0 4ef32000 4ef32000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 0000765c 4ef33000 4ef33000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_deb 0000001c 4ef3b000 4ef3b000 00036c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA $ objdump -h ltree.dll ltree.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 000088a8 4ef31000 4ef31000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00000dc0 4ef3a000 4ef3a000 00008e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 4ef3b000 4ef3b000 00000000 2**5 ALLOC 3 .edata 00000e3c 4ef3c000 4ef3c000 00009c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000005b8 4ef3d000 4ef3d000 0000ac00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 00000adc 4ef3e000 4ef3e000 0000b200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_deb 00000014 4ef3f000 4ef3f000 0000be00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Both DLLs have a section .gnu_deb, whatever that one is good for. Rebase crashes both times when trying to relocate this .gnu_deb section. As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 bytes. What happens is that the relocation information for the .gnu_deb section appears to be too big. In case of dict_snowball.dll, the reloc info covers 44 relocation entries. The segfault occurs as soon as one entry translates into a memory address which is beyond the committed area of the file memory map. Now, that's the *effect*. From this I can't say what the *cause* for this weird relocation info is. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: rebase segfault 2013-01-15 10:08 ` Corinna Vinschen @ 2013-01-15 10:36 ` marco atzeri 2013-01-15 11:24 ` Corinna Vinschen 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-15 10:36 UTC (permalink / raw) To: cygwin On 1/15/2013 11:07 AM, Corinna Vinschen wrote: > On Jan 15 09:43, marco atzeri wrote: >> rebase is segfaulting on two dlls of new package >> >> postgresql-contrib-9.2.2-1 >> >> Full packages here >> http://matzeri.altervista.org/cygwin-1.7/postgresql/ >> >> Just the two dll's here: >> http://matzeri.altervista.org/works/rebase/ >> >> for i in *.dll; do echo $i ; rebase -O $i ; done >> >> dict_snowball.dll >> Segmentation fault (core dumped) >> >> ltree.dll >> Segmentation fault (core dumped) > > I don't know exactly what's going on here, but there's a common > factor: > > $ objdump -h dict_snowball.dll > > dict_snowball.dll: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00016808 4ef01000 4ef01000 00000400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA > 1 .data 00017180 4ef18000 4ef18000 00016e00 2**5 > CONTENTS, ALLOC, LOAD, DATA > 2 .bss 000000f8 4ef30000 4ef30000 00000000 2**5 > ALLOC > 3 .edata 00000fe0 4ef31000 4ef31000 0002e000 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .idata 000003e0 4ef32000 4ef32000 0002f000 2**2 > CONTENTS, ALLOC, LOAD, DATA > 5 .reloc 0000765c 4ef33000 4ef33000 0002f400 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 .gnu_deb 0000001c 4ef3b000 4ef3b000 00036c00 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > > $ objdump -h ltree.dll > > ltree.dll: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 000088a8 4ef31000 4ef31000 00000400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA > 1 .data 00000dc0 4ef3a000 4ef3a000 00008e00 2**5 > CONTENTS, ALLOC, LOAD, DATA > 2 .bss 000000f8 4ef3b000 4ef3b000 00000000 2**5 > ALLOC > 3 .edata 00000e3c 4ef3c000 4ef3c000 00009c00 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .idata 000005b8 4ef3d000 4ef3d000 0000ac00 2**2 > CONTENTS, ALLOC, LOAD, DATA > 5 .reloc 00000adc 4ef3e000 4ef3e000 0000b200 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 .gnu_deb 00000014 4ef3f000 4ef3f000 0000be00 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > > Both DLLs have a section .gnu_deb, whatever that one is good for. > Rebase crashes both times when trying to relocate this .gnu_deb section. > As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 > bytes. What happens is that the relocation information for the .gnu_deb > section appears to be too big. In case of dict_snowball.dll, the reloc > info covers 44 relocation entries. The segfault occurs as soon as one > entry translates into a memory address which is beyond the committed > area of the file memory map. > > Now, that's the *effect*. From this I can't say what the *cause* > for this weird relocation info is. > > > Corinna > It seems the result of the .dbg creation, that trunks wrongly the sections. I uploaded also the build and stripped versions: $ objdump.exe -h build/dict_snowball.dll build/dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 67ec1000 67ec1000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5 ALLOC 3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .debug_aranges 00000560 67efb000 67efb000 00036c00 2**0 CONTENTS, READONLY, DEBUGGING 7 .debug_pubnames 00001112 67efc000 67efc000 00037200 2**0 CONTENTS, READONLY, DEBUGGING 8 .debug_pubtypes 00000f49 67efe000 67efe000 00038400 2**0 CONTENTS, READONLY, DEBUGGING 9 .debug_info 00048851 67eff000 67eff000 00039400 2**0 CONTENTS, READONLY, DEBUGGING 10 .debug_abbrev 000050a3 67f48000 67f48000 00081e00 2**0 CONTENTS, READONLY, DEBUGGING 11 .debug_line 000078a3 67f4e000 67f4e000 00087000 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_frame 00002114 67f56000 67f56000 0008ea00 2**2 CONTENTS, READONLY, DEBUGGING 13 .debug_str 00000664 67f59000 67f59000 00090c00 2**0 CONTENTS, READONLY, DEBUGGING 14 .debug_loc 000170a4 67f5a000 67f5a000 00091400 2**0 CONTENTS, READONLY, DEBUGGING 15 .debug_ranges 0000f3a0 67f72000 67f72000 000a8600 2**0 CONTENTS, READONLY, DEBUGGING Stripped $ objdump.exe -h strip/dict_snowball.dll strip/dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 67ec1000 67ec1000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5 ALLOC 3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA for what I can see a dll with debug symbols should have a .gnu_debuglink sections: $ objdump -h /usr/bin/cygmpi-0.dll /usr/bin/cygmpi-0.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00181a28 5e1d1000 5e1d1000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00035a40 5e353000 5e353000 00182000 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .rdata 00008460 5e389000 5e389000 001b7c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .eh_frame 000250b8 5e392000 5e392000 001c0200 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .bss 0008cd98 5e3b8000 5e3b8000 00000000 2**5 ALLOC 5 .edata 000214b4 5e445000 5e445000 001e5400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .idata 00002adc 5e467000 5e467000 00206a00 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .reloc 0001459c 5e46a000 5e46a000 00209600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .gnu_debuglink 00000018 5e47f000 5e47f000 0021dc00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: rebase segfault 2013-01-15 10:36 ` marco atzeri @ 2013-01-15 11:24 ` Corinna Vinschen 2013-01-15 22:04 ` marco atzeri 0 siblings, 1 reply; 41+ messages in thread From: Corinna Vinschen @ 2013-01-15 11:24 UTC (permalink / raw) To: cygwin On Jan 15 11:36, marco atzeri wrote: > On 1/15/2013 11:07 AM, Corinna Vinschen wrote: > >On Jan 15 09:43, marco atzeri wrote: > >>rebase is segfaulting on two dlls of new package > >> > >>postgresql-contrib-9.2.2-1 > >> > >>Full packages here > >>http://matzeri.altervista.org/cygwin-1.7/postgresql/ > >> > >>Just the two dll's here: > >>http://matzeri.altervista.org/works/rebase/ > >> > >>for i in *.dll; do echo $i ; rebase -O $i ; done > >> > >>dict_snowball.dll > >>Segmentation fault (core dumped) > >> > >>ltree.dll > >>Segmentation fault (core dumped) > > > >I don't know exactly what's going on here, but there's a common > >factor: > > [...] > >Both DLLs have a section .gnu_deb, whatever that one is good for. > >Rebase crashes both times when trying to relocate this .gnu_deb section. > >As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 > >bytes. What happens is that the relocation information for the .gnu_deb > >section appears to be too big. In case of dict_snowball.dll, the reloc > >info covers 44 relocation entries. The segfault occurs as soon as one > >entry translates into a memory address which is beyond the committed > >area of the file memory map. > >[...] > > It seems the result of the .dbg creation, that trunks > wrongly the sections. > [...] > for what I can see a dll with debug symbols > should have a .gnu_debuglink sections: Right. Something's scrambled. AFAIK, the .gnu_debuglink is not relocatable, it only contains a path. ".gnu_deb" appears to be a result of using only the fixed 8 bytes of the section name. Yaakov, do you have any idea what's going on here? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: rebase segfault 2013-01-15 11:24 ` Corinna Vinschen @ 2013-01-15 22:04 ` marco atzeri 2013-01-16 7:16 ` marco atzeri 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-15 22:04 UTC (permalink / raw) To: cygwin On 1/15/2013 12:24 PM, Corinna Vinschen wrote: > On Jan 15 11:36, marco atzeri wrote: >> On 1/15/2013 11:07 AM, Corinna Vinschen wrote: >>> On Jan 15 09:43, marco atzeri wrote: >>>> rebase is segfaulting on two dlls of new package >>>> >>>> postgresql-contrib-9.2.2-1 >>>> >>>> Full packages here >>>> http://matzeri.altervista.org/cygwin-1.7/postgresql/ >>>> >>>> Just the two dll's here: >>>> http://matzeri.altervista.org/works/rebase/ >>>> >>>> for i in *.dll; do echo $i ; rebase -O $i ; done >>>> >>>> dict_snowball.dll >>>> Segmentation fault (core dumped) >>>> >>>> ltree.dll >>>> Segmentation fault (core dumped) >>> >>> I don't know exactly what's going on here, but there's a common >>> factor: >>> [...] >>> Both DLLs have a section .gnu_deb, whatever that one is good for. >>> Rebase crashes both times when trying to relocate this .gnu_deb section. >>> As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 >>> bytes. What happens is that the relocation information for the .gnu_deb >>> section appears to be too big. In case of dict_snowball.dll, the reloc >>> info covers 44 relocation entries. The segfault occurs as soon as one >>> entry translates into a memory address which is beyond the committed >>> area of the file memory map. >>> [...] >> >> It seems the result of the .dbg creation, that trunks >> wrongly the sections. >> [...] >> for what I can see a dll with debug symbols >> should have a .gnu_debuglink sections: > > Right. Something's scrambled. AFAIK, the .gnu_debuglink is not > relocatable, it only contains a path. ".gnu_deb" appears to be > a result of using only the fixed 8 bytes of the section name. > Yaakov, do you have any idea what's going on here? it seems that objcopy is considering the --long-section-names {enable|disable|keep} as disable (or keeping an incorrect disable) using in sequence on a stripped ltree.dll $ objcopy -v --add-gnu-debuglink="ltree.dll.dbg" ltree.dll $ objcopy -v --long-section-names enable --add-gnu-debuglink="ltree.dll.dbg" ltree.dll $ objdump -h ltree.dll ltree.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 000088a8 6fc81000 6fc81000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00000dc0 6fc8a000 6fc8a000 00008e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 6fc8b000 6fc8b000 00000000 2**5 ALLOC 3 .edata 00000e3c 6fc8c000 6fc8c000 00009c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000005b8 6fc8d000 6fc8d000 0000ac00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 00000adc 6fc8e000 6fc8e000 0000b200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_deb 00000014 6fc8f000 6fc8f000 0000be00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .gnu_debuglink 00000014 6fc90000 6fc90000 0000c000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA I consider this a bug of objcopy: "--add-gnu-debuglink" should imply "--long-section-names enable" > > > Corinna > Regards MArco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: rebase segfault 2013-01-15 22:04 ` marco atzeri @ 2013-01-16 7:16 ` marco atzeri 2013-01-16 12:35 ` Binutils objcopy bug (was Re: rebase segfault) Corinna Vinschen 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-16 7:16 UTC (permalink / raw) To: cygwin On 1/15/2013 11:03 PM, marco atzeri wrote: > On 1/15/2013 12:24 PM, Corinna Vinschen wrote: >> On Jan 15 11:36, marco atzeri wrote: >>> On 1/15/2013 11:07 AM, Corinna Vinschen wrote: >>>> On Jan 15 09:43, marco atzeri wrote: >>>>> rebase is segfaulting on two dlls of new package >>>>> >>>>> postgresql-contrib-9.2.2-1 >>>>> >>>>> Full packages here >>>>> http://matzeri.altervista.org/cygwin-1.7/postgresql/ >>>>> >>>>> Just the two dll's here: >>>>> http://matzeri.altervista.org/works/rebase/ >>>>> >>>>> for i in *.dll; do echo $i ; rebase -O $i ; done >>>>> >>>>> dict_snowball.dll >>>>> Segmentation fault (core dumped) >>>>> >>>>> ltree.dll >>>>> Segmentation fault (core dumped) >>>> >>>> I don't know exactly what's going on here, but there's a common >>>> factor: >>>> [...] >>>> Both DLLs have a section .gnu_deb, whatever that one is good for. >>>> Rebase crashes both times when trying to relocate this .gnu_deb >>>> section. >>>> As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 >>>> bytes. What happens is that the relocation information for the >>>> .gnu_deb >>>> section appears to be too big. In case of dict_snowball.dll, the reloc >>>> info covers 44 relocation entries. The segfault occurs as soon as one >>>> entry translates into a memory address which is beyond the committed >>>> area of the file memory map. >>>> [...] >>> >>> It seems the result of the .dbg creation, that trunks >>> wrongly the sections. >>> [...] >>> for what I can see a dll with debug symbols >>> should have a .gnu_debuglink sections: >> >> Right. Something's scrambled. AFAIK, the .gnu_debuglink is not >> relocatable, it only contains a path. ".gnu_deb" appears to be >> a result of using only the fixed 8 bytes of the section name. >> Yaakov, do you have any idea what's going on here? > > it seems that objcopy is considering the > > --long-section-names {enable|disable|keep} > > as disable (or keeping an incorrect disable) > > using in sequence on a stripped ltree.dll > it seems only a symptom, also using that, I have still one rebase segfault more crazy than before. (ltree.dll is fine now) $ objdump -h dict_snowball.dll dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 67ec1000 67ec1000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5 ALLOC 3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_debuglink 0000001c 67efb000 67efb000 00036c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA $ rebase -O dict_snowball.dll Segmentation fault (core dumped) It segfaults and a spurious character appears on the section: $ objdump -h dict_snowball.dll dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 4e971000 4e971000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 4e988000 4e988000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 4e9a0000 4e9a0000 00000000 2**5 ALLOC 3 .edata 00000fe0 4e9a1000 4e9a1000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000003e0 4e9a2000 4e9a2000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 0000765c 4e9a3000 4e9a3000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_debuglinkâ 0000001c 4e9ab000 4e9ab000 00036c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA but the second time it works $ rebase -O dict_snowball.dll So it is now a rebase bug, a objcopy bug or both ? all files here: http://matzeri.altervista.org/works/rebase/ Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 7:16 ` marco atzeri @ 2013-01-16 12:35 ` Corinna Vinschen 2013-01-16 13:38 ` marco atzeri ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Corinna Vinschen @ 2013-01-16 12:35 UTC (permalink / raw) To: cygwin On Jan 16 08:15, marco atzeri wrote: > On 1/15/2013 11:03 PM, marco atzeri wrote: > >On 1/15/2013 12:24 PM, Corinna Vinschen wrote: > >>On Jan 15 11:36, marco atzeri wrote: > >>>On 1/15/2013 11:07 AM, Corinna Vinschen wrote: > >>>> The segfault occurs as soon as one > >>>>entry translates into a memory address which is beyond the committed > >>>>area of the file memory map. > >>>>[...] > [...] > it seems only a symptom, also using that, I have still one > rebase segfault more crazy than before. > (ltree.dll is fine now) This is not really the case, you just don't see it anymore. As I wrote in my first reply, what happens is that the relocation information points outside of the file map. The below effect on dict_snowball.dll shows what's going wrong. > $ rebase -O dict_snowball.dll > Segmentation fault (core dumped) > > It segfaults and a spurious character appears on the section: > > $ objdump -h dict_snowball.dll > > dict_snowball.dll: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00016808 4e971000 4e971000 00000400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA > 1 .data 00017180 4e988000 4e988000 00016e00 2**5 > CONTENTS, ALLOC, LOAD, DATA > 2 .bss 000000f8 4e9a0000 4e9a0000 00000000 2**5 > ALLOC > 3 .edata 00000fe0 4e9a1000 4e9a1000 0002e000 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .idata 000003e0 4e9a2000 4e9a2000 0002f000 2**2 > CONTENTS, ALLOC, LOAD, DATA > 5 .reloc 0000765c 4e9a3000 4e9a3000 0002f400 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 .gnu_debuglinkâ 0000001c 4e9ab000 4e9ab000 00036c00 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > > but the second time it works > $ rebase -O dict_snowball.dll It only works because the file isn't rebased at all since, apparently, it already has been rebased, so the file is left alone. > So it is now a rebase bug, a objcopy bug or both ? As far as I can tell it's an objcopy bug. The stripped version of the DLL has a normal relocation information which at one point ends in a NULL IMAGE_BASE_RELOCATION record, as expected. After calling `objcopy --add-gnu-debuglink', the relocation information is supposed to be the same as before, since the relocatable file content didn't change. Nevertheless, when stepping through the relocator code in rebase, it turns out that the former NULL IMAGE_BASE_RELOCATION record does not contain only 0 values anymore. Rather, it has been overwritten with some random(?) non-0 values, which rebase correctly interprets as the start of the next IMAGE_BASE_RELOCATION array. So rebase blunders along, thus either just SEGVing, if everything goes well, or, worst case, overwriting formerly correct information in the file with arbitrary data. This is a serious bug in objcopy in the current binutils. Given that cygport creates the debug info automatically, we might end up with spuriously broken DLLs in the distro. I checked with objcopy from the older binutils 2.51.53-2, and the problem did not show up. I also built the latest binutils release 2.23.1 and the problem also doesn't show, so we probably can get away with just a black eye by updating binutils to 2.23.1. Chris? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 12:35 ` Binutils objcopy bug (was Re: rebase segfault) Corinna Vinschen @ 2013-01-16 13:38 ` marco atzeri 2013-01-16 14:42 ` Corinna Vinschen 2013-01-24 9:02 ` Yaakov 2013-01-18 15:34 ` marco atzeri 2013-01-19 8:56 ` marco atzeri 2 siblings, 2 replies; 41+ messages in thread From: marco atzeri @ 2013-01-16 13:38 UTC (permalink / raw) To: cygwin On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > On Jan 16 08:15, marco atzeri wrote: >> On 1/15/2013 11:03 PM, marco atzeri wrote: >>> On 1/15/2013 12:24 PM, Corinna Vinschen wrote: >>>> On Jan 15 11:36, marco atzeri wrote: >>>>> On 1/15/2013 11:07 AM, Corinna Vinschen wrote: > > This is a serious bug in objcopy in the current binutils. Given that > cygport creates the debug info automatically, we might end up with > spuriously broken DLLs in the distro. we already have some : /usr/bin/cygcrypto-1.0.0.dll 8 .gnu_deb 0000001c 67542000 67542000 0017ac00 2**2 /usr/bin/cyglsa.dll 6 .gnu_deb 00000014 10007000 10007000 00001400 2**2 /usr/bin/cygssl-1.0.0.dll 8 .gnu_deb 0000001c 58fcf000 58fcf000 00059a00 2**2 > > I checked with objcopy from the older binutils 2.51.53-2, and the > problem did not show up. I also built the latest binutils release > 2.23.1 and the problem also doesn't show, so we probably can get away > with just a black eye by updating binutils to 2.23.1. Chris? > > > Corinna > Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 13:38 ` marco atzeri @ 2013-01-16 14:42 ` Corinna Vinschen 2013-01-16 15:12 ` marco atzeri 2013-01-24 9:02 ` Yaakov 1 sibling, 1 reply; 41+ messages in thread From: Corinna Vinschen @ 2013-01-16 14:42 UTC (permalink / raw) To: cygwin On Jan 16 14:38, marco atzeri wrote: > On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > >On Jan 16 08:15, marco atzeri wrote: > >>On 1/15/2013 11:03 PM, marco atzeri wrote: > >>>On 1/15/2013 12:24 PM, Corinna Vinschen wrote: > >>>>On Jan 15 11:36, marco atzeri wrote: > >>>>>On 1/15/2013 11:07 AM, Corinna Vinschen wrote: > > > > >This is a serious bug in objcopy in the current binutils. Given that > >cygport creates the debug info automatically, we might end up with > >spuriously broken DLLs in the distro. > > we already have some : > > /usr/bin/cygcrypto-1.0.0.dll > 8 .gnu_deb 0000001c 67542000 67542000 0017ac00 2**2 > > /usr/bin/cyglsa.dll > 6 .gnu_deb 00000014 10007000 10007000 00001400 2**2 > > /usr/bin/cygssl-1.0.0.dll > 8 .gnu_deb 0000001c 58fcf000 58fcf000 00059a00 2**2 Drat. > >I checked with objcopy from the older binutils 2.51.53-2, and the > >problem did not show up. I also built the latest binutils release > >2.23.1 and the problem also doesn't show, so we probably can get away > >with just a black eye by updating binutils to 2.23.1. Chris? > > > > > >Corinna I forgot to mention, the --long-section-names enable option was never default, apparently. This would have to be fixed in cygport, I guess. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 14:42 ` Corinna Vinschen @ 2013-01-16 15:12 ` marco atzeri 2013-01-16 16:26 ` Corinna Vinschen 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-16 15:12 UTC (permalink / raw) To: cygwin On 1/16/2013 3:42 PM, Corinna Vinschen wrote: > > I forgot to mention, the --long-section-names enable option was > never default, apparently. This would have to be fixed in cygport, > I guess. The default seems to keep previous value, but as ".gnu_debuglink" is a long name at list in that case should be the default of objcopy to use it. I noticed during my tests: the build version have long names (.debug_aranges, .debug_loc ..) the stripped version usually not (.text, .rdata, .reloc ..) But, there is a field somewhere in the exe format about long-section-names ? If so, is it incorrectly filled by some other utility ? I found no info in the coff format, nor looking in the objcopy source. > Corinna > Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 15:12 ` marco atzeri @ 2013-01-16 16:26 ` Corinna Vinschen 0 siblings, 0 replies; 41+ messages in thread From: Corinna Vinschen @ 2013-01-16 16:26 UTC (permalink / raw) To: cygwin On Jan 16 16:12, marco atzeri wrote: > On 1/16/2013 3:42 PM, Corinna Vinschen wrote: > > > > >I forgot to mention, the --long-section-names enable option was > >never default, apparently. This would have to be fixed in cygport, > >I guess. > > The default seems to keep previous value, but > as ".gnu_debuglink" is a long name at list in that > case should be the default of objcopy to use it. > > I noticed during my tests: > the build version have long names (.debug_aranges, .debug_loc ..) > the stripped version usually not (.text, .rdata, .reloc ..) > But, there is a field somewhere in the exe format > about long-section-names ? If so, is it incorrectly filled by some > other utility ? There's no such field. Of course you could argue that it's a bug in objcopy nevertheless. If the user specifies a long section name on the command line, why does objcopy not preserve it by default? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 13:38 ` marco atzeri 2013-01-16 14:42 ` Corinna Vinschen @ 2013-01-24 9:02 ` Yaakov 2013-01-24 9:28 ` Corinna Vinschen 1 sibling, 1 reply; 41+ messages in thread From: Yaakov @ 2013-01-24 9:02 UTC (permalink / raw) To: cygwin On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote: > On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > > On Jan 16 08:15, marco atzeri wrote: > >> On 1/15/2013 11:03 PM, marco atzeri wrote: > >>> On 1/15/2013 12:24 PM, Corinna Vinschen wrote: > > This is a serious bug in objcopy in the current binutils. Given that > > cygport creates the debug info automatically, we might end up with > > spuriously broken DLLs in the distro. > > we already have some : > > /usr/bin/cygcrypto-1.0.0.dll > 8 .gnu_deb 0000001c 67542000 67542000 0017ac00 2**2 > > /usr/bin/cyglsa.dll > 6 .gnu_deb 00000014 10007000 10007000 00001400 2**2 > > /usr/bin/cygssl-1.0.0.dll > 8 .gnu_deb 0000001c 58fcf000 58fcf000 00059a00 2**2 I checked every /usr/bin/*.dll on my system (which is a lot), and these three, plus cyglsa64.dll (which can only be read by x86_64-w64-mingw32-objdump), are the only ones which show this. I did manage to reproduce this on my machine with openssl, and passing --long-section-names=enable to objcopy does fix this, but why are only these DLLs affected? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 9:02 ` Yaakov @ 2013-01-24 9:28 ` Corinna Vinschen 2013-01-24 9:49 ` marco atzeri 0 siblings, 1 reply; 41+ messages in thread From: Corinna Vinschen @ 2013-01-24 9:28 UTC (permalink / raw) To: cygwin On Jan 24 03:01, Yaakov wrote: > On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote: > > On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > > > On Jan 16 08:15, marco atzeri wrote: > > >> On 1/15/2013 11:03 PM, marco atzeri wrote: > > >>> On 1/15/2013 12:24 PM, Corinna Vinschen wrote: > > > This is a serious bug in objcopy in the current binutils. Given that > > > cygport creates the debug info automatically, we might end up with > > > spuriously broken DLLs in the distro. > > > > we already have some : > > > > /usr/bin/cygcrypto-1.0.0.dll > > 8 .gnu_deb 0000001c 67542000 67542000 0017ac00 2**2 > > > > /usr/bin/cyglsa.dll > > 6 .gnu_deb 00000014 10007000 10007000 00001400 2**2 > > > > /usr/bin/cygssl-1.0.0.dll > > 8 .gnu_deb 0000001c 58fcf000 58fcf000 00059a00 2**2 > > I checked every /usr/bin/*.dll on my system (which is a lot), and these > three, plus cyglsa64.dll (which can only be read by > x86_64-w64-mingw32-objdump), are the only ones which show this. I did > manage to reproduce this on my machine with openssl, and passing > --long-section-names=enable to objcopy does fix this, but why are only > these DLLs affected? Don't forget Marco's DLLs. However, aprt from that it's kind of weird that all of them are built by me, isn't it? I just don't see where the connection is. I'm using your stock Fedora cygwin tools on Fedora 17 to build the Cygwin DLLs. OTOH, the openssl package doesn't support cross builds, so I'm using stock Cygwin distro gcc, binutils, and cygport to build openssl. This is quite puzzeling. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 9:28 ` Corinna Vinschen @ 2013-01-24 9:49 ` marco atzeri 2013-01-24 10:01 ` Corinna Vinschen 2013-01-24 15:56 ` Christopher Faylor 0 siblings, 2 replies; 41+ messages in thread From: marco atzeri @ 2013-01-24 9:49 UTC (permalink / raw) To: cygwin On 1/24/2013 10:27 AM, Corinna Vinschen wrote: > On Jan 24 03:01, Yaakov wrote: >> On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote: >>> On 1/16/2013 1:35 PM, Corinna Vinschen wrote: >>>> On Jan 16 08:15, marco atzeri wrote: >>>>> On 1/15/2013 11:03 PM, marco atzeri wrote: >>>>>> On 1/15/2013 12:24 PM, Corinna Vinschen wrote: >>>> This is a serious bug in objcopy in the current binutils. Given that >>>> cygport creates the debug info automatically, we might end up with >>>> spuriously broken DLLs in the distro. >>> >>> we already have some : >>> >>> /usr/bin/cygcrypto-1.0.0.dll >>> 8 .gnu_deb 0000001c 67542000 67542000 0017ac00 2**2 >>> >>> /usr/bin/cyglsa.dll >>> 6 .gnu_deb 00000014 10007000 10007000 00001400 2**2 >>> >>> /usr/bin/cygssl-1.0.0.dll >>> 8 .gnu_deb 0000001c 58fcf000 58fcf000 00059a00 2**2 >> >> I checked every /usr/bin/*.dll on my system (which is a lot), and these >> three, plus cyglsa64.dll (which can only be read by >> x86_64-w64-mingw32-objdump), are the only ones which show this. I did >> manage to reproduce this on my machine with openssl, and passing >> --long-section-names=enable to objcopy does fix this, but why are only >> these DLLs affected? > > Don't forget Marco's DLLs. However, aprt from that it's kind of weird > that all of them are built by me, isn't it? I just don't see where > the connection is. I'm using your stock Fedora cygwin tools on Fedora 17 > to build the Cygwin DLLs. OTOH, the openssl package doesn't support > cross builds, so I'm using stock Cygwin distro gcc, binutils, and cygport > to build openssl. > > This is quite puzzeling. > > > Corinna > likely complex program have anyway a section with long name The attached patch solves the issue of the short ".gnu_deb" on binutils cvs --- src/binutils/objcopy.c 2013-01-07 18:40:59.000000000 +0100 +++ src_new/binutils/objcopy.c 2013-01-19 22:50:12.447000600 +0100 @@ -3453,6 +3453,7 @@ break; case OPTION_ADD_GNU_DEBUGLINK: + long_section_names = ENABLE ; gnu_debuglink_filename = optarg; break; No clue what is causing rebase to chock. I compared the ".reloc" section of built, stripped and with debug link versions of dict_snowball.dll, and I did not notice any difference (but I am not a PE-COFF expert) all file here: http://matzeri.altervista.org/works/rebase/ Please note that rebase segfaults on dict_snowball.dll the first time but any subsequent rebasing, also with different start address, works without any problem, so it is possible that we had other dll with the same problem but we never noticed Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 9:49 ` marco atzeri @ 2013-01-24 10:01 ` Corinna Vinschen 2013-01-24 10:16 ` marco atzeri 2013-01-25 12:34 ` marco atzeri 2013-01-24 15:56 ` Christopher Faylor 1 sibling, 2 replies; 41+ messages in thread From: Corinna Vinschen @ 2013-01-24 10:01 UTC (permalink / raw) To: cygwin On Jan 24 10:49, marco atzeri wrote: > On 1/24/2013 10:27 AM, Corinna Vinschen wrote: > >On Jan 24 03:01, Yaakov wrote: > >>On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote: > >>>On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > >>>>On Jan 16 08:15, marco atzeri wrote: > >>>>>On 1/15/2013 11:03 PM, marco atzeri wrote: > >>>>>>On 1/15/2013 12:24 PM, Corinna Vinschen wrote: > >>>>This is a serious bug in objcopy in the current binutils. Given that > >>>>cygport creates the debug info automatically, we might end up with > >>>>spuriously broken DLLs in the distro. > >>> > >>>we already have some : > >>> > >>>/usr/bin/cygcrypto-1.0.0.dll > >>> 8 .gnu_deb 0000001c 67542000 67542000 0017ac00 2**2 > >>> > >>>/usr/bin/cyglsa.dll > >>> 6 .gnu_deb 00000014 10007000 10007000 00001400 2**2 > >>> > >>>/usr/bin/cygssl-1.0.0.dll > >>> 8 .gnu_deb 0000001c 58fcf000 58fcf000 00059a00 2**2 > >> > >>I checked every /usr/bin/*.dll on my system (which is a lot), and these > >>three, plus cyglsa64.dll (which can only be read by > >>x86_64-w64-mingw32-objdump), are the only ones which show this. I did > >>manage to reproduce this on my machine with openssl, and passing > >>--long-section-names=enable to objcopy does fix this, but why are only > >>these DLLs affected? > > > >Don't forget Marco's DLLs. However, aprt from that it's kind of weird > >that all of them are built by me, isn't it? I just don't see where > >the connection is. I'm using your stock Fedora cygwin tools on Fedora 17 > >to build the Cygwin DLLs. OTOH, the openssl package doesn't support > >cross builds, so I'm using stock Cygwin distro gcc, binutils, and cygport > >to build openssl. > > > >This is quite puzzeling. > > > > > >Corinna > > > > likely complex program have anyway a section with long name > > The attached patch solves the issue of the short ".gnu_deb" > on binutils cvs > > --- src/binutils/objcopy.c 2013-01-07 18:40:59.000000000 +0100 > +++ src_new/binutils/objcopy.c 2013-01-19 22:50:12.447000600 +0100 > @@ -3453,6 +3453,7 @@ > break; > > case OPTION_ADD_GNU_DEBUGLINK: > + long_section_names = ENABLE ; > gnu_debuglink_filename = optarg; > break; > > No clue what is causing rebase to chock. I compared the > ".reloc" section of > > built, stripped and with debug link versions of dict_snowball.dll, > and I did not notice any difference (but I am not a PE-COFF expert) > all file here: > http://matzeri.altervista.org/works/rebase/ > > Please note that rebase segfaults on dict_snowball.dll the first time > but any subsequent rebasing, also with different start address, > works without any problem, so it is possible that we had other > dll with the same problem but we never noticed I already explained why: The SEGV happens during relocation. The file header has been changed already. If you call the same rebase, it will try to rebase the file to the same new address. If current file base address == requested file base address, rebase will return without performing any action. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 10:01 ` Corinna Vinschen @ 2013-01-24 10:16 ` marco atzeri 2013-01-24 12:09 ` Corinna Vinschen 2013-01-25 12:34 ` marco atzeri 1 sibling, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-24 10:16 UTC (permalink / raw) To: cygwin On 1/24/2013 11:00 AM, Corinna Vinschen wrote: > On Jan 24 10:49, marco atzeri wrote: >> On 1/24/2013 10:27 AM, Corinna Vinschen wrote: >>> On Jan 24 03:01, Yaakov wrote: >>>> On Wed, 16 Jan 2013 14:38:43 +0100, marco atzeri wrote: >>>>> On 1/16/2013 1:35 PM, Corinna Vinschen wrote: >>>>>> On Jan 16 08:15, marco atzeri wrote: >>>>>>> On 1/15/2013 11:03 PM, marco atzeri wrote: >>>>>>>> On 1/15/2013 12:24 PM, Corinna Vinschen wrote: >>>>>> This is a serious bug in objcopy in the current binutils. Given that >>>>>> cygport creates the debug info automatically, we might end up with >>>>>> spuriously broken DLLs in the distro. >>>>> >>>>> we already have some : >>>>> >>>>> /usr/bin/cygcrypto-1.0.0.dll >>>>> 8 .gnu_deb 0000001c 67542000 67542000 0017ac00 2**2 >>>>> >>>>> /usr/bin/cyglsa.dll >>>>> 6 .gnu_deb 00000014 10007000 10007000 00001400 2**2 >>>>> >>>>> /usr/bin/cygssl-1.0.0.dll >>>>> 8 .gnu_deb 0000001c 58fcf000 58fcf000 00059a00 2**2 >>>> >>>> I checked every /usr/bin/*.dll on my system (which is a lot), and these >>>> three, plus cyglsa64.dll (which can only be read by >>>> x86_64-w64-mingw32-objdump), are the only ones which show this. I did >>>> manage to reproduce this on my machine with openssl, and passing >>>> --long-section-names=enable to objcopy does fix this, but why are only >>>> these DLLs affected? >>> >>> Don't forget Marco's DLLs. However, aprt from that it's kind of weird >>> that all of them are built by me, isn't it? I just don't see where >>> the connection is. I'm using your stock Fedora cygwin tools on Fedora 17 >>> to build the Cygwin DLLs. OTOH, the openssl package doesn't support >>> cross builds, so I'm using stock Cygwin distro gcc, binutils, and cygport >>> to build openssl. >>> >>> This is quite puzzeling. >>> >>> >>> Corinna >>> >> >> likely complex program have anyway a section with long name >> >> The attached patch solves the issue of the short ".gnu_deb" >> on binutils cvs >> >> --- src/binutils/objcopy.c 2013-01-07 18:40:59.000000000 +0100 >> +++ src_new/binutils/objcopy.c 2013-01-19 22:50:12.447000600 +0100 >> @@ -3453,6 +3453,7 @@ >> break; >> >> case OPTION_ADD_GNU_DEBUGLINK: >> + long_section_names = ENABLE ; >> gnu_debuglink_filename = optarg; >> break; >> >> No clue what is causing rebase to chock. I compared the >> ".reloc" section of >> >> built, stripped and with debug link versions of dict_snowball.dll, >> and I did not notice any difference (but I am not a PE-COFF expert) >> all file here: >> http://matzeri.altervista.org/works/rebase/ >> >> Please note that rebase segfaults on dict_snowball.dll the first time >> but any subsequent rebasing, also with different start address, >> works without any problem, so it is possible that we had other >> dll with the same problem but we never noticed > > I already explained why: The SEGV happens during relocation. > The file header has been changed already. If you call the > same rebase, it will try to rebase the file to the same new > address. If current file base address == requested file base > address, rebase will return without performing any action. I was not clear. Also rebasing with a different address make no difference > Corinna > Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 10:16 ` marco atzeri @ 2013-01-24 12:09 ` Corinna Vinschen 2013-01-24 12:35 ` marco atzeri 0 siblings, 1 reply; 41+ messages in thread From: Corinna Vinschen @ 2013-01-24 12:09 UTC (permalink / raw) To: cygwin On Jan 24 11:16, marco atzeri wrote: > On 1/24/2013 11:00 AM, Corinna Vinschen wrote: > >On Jan 24 10:49, marco atzeri wrote: > >>Please note that rebase segfaults on dict_snowball.dll the first time > >>but any subsequent rebasing, also with different start address, > >>works without any problem, so it is possible that we had other > >>dll with the same problem but we never noticed > > > >I already explained why: The SEGV happens during relocation. > >The file header has been changed already. If you call the > >same rebase, it will try to rebase the file to the same new > >address. If current file base address == requested file base > >address, rebase will return without performing any action. > > I was not clear. > Also rebasing with a different address make no difference It does for me: $ rebase -b 0x40000000 dict_snowball.dll Segmentation fault $ rebase -b 0x50000000 dict_snowball.dll Segmentation fault $ rebase -b 0x40000000 dict_snowball.dll Segmentation fault $ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 12:09 ` Corinna Vinschen @ 2013-01-24 12:35 ` marco atzeri 2013-01-24 14:12 ` Corinna Vinschen 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-24 12:35 UTC (permalink / raw) To: cygwin On 1/24/2013 1:08 PM, Corinna Vinschen wrote: >> I was not clear. >> Also rebasing with a different address make no difference > > It does for me: > > $ rebase -b 0x40000000 dict_snowball.dll > Segmentation fault > $ rebase -b 0x50000000 dict_snowball.dll > Segmentation fault > $ rebase -b 0x40000000 dict_snowball.dll > Segmentation fault > $ same here, but with -O it works differently $ rebase -O -b 0x60000000 dict_snowball.dll Segmentation fault (core dumped) $ rebase -O -b 0x40000000 dict_snowball.dll $ rebase -O -b 0x50000000 dict_snowball.dll What I am missing ? > > Corinna Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 12:35 ` marco atzeri @ 2013-01-24 14:12 ` Corinna Vinschen 0 siblings, 0 replies; 41+ messages in thread From: Corinna Vinschen @ 2013-01-24 14:12 UTC (permalink / raw) To: cygwin On Jan 24 13:34, marco atzeri wrote: > On 1/24/2013 1:08 PM, Corinna Vinschen wrote: > > >>I was not clear. > >>Also rebasing with a different address make no difference > > > >It does for me: > > > > $ rebase -b 0x40000000 dict_snowball.dll > > Segmentation fault > > $ rebase -b 0x50000000 dict_snowball.dll > > Segmentation fault > > $ rebase -b 0x40000000 dict_snowball.dll > > Segmentation fault > > $ > > same here, but with -O it works differently > > $ rebase -O -b 0x60000000 dict_snowball.dll > Segmentation fault (core dumped) > > $ rebase -O -b 0x40000000 dict_snowball.dll > > $ rebase -O -b 0x50000000 dict_snowball.dll > > What I am missing ? -O, --oblivious Do not change any files already in the database and do not record any changes to the database. (Implies -s). ^^^^^^^^^^^^^ Maybe this. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 10:01 ` Corinna Vinschen 2013-01-24 10:16 ` marco atzeri @ 2013-01-25 12:34 ` marco atzeri 2013-01-25 13:20 ` Kai Tietz 2013-01-25 13:22 ` Kai Tietz 1 sibling, 2 replies; 41+ messages in thread From: marco atzeri @ 2013-01-25 12:34 UTC (permalink / raw) To: cygwin On 1/24/2013 11:00 AM, Corinna Vinschen wrote: > I already explained why: The SEGV happens during relocation. > The file header has been changed already. If you call the > same rebase, it will try to rebase the file to the same new > address. If current file base address == requested file base > address, rebase will return without performing any action. > Hi Corinna, I would like your opinion on this .reloc strange issue of dict_snowball, as I have the impression I found the root cause. The relocation table looks the same for the the build, strip and with debug link dll's $ objdump -p dict_snowball-strip.dll |grep Virtual |wc -l 130 $ objdump -p dict_snowball-build.dll |grep Virtual |wc -l 130 $ objdump -p dict_snowball-debug.dll |grep Virtual |wc -l 130 but some some sections does not exist anymore after the strip, so the .reloc table should be smaller after strip. $ objdump -p dict_snowball-build.dll |grep Virtual Virtual Address: 00001000 Chunk size 72 (0x48) Number of fixups 32 [cut] Virtual Address: 0002e000 Chunk size 340 (0x154) Number of fixups 166 [this area points to the .debug_* sections, starting with .debug_info, up to .debug_loc] Virtual Address: 0003b000 Chunk size 96 (0x60) Number of fixups 44 Virtual Address: 0003f000 Chunk size 12 (0xc) Number of fixups 2 .... Virtual Address: 00098000 Chunk size 20 (0x14) Number of fixups 6 Virtual Address: 0009a000 Chunk size 12 (0xc) Number of fixups 2 $ objdump -h dict_snowball-build.dll dict_snowball-build.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 67ec1000 67ec1000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5 ALLOC 3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .debug_aranges 00000560 67efb000 67efb000 00036c00 2**0 CONTENTS, READONLY, DEBUGGING 7 .debug_pubnames 00001112 67efc000 67efc000 00037200 2**0 CONTENTS, READONLY, DEBUGGING 8 .debug_pubtypes 00000f49 67efe000 67efe000 00038400 2**0 CONTENTS, READONLY, DEBUGGING 9 .debug_info 00048851 67eff000 67eff000 00039400 2**0 CONTENTS, READONLY, DEBUGGING 10 .debug_abbrev 000050a3 67f48000 67f48000 00081e00 2**0 CONTENTS, READONLY, DEBUGGING 11 .debug_line 000078a3 67f4e000 67f4e000 00087000 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_frame 00002114 67f56000 67f56000 0008ea00 2**2 CONTENTS, READONLY, DEBUGGING 13 .debug_str 00000664 67f59000 67f59000 00090c00 2**0 CONTENTS, READONLY, DEBUGGING 14 .debug_loc 000170a4 67f5a000 67f5a000 00091400 2**0 CONTENTS, READONLY, DEBUGGING 15 .debug_ranges 0000f3a0 67f72000 67f72000 000a8600 2**0 CONTENTS, READONLY, DEBUGGING $ objdump -h dict_snowball-strip.dll dict_snowball-strip.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 67ec1000 67ec1000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5 ALLOC 3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Questions: - Is it anomalous to have a .reloc portion addressing the debug_* sections (so the original build file is broken) - or should strip recognize and remove reloc portion not anymore relevant ? rebase is choking on this portion of the .reloc table > > Corinna > Thansk in advance Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-25 12:34 ` marco atzeri @ 2013-01-25 13:20 ` Kai Tietz 2013-01-25 15:01 ` Corinna Vinschen 2013-01-25 13:22 ` Kai Tietz 1 sibling, 1 reply; 41+ messages in thread From: Kai Tietz @ 2013-01-25 13:20 UTC (permalink / raw) To: cygwin 2013/1/25 marco atzeri <marco.atzeri@gmail.com>: > On 1/24/2013 11:00 AM, Corinna Vinschen wrote: > >> I already explained why: The SEGV happens during relocation. >> The file header has been changed already. If you call the >> same rebase, it will try to rebase the file to the same new >> address. If current file base address == requested file base >> address, rebase will return without performing any action. >> > > Hi Corinna, > I would like your opinion on this .reloc strange issue of > dict_snowball, as I have the impression I found the root cause. > > The relocation table looks the same for the the build, strip and > with debug link dll's > > $ objdump -p dict_snowball-strip.dll |grep Virtual |wc -l > 130 > > $ objdump -p dict_snowball-build.dll |grep Virtual |wc -l > 130 > > $ objdump -p dict_snowball-debug.dll |grep Virtual |wc -l > 130 > > but some some sections does not exist anymore after the strip, > so the .reloc table should be smaller after strip. > > $ objdump -p dict_snowball-build.dll |grep Virtual > Virtual Address: 00001000 Chunk size 72 (0x48) Number of fixups 32 > > [cut] > > Virtual Address: 0002e000 Chunk size 340 (0x154) Number of fixups 166 > > [this area points to the .debug_* sections, > starting with .debug_info, up to .debug_loc] > > Virtual Address: 0003b000 Chunk size 96 (0x60) Number of fixups 44 > Virtual Address: 0003f000 Chunk size 12 (0xc) Number of fixups 2 > .... > Virtual Address: 00098000 Chunk size 20 (0x14) Number of fixups 6 > Virtual Address: 0009a000 Chunk size 12 (0xc) Number of fixups 2 > > > $ objdump -h dict_snowball-build.dll > > dict_snowball-build.dll: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00016808 67ec1000 67ec1000 00000400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA > 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 > CONTENTS, ALLOC, LOAD, DATA > 2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5 > ALLOC > 3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2 > CONTENTS, ALLOC, LOAD, DATA > 5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 .debug_aranges 00000560 67efb000 67efb000 00036c00 2**0 > CONTENTS, READONLY, DEBUGGING > 7 .debug_pubnames 00001112 67efc000 67efc000 00037200 2**0 > CONTENTS, READONLY, DEBUGGING > 8 .debug_pubtypes 00000f49 67efe000 67efe000 00038400 2**0 > CONTENTS, READONLY, DEBUGGING > 9 .debug_info 00048851 67eff000 67eff000 00039400 2**0 > CONTENTS, READONLY, DEBUGGING > 10 .debug_abbrev 000050a3 67f48000 67f48000 00081e00 2**0 > CONTENTS, READONLY, DEBUGGING > 11 .debug_line 000078a3 67f4e000 67f4e000 00087000 2**0 > CONTENTS, READONLY, DEBUGGING > 12 .debug_frame 00002114 67f56000 67f56000 0008ea00 2**2 > CONTENTS, READONLY, DEBUGGING > 13 .debug_str 00000664 67f59000 67f59000 00090c00 2**0 > CONTENTS, READONLY, DEBUGGING > 14 .debug_loc 000170a4 67f5a000 67f5a000 00091400 2**0 > CONTENTS, READONLY, DEBUGGING > 15 .debug_ranges 0000f3a0 67f72000 67f72000 000a8600 2**0 > CONTENTS, READONLY, DEBUGGING > > $ objdump -h dict_snowball-strip.dll > > dict_snowball-strip.dll: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00016808 67ec1000 67ec1000 00000400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA > 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 > CONTENTS, ALLOC, LOAD, DATA > 2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5 > ALLOC > 3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2 > CONTENTS, ALLOC, LOAD, DATA > 5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > > > Questions: > - Is it anomalous to have a .reloc portion addressing the > debug_* sections (so the original build file is broken) > - or should strip recognize and remove reloc portion not > anymore relevant ? > > rebase is choking on this portion of the .reloc table > >> >> Corinna >> > > Thansk in advance > Marco Well, here are my 2-cents about that issue. In general it is a flaw to have an base-relocation in debug-section, as this means such a section can't be moved into a separate debug-file anymore, due that has no relocation-information. Nevertheless it would be good, if objcopy gets adjusted to eliminated base-relocations of stripped sections. Kai -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-25 13:20 ` Kai Tietz @ 2013-01-25 15:01 ` Corinna Vinschen 2013-01-25 15:12 ` marco atzeri 0 siblings, 1 reply; 41+ messages in thread From: Corinna Vinschen @ 2013-01-25 15:01 UTC (permalink / raw) To: cygwin On Jan 25 14:19, Kai Tietz wrote: > 2013/1/25 marco atzeri <marco.atzeri@gmail.com>: > > On 1/24/2013 11:00 AM, Corinna Vinschen wrote: > > > >> I already explained why: The SEGV happens during relocation. > >> The file header has been changed already. If you call the > >> same rebase, it will try to rebase the file to the same new > >> address. If current file base address == requested file base > >> address, rebase will return without performing any action. > >> > > > > Hi Corinna, > > I would like your opinion on this .reloc strange issue of > > dict_snowball, as I have the impression I found the root cause. > > [...] > > Questions: > > - Is it anomalous to have a .reloc portion addressing the > > debug_* sections (so the original build file is broken) > > - or should strip recognize and remove reloc portion not > > anymore relevant ? > > > > rebase is choking on this portion of the .reloc table > > > >> > >> Corinna > >> > > > > Thansk in advance > > Marco > > Well, here are my 2-cents about that issue. In general it is a flaw > to have an base-relocation in debug-section, as this means such a > section can't be moved into a separate debug-file anymore, due that > has no relocation-information. > Nevertheless it would be good, if objcopy gets adjusted to eliminated > base-relocations of stripped sections. But the tool generating these debug relocs is gas, isn't it? Why on earth does it do that?!? I still think rebase is not to blame here. It has to assume that the relocation info is correct, doesn't it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-25 15:01 ` Corinna Vinschen @ 2013-01-25 15:12 ` marco atzeri 2013-01-26 6:32 ` Reini Urban 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-25 15:12 UTC (permalink / raw) To: cygwin On 1/25/2013 4:00 PM, Corinna Vinschen wrote: > On Jan 25 14:19, Kai Tietz wrote: >> 2013/1/25 marco atzeri <marco.atzeri@gmail.com>: >>> On 1/24/2013 11:00 AM, Corinna Vinschen wrote: >>> >>>> I already explained why: The SEGV happens during relocation. >>>> The file header has been changed already. If you call the >>>> same rebase, it will try to rebase the file to the same new >>>> address. If current file base address == requested file base >>>> address, rebase will return without performing any action. >>>> >>> >>> Hi Corinna, >>> I would like your opinion on this .reloc strange issue of >>> dict_snowball, as I have the impression I found the root cause. >>> [...] >>> Questions: >>> - Is it anomalous to have a .reloc portion addressing the >>> debug_* sections (so the original build file is broken) >>> - or should strip recognize and remove reloc portion not >>> anymore relevant ? >>> >>> rebase is choking on this portion of the .reloc table >>> >>>> >>>> Corinna >>>> >>> >>> Thansk in advance >>> Marco >> >> Well, here are my 2-cents about that issue. In general it is a flaw >> to have an base-relocation in debug-section, as this means such a >> section can't be moved into a separate debug-file anymore, due that >> has no relocation-information. >> Nevertheless it would be good, if objcopy gets adjusted to eliminated >> base-relocations of stripped sections. > > But the tool generating these debug relocs is gas, isn't it? Why > on earth does it do that?!? > > I still think rebase is not to blame here. It has to assume that > the relocation info is correct, doesn't it? rebase is not to blame. I agree ;-) Someone else is incorrectly managing the reloc table, and also objcopy seems innocent ... Postgresql dll's are built in this way: gcc -ggdb -O2 -pipe -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/build=/usr/src/debug/postgresql-9.2.2-1 -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2=/usr/src/debug/postgresql-9.2.2-1 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball/libstemmer -I../../../src/include -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include -c -o dict_snowball.o /pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/backend/snowball/dict_snowball.c dllwrap -o dict_snowball.dll --dllname dict_snowball.dll --def libdict_snowballdll.def dict_snowball.o api.o utilities.o stem_ISO_8859_1_danish.o stem_ISO_8859_1_dutch.o stem_ISO_8859_1_english.o stem_ISO_8859_1_finnish.o stem_ISO_8859_1_french.o stem_ISO_8859_1_german.o stem_ISO_8859_1_hungarian.o stem_ISO_8859_1_italian.o stem_ISO_8859_1_norwegian.o stem_ISO_8859_1_porter.o stem_ISO_8859_1_portuguese.o stem_ISO_8859_1_spanish.o stem_ISO_8859_1_swedish.o stem_ISO_8859_2_romanian.o stem_KOI8_R_russian.o stem_UTF_8_danish.o stem_UTF_8_dutch.o stem_UTF_8_english.o stem_UTF_8_finnish.o stem_UTF_8_french.o stem_UTF_8_german.o stem_UTF_8_hungarian.o stem_UTF_8_italian.o stem_UTF_8_norwegian.o stem_UTF_8_porter.o stem_UTF_8_portuguese.o stem_UTF_8_romanian.o stem_UTF_8_russian.o stem_UTF_8_spanish.o stem_UTF_8_swedish.o stem_UTF_8_turkish.o -L../../../src/port -Wl,--allow-multiple-definition -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed -L../../../src/backend -lpostgres > Corinna Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-25 15:12 ` marco atzeri @ 2013-01-26 6:32 ` Reini Urban 2013-01-26 7:53 ` marco atzeri 0 siblings, 1 reply; 41+ messages in thread From: Reini Urban @ 2013-01-26 6:32 UTC (permalink / raw) To: cygwin On Fri, Jan 25, 2013 at 8:11 AM, marco atzeri wrote: > On 1/25/2013 4:00 PM, Corinna Vinschen wrote: >> >> On Jan 25 14:19, Kai Tietz wrote: >>> >>> 2013/1/25 marco atzeri <marco.atzeri@gmail.com>: >>>> >>>> On 1/24/2013 11:00 AM, Corinna Vinschen wrote: >>>> >>>>> I already explained why: The SEGV happens during relocation. >>>>> The file header has been changed already. If you call the >>>>> same rebase, it will try to rebase the file to the same new >>>>> address. If current file base address == requested file base >>>>> address, rebase will return without performing any action. >>>>> >>>> >>>> Hi Corinna, >>>> I would like your opinion on this .reloc strange issue of >>>> dict_snowball, as I have the impression I found the root cause. >>>> [...] >>>> Questions: >>>> - Is it anomalous to have a .reloc portion addressing the >>>> debug_* sections (so the original build file is broken) >>>> - or should strip recognize and remove reloc portion not >>>> anymore relevant ? >>>> >>>> rebase is choking on this portion of the .reloc table >>>> >>>>> >>>>> Corinna >>>>> >>>> >>>> Thansk in advance >>>> Marco >>> >>> >>> Well, here are my 2-cents about that issue. In general it is a flaw >>> to have an base-relocation in debug-section, as this means such a >>> section can't be moved into a separate debug-file anymore, due that >>> has no relocation-information. >>> Nevertheless it would be good, if objcopy gets adjusted to eliminated >>> base-relocations of stripped sections. >> >> >> But the tool generating these debug relocs is gas, isn't it? Why >> on earth does it do that?!? >> >> I still think rebase is not to blame here. It has to assume that >> the relocation info is correct, doesn't it? > > > rebase is not to blame. I agree ;-) > Someone else is incorrectly managing the reloc table, > and also objcopy seems innocent ... > > Postgresql dll's are built in this way: My strong guess is dllwrap. No other packages uses the ancient dllwrap anymore. I tried to get rid of it, but got stuck somewhere else. > gcc -ggdb -O2 -pipe > -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/build=/usr/src/debug/postgresql-9.2.2-1 > -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2=/usr/src/debug/postgresql-9.2.2-1 > -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -Wendif-labels -Wmissing-format-attribute -Wformat-security > -fno-strict-aliasing -fwrapv -fexcess-precision=standard > -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball > -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball/libstemmer > -I../../../src/include > -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include > -c -o dict_snowball.o > /pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/backend/snowball/dict_snowball.c > > > dllwrap -o dict_snowball.dll --dllname dict_snowball.dll --def > libdict_snowballdll.def dict_snowball.o api.o utilities.o > stem_ISO_8859_1_danish.o stem_ISO_8859_1_dutch.o stem_ISO_8859_1_english.o > stem_ISO_8859_1_finnish.o stem_ISO_8859_1_french.o stem_ISO_8859_1_german.o > stem_ISO_8859_1_hungarian.o stem_ISO_8859_1_italian.o > stem_ISO_8859_1_norwegian.o stem_ISO_8859_1_porter.o > stem_ISO_8859_1_portuguese.o stem_ISO_8859_1_spanish.o > stem_ISO_8859_1_swedish.o stem_ISO_8859_2_romanian.o stem_KOI8_R_russian.o > stem_UTF_8_danish.o stem_UTF_8_dutch.o stem_UTF_8_english.o > stem_UTF_8_finnish.o stem_UTF_8_french.o stem_UTF_8_german.o > stem_UTF_8_hungarian.o stem_UTF_8_italian.o stem_UTF_8_norwegian.o > stem_UTF_8_porter.o stem_UTF_8_portuguese.o stem_UTF_8_romanian.o > stem_UTF_8_russian.o stem_UTF_8_spanish.o stem_UTF_8_swedish.o > stem_UTF_8_turkish.o -L../../../src/port -Wl,--allow-multiple-definition > -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed > -L../../../src/backend -lpostgres -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-26 6:32 ` Reini Urban @ 2013-01-26 7:53 ` marco atzeri 2013-01-29 22:30 ` Reini Urban 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-26 7:53 UTC (permalink / raw) To: cygwin On 1/26/2013 7:32 AM, Reini Urban wrote: >> >> >> rebase is not to blame. I agree ;-) >> Someone else is incorrectly managing the reloc table, >> and also objcopy seems innocent ... >> >> Postgresql dll's are built in this way: > > My strong guess is dllwrap. > No other packages uses the ancient dllwrap anymore. > I tried to get rid of it, but got stuck somewhere else. > Hi Reini, I agree dllwrap seems the coolprit, and "gcc -shared" seems a better alternative , at least on a single test with this dll. I looked on the postgresql makefiles and it is a big mess to replace dllwrap; upstream is crazy, they crippled configure forcing a specific version and refusing to use Automake. Autoconf+Automake will be a much cleaner approach, and will allow to avoid at all the platform checks. Could you make another check on 9.2.2 package before a new RFU http://matzeri.altervista.org/cygwin-1.7/postgresql/ Thanks in advance Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-26 7:53 ` marco atzeri @ 2013-01-29 22:30 ` Reini Urban 2013-01-30 16:46 ` Andrew Dunstan 0 siblings, 1 reply; 41+ messages in thread From: Reini Urban @ 2013-01-29 22:30 UTC (permalink / raw) To: cygwin; +Cc: Andrew Dunstan On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote: > On 1/26/2013 7:32 AM, Reini Urban wrote: >>> rebase is not to blame. I agree ;-) >>> Someone else is incorrectly managing the reloc table, >>> and also objcopy seems innocent ... >>> >>> Postgresql dll's are built in this way: >> >> >> My strong guess is dllwrap. >> No other packages uses the ancient dllwrap anymore. >> I tried to get rid of it, but got stuck somewhere else. >> > > Hi Reini, > I agree dllwrap seems the coolprit, and "gcc -shared" > seems a better alternative, at least on a single test with this dll. > > I looked on the postgresql makefiles and it is a big mess to > replace dllwrap; upstream is crazy, they crippled configure > forcing a specific version and refusing to use Automake. > > Autoconf+Automake will be a much cleaner approach, and will > allow to avoid at all the platform checks. Yes, I had the same impression but it is unfortunately not realistic. I worked against dllwrap removal but got stuck somewhere. When I find my old patches I'll hand it over to you. Just came back from holidays. > Could you make another check on 9.2.2 package before a new RFU > http://matzeri.altervista.org/cygwin-1.7/postgresql/ Sorry, holidays. Gold star please. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-29 22:30 ` Reini Urban @ 2013-01-30 16:46 ` Andrew Dunstan 2013-01-30 17:03 ` marco atzeri 2013-03-04 20:01 ` Andrew Dunstan 0 siblings, 2 replies; 41+ messages in thread From: Andrew Dunstan @ 2013-01-30 16:46 UTC (permalink / raw) To: Reini Urban; +Cc: cygwin On 01/29/2013 05:30 PM, Reini Urban wrote: > On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote: >> On 1/26/2013 7:32 AM, Reini Urban wrote: >>>> rebase is not to blame. I agree ;-) >>>> Someone else is incorrectly managing the reloc table, >>>> and also objcopy seems innocent ... >>>> >>>> Postgresql dll's are built in this way: >>> >>> My strong guess is dllwrap. >>> No other packages uses the ancient dllwrap anymore. >>> I tried to get rid of it, but got stuck somewhere else. >>> >> Hi Reini, >> I agree dllwrap seems the coolprit, and "gcc -shared" >> seems a better alternative, at least on a single test with this dll. >> >> I looked on the postgresql makefiles and it is a big mess to >> replace dllwrap; upstream is crazy, they crippled configure >> forcing a specific version and refusing to use Automake. >> >> Autoconf+Automake will be a much cleaner approach, and will >> allow to avoid at all the platform checks. > Yes, I had the same impression but it is unfortunately not realistic. > I worked against dllwrap removal but got stuck somewhere. > When I find my old patches I'll hand it over to you. Just came back > from holidays. > > I will be very happy to work with you to remove the use of dllwrap etc. for cygwin. Since I'm a Postgres committer (and the only one interested in Cygwin at all) I'm in a good position to do this. I believe the Postgres project had problems in the past with automake and made a decision long ago not to use it, so we're not going down that route. However, that surely need not stop us from getting this working. cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-30 16:46 ` Andrew Dunstan @ 2013-01-30 17:03 ` marco atzeri 2013-03-04 20:01 ` Andrew Dunstan 1 sibling, 0 replies; 41+ messages in thread From: marco atzeri @ 2013-01-30 17:03 UTC (permalink / raw) To: cygwin On 1/30/2013 5:46 PM, Andrew Dunstan wrote: > >>> Autoconf+Automake will be a much cleaner approach, and will >>> allow to avoid at all the platform checks. >> Yes, I had the same impression but it is unfortunately not realistic. >> I worked against dllwrap removal but got stuck somewhere. >> When I find my old patches I'll hand it over to you. Just came back >> from holidays. > > I will be very happy to work with you to remove the use of dllwrap etc. > for cygwin. Since I'm a Postgres committer (and the only one interested > in Cygwin at all) I'm in a good position to do this. I believe the > Postgres project had problems in the past with automake and made a > decision long ago not to use it, so we're not going down that route. > However, that surely need not stop us from getting this working. > > cheers > > andrew > Hi Andrew, I see most of the other platforms are using "gcc --shared" instead of dllwrap. I suspect that just switching away from dllwrap will improve the situation. Postgresql is the only package, where I was forced to remove debug information to have a running binary. I will very happy to work on this change Marco (current maintainer of Postgresql package) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-30 16:46 ` Andrew Dunstan 2013-01-30 17:03 ` marco atzeri @ 2013-03-04 20:01 ` Andrew Dunstan 2013-03-04 21:30 ` marco atzeri 1 sibling, 1 reply; 41+ messages in thread From: Andrew Dunstan @ 2013-03-04 20:01 UTC (permalink / raw) To: Reini Urban; +Cc: cygwin On 01/30/2013 11:46 AM, Andrew Dunstan wrote: > > On 01/29/2013 05:30 PM, Reini Urban wrote: >> On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote: >>> On 1/26/2013 7:32 AM, Reini Urban wrote: >>>>> rebase is not to blame. I agree ;-) >>>>> Someone else is incorrectly managing the reloc table, >>>>> and also objcopy seems innocent ... >>>>> >>>>> Postgresql dll's are built in this way: >>>> >>>> My strong guess is dllwrap. >>>> No other packages uses the ancient dllwrap anymore. >>>> I tried to get rid of it, but got stuck somewhere else. >>>> >>> Hi Reini, >>> I agree dllwrap seems the coolprit, and "gcc -shared" >>> seems a better alternative, at least on a single test with this dll. >>> >>> I looked on the postgresql makefiles and it is a big mess to >>> replace dllwrap; upstream is crazy, they crippled configure >>> forcing a specific version and refusing to use Automake. >>> >>> Autoconf+Automake will be a much cleaner approach, and will >>> allow to avoid at all the platform checks. >> Yes, I had the same impression but it is unfortunately not realistic. >> I worked against dllwrap removal but got stuck somewhere. >> When I find my old patches I'll hand it over to you. Just came back >> from holidays. >> >> > > > I will be very happy to work with you to remove the use of dllwrap > etc. for cygwin. Since I'm a Postgres committer (and the only one > interested in Cygwin at all) I'm in a good position to do this. I > believe the Postgres project had problems in the past with automake > and made a decision long ago not to use it, so we're not going down > that route. However, that surely need not stop us from getting this > working. > > I have not heard a word on this in the 5 weeks or so since it was sent. Are you guys interested in fixing this or not? cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-03-04 20:01 ` Andrew Dunstan @ 2013-03-04 21:30 ` marco atzeri 2013-03-04 21:41 ` Andrew Dunstan 2013-03-04 22:32 ` Andrew Dunstan 0 siblings, 2 replies; 41+ messages in thread From: marco atzeri @ 2013-03-04 21:30 UTC (permalink / raw) To: cygwin, andrew [-- Attachment #1: Type: text/plain, Size: 526 bytes --] On 3/4/2013 9:00 PM, Andrew Dunstan wrote: > > I have not heard a word on this in the 5 weeks or so since it was sent. > Are you guys interested in fixing this or not? yes Andrew, I am working on it, unfortunately this Makefile spaghetti is not nice to handle probably 90% is working now, but I just found that postgres.exe is incomplete attached current patch for my trial src/backend/Makefile needs some works for postgres.exe and libpostgres.a that I hope is the only missing bit > > cheers > > andrew Regards Marco [-- Attachment #2: post.patch --] [-- Type: text/plain, Size: 7696 bytes --] --- origsrc/postgresql-9.2.3/src/Makefile.shlib 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/Makefile.shlib 2013-03-04 11:56:36.238271500 +0100 @@ -284,6 +284,7 @@ endif ifeq ($(PORTNAME), cygwin) + LINK.shared = $(CC) -shared ifdef SO_MAJOR_VERSION shlib = cyg$(NAME)$(DLSUFFIX) endif @@ -374,6 +375,16 @@ # If SHLIB_EXPORTS is set, the rules below will build a .def file from # that. Else we build a temporary one here. +ifeq ($(PORTNAME), cygwin) +$(shlib): $(OBJS) | $(SHLIB_PREREQS) + $(CC) $(CFLAGS) -shared -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE) + +$(stlib): $(OBJS) | $(SHLIB_PREREQS) + $(LINK.static) $@ $^ + $(RANLIB) $@ + + +else ifeq (,$(SHLIB_EXPORTS)) DLL_DEFFILE = lib$(NAME)dll.def exports_file = $(DLL_DEFFILE) @@ -390,6 +401,7 @@ $(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS) $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE) --output-lib $@ +endif # PORTNAME == cygwin endif # PORTNAME == cygwin || PORTNAME == win32 endif # enable_shared --- origsrc/postgresql-9.2.3/src/backend/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/backend/Makefile 2013-03-04 11:18:03.048271500 +0100 @@ -47,7 +47,6 @@ all: submake-libpgport submake-schemapg postgres $(POSTGRES_IMP) -ifneq ($(PORTNAME), cygwin) ifneq ($(PORTNAME), win32) ifneq ($(PORTNAME), aix) @@ -56,24 +55,6 @@ endif endif -endif - -ifeq ($(PORTNAME), cygwin) - -postgres: $(OBJS) postgres.def libpostgres.a - $(DLLTOOL) --dllname $@$(X) --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -o $@$(X) -Wl,--base-file,$@.base $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - $(DLLTOOL) --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -Wl,--stack,$(WIN32_STACK_RLIMIT) -o $@$(X) $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - rm -f $@.exp $@.base - -postgres.def: $(OBJS) - $(DLLTOOL) --export-all --output-def $@ $(call expand_subsys,$^) - -libpostgres.a: postgres.def - $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ - -endif # cygwin ifeq ($(PORTNAME), win32) LIBS += -lsecur32 @@ -210,7 +191,7 @@ install: all installdirs install-bin ifeq ($(PORTNAME), cygwin) ifeq ($(MAKE_DLL), true) - $(INSTALL_DATA) libpostgres.a '$(DESTDIR)$(libdir)/libpostgres.a' +# $(INSTALL_DATA) libpostgres.a '$(DESTDIR)$(libdir)/libpostgres.a' endif endif ifeq ($(PORTNAME), win32) --- origsrc/postgresql-9.2.3/src/bin/pg_basebackup/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/bin/pg_basebackup/Makefile 2013-03-04 11:12:39.523271500 +0100 @@ -16,6 +16,8 @@ top_builddir = ../../.. include $(top_builddir)/src/Makefile.global +LIBS += $(LIBS) $(LDAP_LIBS_BE) + override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) OBJS=receivelog.o streamutil.o $(WIN32RES) --- origsrc/postgresql-9.2.3/src/bin/pg_ctl/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/bin/pg_ctl/Makefile 2013-03-04 11:04:16.268271500 +0100 @@ -23,7 +23,7 @@ all: pg_ctl pg_ctl: $(OBJS) | submake-libpq submake-libpgport - $(CC) $(CFLAGS) $(OBJS) $(libpq_pgport) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X) + $(CC) $(CFLAGS) $(OBJS) $(libpq_pgport) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X) $(LDAP_LIBS_BE) install: all installdirs $(INSTALL_PROGRAM) pg_ctl$(X) '$(DESTDIR)$(bindir)/pg_ctl$(X)' --- origsrc/postgresql-9.2.3/src/bin/pg_dump/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/bin/pg_dump/Makefile 2013-03-04 11:10:40.034271500 +0100 @@ -12,10 +12,13 @@ PGFILEDESC = "pg_dump/pg_restore/pg_dumpall - backup and restore PostgreSQL databases" PGAPPICON=win32 + subdir = src/bin/pg_dump top_builddir = ../../.. include $(top_builddir)/src/Makefile.global +LIBS += $(LIBS) $(LDAP_LIBS_BE) + override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) OBJS= pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o \ @@ -30,7 +33,7 @@ all: pg_dump pg_restore pg_dumpall pg_dump: pg_dump.o common.o pg_dump_sort.o $(OBJS) $(KEYWRDOBJS) | submake-libpq submake-libpgport - $(CC) $(CFLAGS) pg_dump.o common.o pg_dump_sort.o $(KEYWRDOBJS) $(OBJS) $(libpq_pgport) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X) + $(CC) $(CFLAGS) pg_dump.o common.o pg_dump_sort.o $(KEYWRDOBJS) $(OBJS) $(libpq_pgport) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X) pg_restore: pg_restore.o $(OBJS) $(KEYWRDOBJS) | submake-libpq submake-libpgport $(CC) $(CFLAGS) pg_restore.o $(KEYWRDOBJS) $(OBJS) $(libpq_pgport) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X) --- origsrc/postgresql-9.2.3/src/bin/psql/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/bin/psql/Makefile 2013-03-04 11:11:05.859271500 +0100 @@ -16,6 +16,8 @@ top_builddir = ../../.. include $(top_builddir)/src/Makefile.global +LIBS += $(LIBS) $(LDAP_LIBS_BE) + REFDOCDIR= $(top_srcdir)/doc/src/sgml/ref override CPPFLAGS := -I. -I$(srcdir) -I$(libpq_srcdir) -I$(top_srcdir)/src/bin/pg_dump $(CPPFLAGS) --- origsrc/postgresql-9.2.3/src/bin/scripts/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/bin/scripts/Makefile 2013-03-04 11:11:44.367271500 +0100 @@ -16,6 +16,8 @@ top_builddir = ../../.. include $(top_builddir)/src/Makefile.global +LIBS += $(LIBS) $(LDAP_LIBS_BE) + PROGRAMS = createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb override CPPFLAGS := -I$(top_srcdir)/src/bin/pg_dump -I$(top_srcdir)/src/bin/psql -I$(libpq_srcdir) $(CPPFLAGS) --- origsrc/postgresql-9.2.3/src/interfaces/libpq/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/interfaces/libpq/Makefile 2013-03-04 11:03:01.935271500 +0100 @@ -27,7 +27,7 @@ # Need to recompile any external C files because we need # all object files to use the same compile flags as libpq; some # platforms require special flags. -LIBS := $(LIBS:-lpgport=) +LIBS := $(LIBS:-lpgport=) $(LDAP_LIBS_BE) # We can't use Makefile variables here because the MSVC build system scrapes # OBJS from this file. --- origsrc/postgresql-9.2.3/src/makefiles/Makefile.cygwin 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/makefiles/Makefile.cygwin 2013-02-08 06:49:00.645766200 +0100 @@ -1,6 +1,4 @@ # src/makefiles/Makefile.cygwin -DLLTOOL= dlltool -DLLWRAP= dllwrap ifdef PGXS BE_DLLLIBS= -L$(libdir) -lpostgres else @@ -40,6 +38,4 @@ # Rule for building a shared library from a single .o file %.dll: %.o - $(DLLTOOL) --export-all --output-def $*.def $< - $(DLLWRAP) -o $@ --def $*.def $< $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS) - rm -f $*.def + $(CC) $(CFLAGS) -shared -o $@ $< $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS) --- origsrc/postgresql-9.2.3/src/makefiles/pgxs.mk 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/makefiles/pgxs.mk 2013-03-03 22:40:26.148157400 +0100 @@ -296,5 +296,5 @@ ifdef PROGRAM $(PROGRAM): $(OBJS) - $(CC) $(CFLAGS) $(OBJS) $(PG_LIBS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X) + $(CC) $(CFLAGS) $(OBJS) $(PG_LIBS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) $(LDAP_LIBS_BE) -o $@$(X) endif --- origsrc/postgresql-9.2.3/src/port/Makefile 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/port/Makefile 2013-03-04 10:59:59.686271500 +0100 @@ -28,7 +28,7 @@ include $(top_builddir)/src/Makefile.global override CPPFLAGS := -I$(top_builddir)/src/port -DFRONTEND $(CPPFLAGS) -LIBS += $(PTHREAD_LIBS) +LIBS += $(PTHREAD_LIBS) $(LDAP_LIBS_BE) OBJS = $(LIBOBJS) chklocale.o dirmod.o erand48.o exec.o fls.o inet_net_ntop.o \ noblock.o path.o pgcheckdir.o pg_crc.o pgmkdirp.o pgsleep.o \ [-- Attachment #3: test.patch --] [-- Type: text/plain, Size: 3237 bytes --] --- origsrc/postgresql-9.2.3/src/test/regress/parallel_schedule 2013-02-04 22:28:13.000000000 +0100 +++ src/postgresql-9.2.3/src/test/regress/parallel_schedule 2013-02-08 07:07:03.526595700 +0100 @@ -13,7 +13,8 @@ # ---------- # The first group of parallel tests # ---------- -test: boolean char name varchar text int2 int4 int8 oid float4 float8 bit numeric txid uuid enum money rangetypes +test: boolean char name varchar text int2 int4 int8 oid +test: float4 float8 bit numeric txid uuid enum money rangetypes # Depends on things setup during char, varchar and text test: strings @@ -23,7 +24,8 @@ # ---------- # The second group of parallel tests # ---------- -test: point lseg box path polygon circle date time timetz timestamp timestamptz interval abstime reltime tinterval inet macaddr tstypes comments +test: point lseg box path polygon circle date time timetz timestamp +test: timestamptz interval abstime reltime tinterval inet macaddr tstypes comments # ---------- # Another group of parallel tests @@ -78,7 +80,10 @@ # ---------- # Another group of parallel tests # ---------- -test: select_into select_distinct select_distinct_on select_implicit select_having subselect union case join aggregates transactions random portals arrays btree_index hash_index update namespace prepared_xacts delete +# test: select_into select_distinct select_distinct_on select_implicit select_having subselect union case join aggregates transactions random portals arrays btree_index hash_index update namespace prepared_xacts delete +test: select_into select_distinct select_distinct_on select_implicit select_having subselect union case +test: join aggregates transactions random portals arrays btree_index hash_index update namespace delete +# test: prepared_xacts # ---------- # Another group of parallel tests @@ -92,14 +97,18 @@ # ---------- # Another group of parallel tests # ---------- -test: select_views portals_p2 foreign_key cluster dependency guc bitmapops combocid tsearch tsdicts foreign_data window xmlmap functional_deps advisory_lock json +#test: select_views portals_p2 foreign_key cluster dependency guc bitmapops combocid tsearch tsdicts foreign_data window xmlmap functional_deps advisory_lock json +test: select_views portals_p2 foreign_key cluster dependency guc bitmapops +test: combocid tsearch tsdicts foreign_data window xmlmap functional_deps advisory_lock json # ---------- # Another group of parallel tests # NB: temp.sql does a reconnect which transiently uses 2 connections, # so keep this parallel group to at most 19 tests # ---------- -test: plancache limit plpgsql copy2 temp domain rangefuncs prepare without_oid conversion truncate alter_table sequence polymorphism rowtypes returning largeobject with xml +# test: plancache limit plpgsql copy2 temp domain rangefuncs prepare without_oid conversion truncate alter_table sequence polymorphism rowtypes returning largeobject with xml +test: plancache limit plpgsql copy2 temp domain rangefuncs prepare without_oid conversion +test: conversion truncate alter_table sequence polymorphism rowtypes returning largeobject with xml # run stats by itself because its delay may be insufficient under heavy load test: stats [-- Attachment #4: Type: text/plain, Size: 218 bytes --] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-03-04 21:30 ` marco atzeri @ 2013-03-04 21:41 ` Andrew Dunstan 2013-03-04 22:32 ` Andrew Dunstan 1 sibling, 0 replies; 41+ messages in thread From: Andrew Dunstan @ 2013-03-04 21:41 UTC (permalink / raw) To: marco atzeri; +Cc: cygwin On 03/04/2013 04:30 PM, marco atzeri wrote: > On 3/4/2013 9:00 PM, Andrew Dunstan wrote: >> >> I have not heard a word on this in the 5 weeks or so since it was sent. >> Are you guys interested in fixing this or not? > > yes Andrew, > I am working on it, unfortunately this Makefile spaghetti > is not nice to handle Well, you can ask me for help :-) I deal with this code a lot. Anyway, I'll take a look at what you have so far. cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-03-04 21:30 ` marco atzeri 2013-03-04 21:41 ` Andrew Dunstan @ 2013-03-04 22:32 ` Andrew Dunstan 2013-03-05 5:42 ` marco atzeri 1 sibling, 1 reply; 41+ messages in thread From: Andrew Dunstan @ 2013-03-04 22:32 UTC (permalink / raw) To: marco atzeri; +Cc: cygwin On 03/04/2013 04:30 PM, marco atzeri wrote: > On 3/4/2013 9:00 PM, Andrew Dunstan wrote: >> >> I have not heard a word on this in the 5 weeks or so since it was sent. >> Are you guys interested in fixing this or not? > > yes Andrew, > I am working on it, unfortunately this Makefile spaghetti > is not nice to handle > > probably 90% is working now, but I just found > that postgres.exe is incomplete > > attached current patch for my trial > > src/backend/Makefile needs some works for > postgres.exe and libpostgres.a > > that I hope is the only missing bit > Incidentally, there is no need to change the test schedules, and such a patch would not be accepted. There is an option to restrict the number of concurrent connections the regression tests will run (designed specifically with Cygwin in mind, in fact, many years ago.) The way to do this is: make MAX_CONNECTIONS=10 check cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-03-04 22:32 ` Andrew Dunstan @ 2013-03-05 5:42 ` marco atzeri 2013-03-05 15:39 ` Andrew Dunstan 0 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-03-05 5:42 UTC (permalink / raw) To: Andrew Dunstan; +Cc: cygwin On 3/4/2013 11:32 PM, Andrew Dunstan wrote: > > > > Incidentally, there is no need to change the test schedules, and such a > patch would not be accepted. There is an option to restrict the number > of concurrent connections the regression tests will run (designed > specifically with Cygwin in mind, in fact, many years ago.) The way to > do this is: > > make MAX_CONNECTIONS=10 check > nice to know. The test.patch is what I used in last release Please note that "prepared_xacts" is freezing the test sequence so i am forced to skip it , for the time being > > cheers > > andrew > Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-03-05 5:42 ` marco atzeri @ 2013-03-05 15:39 ` Andrew Dunstan 0 siblings, 0 replies; 41+ messages in thread From: Andrew Dunstan @ 2013-03-05 15:39 UTC (permalink / raw) To: marco atzeri; +Cc: cygwin On 03/05/2013 12:42 AM, marco atzeri wrote: > On 3/4/2013 11:32 PM, Andrew Dunstan wrote: >> > >> >> >> Incidentally, there is no need to change the test schedules, and such a >> patch would not be accepted. There is an option to restrict the number >> of concurrent connections the regression tests will run (designed >> specifically with Cygwin in mind, in fact, many years ago.) The way to >> do this is: >> >> make MAX_CONNECTIONS=10 check >> > > nice to know. > The test.patch is what I used in last release > > Please note that "prepared_xacts" is freezing the test sequence > so i am forced to skip it , for the time being Yeah. Now that's an interesting thing, which I have also seen. Here's a relevant data point. My Postgresql Buildfarm member brolga <http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolga&br=HEAD>, which runs on Cygwin 1.7.7, and builds with gcc 4.3.4, doesn't have this difficulty. So What I'd like to know is what changed between when those things were released and now to make this break. cheers andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-25 12:34 ` marco atzeri 2013-01-25 13:20 ` Kai Tietz @ 2013-01-25 13:22 ` Kai Tietz 1 sibling, 0 replies; 41+ messages in thread From: Kai Tietz @ 2013-01-25 13:22 UTC (permalink / raw) To: cygwin Well, here are my 2-cents about that issue. In general it is a flaw to have an base-relocation in debug-section, as this means such debug information can't be moved into a separate debug-file anymore. A debug-file has no relocation-information. Nevertheless it would be good, if objcopy gets adjusted to eliminated base-relocations of stripped sections. Kai -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 9:49 ` marco atzeri 2013-01-24 10:01 ` Corinna Vinschen @ 2013-01-24 15:56 ` Christopher Faylor 2013-01-24 16:17 ` marco atzeri 1 sibling, 1 reply; 41+ messages in thread From: Christopher Faylor @ 2013-01-24 15:56 UTC (permalink / raw) To: cygwin On Thu, Jan 24, 2013 at 10:49:35AM +0100, marco atzeri wrote: >The attached patch solves the issue of the short ".gnu_deb" >on binutils cvs > >--- src/binutils/objcopy.c 2013-01-07 18:40:59.000000000 +0100 >+++ src_new/binutils/objcopy.c 2013-01-19 22:50:12.447000600 +0100 >@@ -3453,6 +3453,7 @@ > break; > > case OPTION_ADD_GNU_DEBUGLINK: >+ long_section_names = ENABLE ; > gnu_debuglink_filename = optarg; > break; Would you mind sending that (with a ChangeLog) to the binutils mailinglist at sourceware.org? My system is in a strange state right now so I'm having problems building anything besides Cygwin itself at the moment. So I can't roll out a new version of binutils. I hope to have some time this weekend to rectify that. (The rectification will be in the form of a new computer with Fedora installed) cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-24 15:56 ` Christopher Faylor @ 2013-01-24 16:17 ` marco atzeri 0 siblings, 0 replies; 41+ messages in thread From: marco atzeri @ 2013-01-24 16:17 UTC (permalink / raw) To: cygwin On 1/24/2013 4:56 PM, Christopher Faylor wrote: > On Thu, Jan 24, 2013 at 10:49:35AM +0100, marco atzeri wrote: >> The attached patch solves the issue of the short ".gnu_deb" >> on binutils cvs >> >> --- src/binutils/objcopy.c 2013-01-07 18:40:59.000000000 +0100 >> +++ src_new/binutils/objcopy.c 2013-01-19 22:50:12.447000600 +0100 >> @@ -3453,6 +3453,7 @@ >> break; >> >> case OPTION_ADD_GNU_DEBUGLINK: >> + long_section_names = ENABLE ; >> gnu_debuglink_filename = optarg; >> break; > > Would you mind sending that (with a ChangeLog) to the binutils mailinglist > at sourceware.org? > > My system is in a strange state right now so I'm having problems > building anything besides Cygwin itself at the moment. So I can't roll > out a new version of binutils. I hope to have some time this weekend to > rectify that. > > (The rectification will be in the form of a new computer with Fedora > installed) > > cgf > No problem. Unfortunately the real issue is not there, something else is not producing correct PE-COFF with debug_link Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 12:35 ` Binutils objcopy bug (was Re: rebase segfault) Corinna Vinschen 2013-01-16 13:38 ` marco atzeri @ 2013-01-18 15:34 ` marco atzeri 2013-01-18 15:44 ` Christopher Faylor 2013-01-19 8:56 ` marco atzeri 2 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-18 15:34 UTC (permalink / raw) To: cygwin On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > > As far as I can tell it's an objcopy bug. > > The stripped version of the DLL has a normal relocation information > which at one point ends in a NULL IMAGE_BASE_RELOCATION record, as > expected. After calling `objcopy --add-gnu-debuglink', the relocation > information is supposed to be the same as before, since the relocatable > file content didn't change. > > Nevertheless, when stepping through the relocator code in rebase, it > turns out that the former NULL IMAGE_BASE_RELOCATION record does not > contain only 0 values anymore. Rather, it has been overwritten with > some random(?) non-0 values, which rebase correctly interprets as the > start of the next IMAGE_BASE_RELOCATION array. So rebase blunders > along, thus either just SEGVing, if everything goes well, or, worst > case, overwriting formerly correct information in the file with > arbitrary data. > > This is a serious bug in objcopy in the current binutils. Given that > cygport creates the debug info automatically, we might end up with > spuriously broken DLLs in the distro. > > I checked with objcopy from the older binutils 2.51.53-2, and the > problem did not show up. I also built the latest binutils release > 2.23.1 and the problem also doesn't show, so we probably can get away > with just a black eye by updating binutils to 2.23.1. Chris? > > > Corinna > Chris, any news ? Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-18 15:34 ` marco atzeri @ 2013-01-18 15:44 ` Christopher Faylor 0 siblings, 0 replies; 41+ messages in thread From: Christopher Faylor @ 2013-01-18 15:44 UTC (permalink / raw) To: cygwin On Fri, Jan 18, 2013 at 04:34:25PM +0100, marco atzeri wrote: >On 1/16/2013 1:35 PM, Corinna Vinschen wrote: >> >> As far as I can tell it's an objcopy bug. >> >> The stripped version of the DLL has a normal relocation information >> which at one point ends in a NULL IMAGE_BASE_RELOCATION record, as >> expected. After calling `objcopy --add-gnu-debuglink', the relocation >> information is supposed to be the same as before, since the relocatable >> file content didn't change. >> >> Nevertheless, when stepping through the relocator code in rebase, it >> turns out that the former NULL IMAGE_BASE_RELOCATION record does not >> contain only 0 values anymore. Rather, it has been overwritten with >> some random(?) non-0 values, which rebase correctly interprets as the >> start of the next IMAGE_BASE_RELOCATION array. So rebase blunders >> along, thus either just SEGVing, if everything goes well, or, worst >> case, overwriting formerly correct information in the file with >> arbitrary data. >> >> This is a serious bug in objcopy in the current binutils. Given that >> cygport creates the debug info automatically, we might end up with >> spuriously broken DLLs in the distro. >> >> I checked with objcopy from the older binutils 2.51.53-2, and the >> problem did not show up. I also built the latest binutils release >> 2.23.1 and the problem also doesn't show, so we probably can get away >> with just a black eye by updating binutils to 2.23.1. Chris? >> >> >> Corinna >> > >Chris, >any news ? Nope. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-16 12:35 ` Binutils objcopy bug (was Re: rebase segfault) Corinna Vinschen 2013-01-16 13:38 ` marco atzeri 2013-01-18 15:34 ` marco atzeri @ 2013-01-19 8:56 ` marco atzeri 2013-01-19 15:23 ` Corinna Vinschen 2 siblings, 1 reply; 41+ messages in thread From: marco atzeri @ 2013-01-19 8:56 UTC (permalink / raw) To: cygwin On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > This is a serious bug in objcopy in the current binutils. Given that > cygport creates the debug info automatically, we might end up with > spuriously broken DLLs in the distro. > > I checked with objcopy from the older binutils 2.51.53-2, and the > problem did not show up. I also built the latest binutils release > 2.23.1 and the problem also doesn't show, so we probably can get away > with just a black eye by updating binutils to 2.23.1. Chris? > Hi Corinna, it seems not so easy. Just built from cvs objcopy --version GNU objcopy (GNU Binutils) 2.23.51.20130119 but the problem is still there > > Corinna > Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Binutils objcopy bug (was Re: rebase segfault) 2013-01-19 8:56 ` marco atzeri @ 2013-01-19 15:23 ` Corinna Vinschen 0 siblings, 0 replies; 41+ messages in thread From: Corinna Vinschen @ 2013-01-19 15:23 UTC (permalink / raw) To: cygwin On Jan 19 09:56, marco atzeri wrote: > On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > > >This is a serious bug in objcopy in the current binutils. Given that > >cygport creates the debug info automatically, we might end up with > >spuriously broken DLLs in the distro. > > > >I checked with objcopy from the older binutils 2.51.53-2, and the > >problem did not show up. I also built the latest binutils release > >2.23.1 and the problem also doesn't show, so we probably can get away > >with just a black eye by updating binutils to 2.23.1. Chris? > > > > Hi Corinna, > it seems not so easy. > > Just built from cvs > > objcopy --version > GNU objcopy (GNU Binutils) 2.23.51.20130119 > > but the problem is still there You're right, unfortunately. I don't know what I did when testing it 3 days ago, but now I can reproduce the crash even with 2.23.1. Bummer. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2013-03-05 15:39 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-15 8:44 rebase segfault marco atzeri 2013-01-15 10:08 ` Corinna Vinschen 2013-01-15 10:36 ` marco atzeri 2013-01-15 11:24 ` Corinna Vinschen 2013-01-15 22:04 ` marco atzeri 2013-01-16 7:16 ` marco atzeri 2013-01-16 12:35 ` Binutils objcopy bug (was Re: rebase segfault) Corinna Vinschen 2013-01-16 13:38 ` marco atzeri 2013-01-16 14:42 ` Corinna Vinschen 2013-01-16 15:12 ` marco atzeri 2013-01-16 16:26 ` Corinna Vinschen 2013-01-24 9:02 ` Yaakov 2013-01-24 9:28 ` Corinna Vinschen 2013-01-24 9:49 ` marco atzeri 2013-01-24 10:01 ` Corinna Vinschen 2013-01-24 10:16 ` marco atzeri 2013-01-24 12:09 ` Corinna Vinschen 2013-01-24 12:35 ` marco atzeri 2013-01-24 14:12 ` Corinna Vinschen 2013-01-25 12:34 ` marco atzeri 2013-01-25 13:20 ` Kai Tietz 2013-01-25 15:01 ` Corinna Vinschen 2013-01-25 15:12 ` marco atzeri 2013-01-26 6:32 ` Reini Urban 2013-01-26 7:53 ` marco atzeri 2013-01-29 22:30 ` Reini Urban 2013-01-30 16:46 ` Andrew Dunstan 2013-01-30 17:03 ` marco atzeri 2013-03-04 20:01 ` Andrew Dunstan 2013-03-04 21:30 ` marco atzeri 2013-03-04 21:41 ` Andrew Dunstan 2013-03-04 22:32 ` Andrew Dunstan 2013-03-05 5:42 ` marco atzeri 2013-03-05 15:39 ` Andrew Dunstan 2013-01-25 13:22 ` Kai Tietz 2013-01-24 15:56 ` Christopher Faylor 2013-01-24 16:17 ` marco atzeri 2013-01-18 15:34 ` marco atzeri 2013-01-18 15:44 ` Christopher Faylor 2013-01-19 8:56 ` marco atzeri 2013-01-19 15:23 ` Corinna Vinschen
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).