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

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

[Franchuk, Alex]

Hello,

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?).

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.

Any advice would be greatly appreciated!
-Alex Franchuk
--
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

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

[Jon Turney]

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