problems linking formats.

problems linking formats.

[Boatwright, Charles]

gnu-win32 readers-

Here is a problem involving several backends....

The toolchain was recompiled as follows....

./configure --target=i386-unknown-aout --host=i386-pc-cygwin32
--enable-targets=i386-unknown-aout,i386-unknown-pe --program-suffix=.exe
--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
format)
Naturally the gnu-win32 toolchain seemed like a solution. Our logic:
gnu has
always supported a.out well, however pe-i386 support was not all there,
or not
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?


-chuck


INFORMATION:

NT 3.51  
running b17.1  
on pentium machine





-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: problems linking formats.

[Tim Iverson]

I'm unsure about the latest MSVC, but I do know that MSC, Borland, etc.
(all older Windows/DOS compilers) use Intel OMF, not "pe-i386", which I
believe is an executable format, not an object format.  According to the
Cygnus GCC-b17.1 source, pe-i386 assumes that the object module format is
actually a variation on COFF.

MSC did at one time support SCO's variation on COFF, which may be similar
enough to what GCC uses such that MSVC's link.exe will link without error
messages, but use incorrect offsets.  I have seen the incorrect offsets
problem with GCC-b17.1 and Phar-Lap's linker, which does support COFF.  So,
I'm inclined to believe that pe-i386 is not COFF enough to be useful
outside of GCC.

IMHO, if Cygnus wants a drop-in replacement for a production toolset, they
will need to support OMF at some point.  However, given that GNU doesn't
support it, using a bastard COFF during beta does provide a workable
solution until OMF support is ready.

I do wish it was better documented, though.  I looked all over the README's
and FAQs and saw nary a reference to executable or object format; "pe-i386"
does somewhat imply "Microsoft Portable Executable" format, often referred
to as "PE", but it would be nice if it was explicitly stated.

BTW, on another note, the standard b17.1 distribution doesn't even come
close to building itself under Windows '95.  Is everyone building under NT
or Unix (most of the problems seem to be bugs in bash)?  Is there a long
list of caveats someplace?  There is absolute no documentation in the 'all'
tarball -- gotta scrounge around for it on the web site.


- Tim Iverson
  iverson@cisco.com

\f
+----------------
| From: "Boatwright, Charles" <Charles_Boatwright@cisnc.canon.com>
| To: "'gnu-win32@cygnus.com'" <gnu-win32@cygnus.com>
| Subject: problems linking formats.
| Date: Fri, 21 Mar 1997 12:30:37 -0800
...
| the result is that we have a compiler which targets aout-i386, and can
| read aout-i386 and pe-i386
...
| 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
...
| always supported a.out well, however pe-i386 support was not all there,
| or not easy to find.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: problems linking formats.

[Kim Knuttila]

   From: Tim Iverson <iverson@cisco.com>
   Date: Mon, 24 Mar 1997 17:54:39 -0800 (PST)
   Cc: gnu-win32@cygnus.com
   X-Mailer: ELM [version 2.4 PL25]
   MIME-Version: 1.0
   Content-Type: text/plain; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Sender: owner-gnu-win32@cygnus.com
   Precedence: bulk

   I'm unsure about the latest MSVC, but I do know that MSC, Borland, etc.
   (all older Windows/DOS compilers) use Intel OMF, not "pe-i386", which I
   believe is an executable format, not an object format.  According to the
   Cygnus GCC-b17.1 source, pe-i386 assumes that the object module format is
   actually a variation on COFF.

   MSC did at one time support SCO's variation on COFF, which may be similar
   enough to what GCC uses such that MSVC's link.exe will link without error
   messages, but use incorrect offsets.  I have seen the incorrect offsets
   problem with GCC-b17.1 and Phar-Lap's linker, which does support COFF.  So,
   I'm inclined to believe that pe-i386 is not COFF enough to be useful
   outside of GCC.

   IMHO, if Cygnus wants a drop-in replacement for a production toolset, they
   will need to support OMF at some point.  However, given that GNU doesn't
   support it, using a bastard COFF during beta does provide a workable
   solution until OMF support is ready.

   I do wish it was better documented, though.  I looked all over the README's
   and FAQs and saw nary a reference to executable or object format; "pe-i386"
   does somewhat imply "Microsoft Portable Executable" format, often referred
   to as "PE", but it would be nice if it was explicitly stated.

Tim,

You're missing some info. The 'pe' does refer to "Portable Executable". This 
is Microsoft's extension to COFF and it is the official format for Windows/NT.
(There's tons of info on the MS Developer CD's, etc) Far from a 'bastard COFF',
you can think of PE as the replacement for OMF. There are PE formats defined
for i386, powerpc, alpha and mips (and probably others by now).

--krk

-- 
Kim Knuttila     | Speaking for himself as always.
Cygnus Solutions |		Woof.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

was: (Re: still installation problems)

[Bernd Prager]

Thanks everybody for help.

I solved my installation problem.
first: I had to expand GCC_EXEC_PREFIX to 
.../H-i386-cygwin32/lib/gcc-lib/i386-cygwin32/cygnus-2.7.2-961023/
second and most
I had to EXPORT (!!) all my settings in .bashrc.

By the way another question:
Is there a "curses" distribution with GNU-WIN32 or
had anybody try to port this?

Bernd
_____________________________________________________________________
Bernd Prager
GECKO mbH; Wismarsche Str.3, 18057 Rostock; Germany					
http://www.gecko.de

PGP Key fingerprint = 83 54 6A 3B 7A 9D 6C 0E F3 41 CE 99 11 30 B7 D6
public key by mailto:bpr@gecko.de?Subject=SendPGPKey
_____________________________________________________________________
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: problems linking formats.

[Matt Calder]

gnu list,
	Sorry to branch off on this thread, but if someone
who can answer this has a minute I'd really appreciate it. 
There has been much discussion on this thread about various 
object file formats, I do a lot of work with a statistical 
package (Splus), that allows one to load user code via 
object files or dlls. The object files however must have been
produced by the Watcom compiler. If one tries to load object
files produced by MSVC it complains that the object file
is not Intel-OMF. What I want to know is what object file
formats the various PC compilers use, Borand, MSVC, Watcom, 
etc..., Is it possible to convert from one to another?, 
Is there freely available documentation on these formats?
	On a side note, a question that is perhaps of a 
more general interest. If I am unable to load object files, I
must write dll's. I would like to use the gnu32 compiler. The
Splus package however, only allows loading of 16-bit dlls.
I have code written for 16->32 bit calls via generic thunking
(as described in MS Knowledge Base) that works with 32-bit
dlls compiled by Borland and MSVC. When I use a dll compiled
with gnu32 (based on the excellent and much appreciated examples
on the cygnus web site) the call to LoadLibraryEx32() fails. In
my experience this is due to auxilliary dlls not being found, 
however everthing is in the path as near as I can tell. Has 
anyone successfully loaded a gnu32 compiled dll via the 
LoadLibraryEx32() call? Is there any way to determine what 
goes wrong when this call fails (recall, it is called from a 
16-bit dll, no GetLastError()) ? 

Thanks, 
	Matt 

/*****************************************/
/* Matt Calder, Dept. of Statistics, CSU */
/* http://www.stat.colostate.edu/~calder */
/*****************************************/

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".