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".

RE: problems linking formats.

[Boatwright, Charles]

Kim,

I agree with your point about PE being COFF.  M$ finally admitted it, 
however, the format keeps changing!!!!!!  M$ continually adds segments.
In my mind (what little there is) a constantly "moving" and unpublished 
standard  (M$ requires money, i.e. MSDN) for their docs (except the docs
on the web), and the have published the format reluctantly, this makes 
M$, not the format a  ba***rd......  ;-(

Do you have any experience with the problem previously mentioned?

Here is some more information..

We have found that the calling addresses for MSVC 4.2 compiled object
are 
"off" by four bytes.    I am intentionally vague and inaccurate about
the 
process here, the exact details can be forwarded, however, my 
boss wants me to produce some code this week  ;-).


Example

image foo() in foo.obj

objdump reports the address of foo as 0x1f30, the code (when
disassembled)
has the (relative address translated) 0x1f34.  

I am still exploring this, but perhaps you can tell me, are there any
additional
details in and send-pr reports which might help?

I am guessing that the problem is somewhere in the backend, since 
objcopy can't copy pe to aout and maintain the relocation records.


-chuck

disclaimers:  I am not representing anything except my stomach!

MS Exchange is a frustratingly miserable mail package!
 

>----------
>From: 	Kim Knuttila[SMTP:krk@cygnus.com]
>Sent: 	Tuesday, March 25, 1997 7:36 PM
>To: 	iverson@cisco.com
>Cc: 	Boatwright, Charles; gnu-win32@cygnus.com
>Subject: 	Re: problems linking formats.
>
>   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".

Re: problems linking formats.

[Stan Shebs]

iverson@cisco.com (Tim Iverson) writes:

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

That's a tough call.  It's been discussed, but there is no final
decision.  It's hard to see the business reason for doing OMF; the
marketplace that needs OMF already has plenty of compilers, and those
compilers are losing money for the companies.  If someone says to me
"we'll give you a $200K/year support contract once you have OMF support"
(and they show me the money! :-) ), I'll be much more motivated; but
that hasn't happened yet.

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

Usually only the hardcore care about these kinds of details, and they can
find that in the sources.  Most programmers want it to "just work".
Still, it seems reasonable to add at least a note about PE to the
user-visible documents.

							Stan Shebs
							Cygnus Solutions
							shebs@cygnus.com
-
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.

[Dave Sanderman]

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.
i wanted to chime in here with a note about the particular bash [bug|misfeature] that i'm seeing, under both win95 and nt40:  on the bash that i have on netcom (sorry, can't check the version # of it right now), the following:

% echo foo > out
% echo bar >> out
% export TESTVAR=`cat out`

sets TESTVAR to simply "foo".  on b17.1, i'm getting

"foo
bar"

instead.  this is preventing any of the configuration scripts supplied with gcc from functioning, so i'm unable to self-host and rebuild gcc.  apologies if this is a known issue, but like tim i was unable to find any list of known bash problems.  oh, and one other thing, which i'm sure must be a FAQ, but again, i can't find the answer to--how do i stop bash from requiring a /tmp dir for the temp files produced by "cat <<EOF"?  no amount of environment var fiddling seemed to save me...

thanks in advance...
  dave sanderman -- davidsan@verity.com

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

[wiljan]

Yes there I bugs in the object handling.
It is impossible to link object code generated with the cygnus tools
using LINK form MS. When doing that you get strange offsets in references
to things similar as you experience.
I myself reported this bug to ACT. They are working on it right now.
I have no idea about the status of this work right now.

Greetings,

Wiljan

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