Binutils objcopy bug (was Re: rebase segfault)

[marco atzeri]

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