X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-5.6 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ,TW_JC,TW_YG
X-Spam-Check-By: sourceware.org
X-Received: by 10.152.131.168 with SMTP id on8mr1294170lab.38.1359022589235;        Thu, 24 Jan 2013 02:16:29 -0800 (PST)
Message-ID: <510109F8.5020504@gmail.com>
Date: Thu, 24 Jan 2013 11:16:24 +0100
From: marco atzeri <marco DOT atzeri AT gmail DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Binutils objcopy bug (was Re: rebase segfault)
References: <20130115100745 DOT GC2353 AT calimero DOT vinschen DOT de> <50F5312A DOT 2040503 AT gmail DOT com> <20130115112406 DOT GA13752 AT calimero DOT vinschen DOT de> <50F5D246 DOT 6010902 AT gmail DOT com> <50F653AB DOT 80102 AT gmail DOT com> <20130116123509 DOT GA16991 AT calimero DOT vinschen DOT de> <50F6AD63 DOT 8080106 AT gmail DOT com> <20130124030145 DOT 22fa143f AT YAAKOV04> <20130124092746 DOT GC8311 AT calimero DOT vinschen DOT de> <510103AF DOT 3080305 AT gmail DOT com> <20130124100037 DOT GB24121 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130124100037.GB24121@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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