This is the mail archive of the
mailing list for the Cygwin project.
problems linking formats.
- To: "'gnu-win32 at cygnus dot com'" <gnu-win32 at cygnus dot com>
- Subject: problems linking formats.
- From: "Boatwright, Charles" <Charles_Boatwright at cisnc dot canon dot com>
- Date: Fri, 21 Mar 1997 12:30:37 -0800
Here is a problem involving several backends....
The toolchain was recompiled as follows....
./configure --target=i386-unknown-aout --host=i386-pc-cygwin32
--prefix=/usr/testbuild -v > configure.log 2>&1
make > make.log 2>&1
make -k install > makeinstall.log 2>&1
the result is that we have a compiler which targets aout-i386, and can
read aout-i386 and pe-i386
For reasons I need not explain...
We have a library, built with MSVC 4.x object code ONLY :-@
We need to link this to an aout-i386 format target (same cpu, different
Naturally the gnu-win32 toolchain seemed like a solution. Our logic:
always supported a.out well, however pe-i386 support was not all there,
easy to find.
We are experiencing a problem, and I wondered if anyone had
some experience or direction....
When testing the execution, the following situation was uncovered....
we have four functions
fooWin32 (in the win32 object code)
foobarWin32 calls foobarAOUT
fooAOUT, which calls fooWin32 from our source.
foobarAOUT does nothing
Here is the test from main(), from source
main calls fooAOUT - This works
fooAOUT calls fooWin32 - This works
main calls fooWin32 - This works
main calls foobarWin32 - This works
foobarWin32 calls foobarAOUT - This DOESN'T work
This appeared very interesting.
So I did some investigation....
objdump says this..
fooWin32 is at xxxx1F0
foobarWin32 is at xxxx200
fooAOUT is at xxxx210
foobarAOUT is at xxxx220
when I look at the diassembly of the program,
The call from foobarWin32 to foobarAOUT is off by 4 bytes!!!!
We tried the following (as a brute force patch)
we did an objcopy of the win32 object code
objcopy --adjust-section-vma=text-4 --remove-section=.debug$S
--remove-section=.debug$T --strip-debug myfoo.obj foowin32.obj
This objcopy permitted foobarwin32 to call foobarAOUT
now we have a real problem
fooWin32 can't call foobarWin32
Does any one have any ideas on this?
on pentium machine
For help on using this list, send a message to
"firstname.lastname@example.org" with one line of text: "help".