* RE: problems linking formats.
@ 1997-03-27 7:23 Boatwright, Charles
0 siblings, 0 replies; 8+ messages in thread
From: Boatwright, Charles @ 1997-03-27 7:23 UTC (permalink / raw)
To: 'krk@cygnus.com'
Cc: 'gnu-win32@cygnus.com', 'iverson@cisco.com'
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problems linking formats.
1997-03-26 9:44 ` Kim Knuttila
@ 1997-03-27 20:59 ` Matt Calder
0 siblings, 0 replies; 8+ messages in thread
From: Matt Calder @ 1997-03-27 20:59 UTC (permalink / raw)
To: gnu-win32
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problems linking formats.
1997-03-24 17:55 ` Tim Iverson
@ 1997-03-26 9:44 ` Kim Knuttila
1997-03-27 20:59 ` Matt Calder
0 siblings, 1 reply; 8+ messages in thread
From: Kim Knuttila @ 1997-03-26 9:44 UTC (permalink / raw)
To: iverson; +Cc: Charles_Boatwright, gnu-win32
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problems linking formats.
[not found] <199703250154.RAA28474.cygnus.gnu-win32@rottweiler.cisco.com>
@ 1997-03-25 20:11 ` Stan Shebs
0 siblings, 0 replies; 8+ messages in thread
From: Stan Shebs @ 1997-03-25 20:11 UTC (permalink / raw)
To: gnu-win32
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: problems linking formats.
@ 1997-03-25 8:02 Dave Sanderman
0 siblings, 0 replies; 8+ messages in thread
From: Dave Sanderman @ 1997-03-25 8:02 UTC (permalink / raw)
To: 'Tim Iverson', Boatwright Charles; +Cc: gnu-win32
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problems linking formats.
1997-03-21 12:31 Boatwright, Charles
@ 1997-03-24 17:55 ` Tim Iverson
1997-03-26 9:44 ` Kim Knuttila
0 siblings, 1 reply; 8+ messages in thread
From: Tim Iverson @ 1997-03-24 17:55 UTC (permalink / raw)
To: Boatwright Charles; +Cc: gnu-win32
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problems linking formats.
@ 1997-03-22 12:23 wiljan
0 siblings, 0 replies; 8+ messages in thread
From: wiljan @ 1997-03-22 12:23 UTC (permalink / raw)
To: Boatwright, Charles; +Cc: gnu-win32
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* problems linking formats.
@ 1997-03-21 12:31 Boatwright, Charles
1997-03-24 17:55 ` Tim Iverson
0 siblings, 1 reply; 8+ messages in thread
From: Boatwright, Charles @ 1997-03-21 12:31 UTC (permalink / raw)
To: 'gnu-win32@cygnus.com'
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1997-03-27 20:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-03-27 7:23 problems linking formats Boatwright, Charles
[not found] <199703250154.RAA28474.cygnus.gnu-win32@rottweiler.cisco.com>
1997-03-25 20:11 ` Stan Shebs
-- strict thread matches above, loose matches on Subject: below --
1997-03-25 8:02 Dave Sanderman
1997-03-22 12:23 wiljan
1997-03-21 12:31 Boatwright, Charles
1997-03-24 17:55 ` Tim Iverson
1997-03-26 9:44 ` Kim Knuttila
1997-03-27 20:59 ` Matt Calder
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).