Out of date GNU binutils, and (slightly) broken binutils 2.27

Jon Turney jon.turney@dronecode.org.uk
Mon Jan 23 14:11:00 GMT 2017


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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list