This is the mail archive of the
mailing list for the Cygwin project.
Re: Out of date GNU binutils, and (slightly) broken binutils 2.27
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: "Franchuk, Alex" <afranchuk at LGSInnovations dot com>
- Cc: cygwin at cygwin dot com
- Date: Mon, 23 Jan 2017 14:10:57 +0000
- Subject: Re: Out of date GNU binutils, and (slightly) broken binutils 2.27
- Authentication-results: sourceware.org; auth=none
- References: <5882821D.6090000@LGSInnovations.com>
On 20/01/2017 21:33, Franchuk, Alex wrote:
I've been responsible for porting a large [primarily] C++ project from
Linux to Cygwin. This project generates object files at one point in the
build process which exceed the object file symbol count limit (around
32k, but if I recall correctly there was actually a binutils bug
limiting this further to 16k). As such, I needed an assembler and linker
that supported the windows big-obj format. That was added in more recent
versions of GNU binutils, however the version that is available in the
Cygwin repository is discouragingly old. So the first point I want to
make is to ask whether the maintainers of Cygwin binutils can be pinged
to update the supported version, or to know why the last supported
version is from 2014 (is there something that breaks with newer versions?).
If I understood correctly, 'nm -l' suffers from a chronic slowdown on
x86 (but not x86_64). This makes the cygport stage which builds
debuginfo packages take forever for large projects.
No-one has had the time to investigate this problem.
The next step I took was to get a recent version (2.27) that does
support big-obj, compile it on the system, point gcc toward that
installation, and try to proceed from there. This fixed the big-obj
issue, and for the most part lots of the sub-projects were working just
fine. But one sub-project in particular is having an issue: the
resulting binary (a dll, in this case) has a flaw in the import lookup
table (.idata subsection). The import lookup table of one
runtime-dependent DLL is overwriting the null entry that *ends* the
previous DLL's table. So, the previous DLL tries to link with a symbol
that is actually contained in the other DLL, while the other DLL still
correctly points to needing that symbol as well. In other words, this
makes it impossible to use the resulting DLL, because it has a dependent
symbol that will never be resolved correctly. It's worth noting that
lots of other things link correctly without this bug, and other DLLs
within that file do not have import lookup tables that overrun each
other. I thought it would be reasonable to send to this mailing list
because, from what I read in the binutils source, it seemed like most of
the pe/pe+ code that has been added to binutils was from Cygwin
developers. I tried to find the root of the problem, but after hours of
searching and debugging the linker and BFD code, I haven't found the
source of the discrepancy.
Please report this issue on the binutils bugzilla.
Please include a test case, or at least an example of a defective PE
file, and say what you think it should look like.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple