This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Binutils objcopy bug (was Re: rebase segfault)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]