* 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 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
* 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 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-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 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-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
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).