Anybody with hands-on experience compiling with FPC for MASM, including the RTL ? The FPC compiler option is there. The advantageis that ML.EXE can produce both COFF and OMF, so that VCC code can be statically linked with FPC code, using the Microsoft linker. Or at least in theory ....

It is rather unfortunate that fpc can only link OMF, not COFF on Windows (I read on some previous posts that it is the other way round, but according to <http://stackoverflow.com/questions/966597/whats-the-difference-between-the-omf-and-coff-format> and <http://www.iecc.com/linker/linker03.html> that doesn't seem to be the case).

Regards,

Adriaan van Os

In our previous episode, Adriaan van Os said:

It is rather unfortunate that fpc can only link OMF, not COFF on Windows (I read on some previous posts that it is the other way round, but according to <http://stackoverflow.com/questions/966597/whats-the-difference-between-the-omf-and-coff-format> and <http://www.iecc.com/linker/linker03.html> that doesn't seem to be the case).

Easiest is to check the files with cygwin "file", and then you'll see:

C:\pp32\units\i386-win32\ptc>file ptc.o
ptc.o: MS Windows COFF Intel 80386 object file

FPC is COFF, and I don't see anything in the referenced links saying otherwise. The stackoverflow link is quite old.

The first link seems to indicate that VSS can generate both omf and coff, so let it generate COFF ?

Well, according to <http://msdn.microsoft.com/en-us/library/s0ksfwcf.aspx>

omf
Generates object module file format (OMF) type of object module. /omf implies /c; ML.exe does not support linking OMF objects.
Not available in ml64.exe.

So, COFF seems to be the standard for VCC. When I run mingw-objdump I get "file format pe-i386" for both a VCC .obj and an FPC .o.

But .... if the formats are the same, what is the cause of the error message " Illegal COFF Magic" when trying to statically link with FPC a VCC produced .obj or .lib ?

Regards,

Adriaan van Os

Would it be possible to give some simple example code that could be tested?

Did you try using the external linker to see if this makes a difference? -Xe option should work for that.

Regards,

Pierre Muller

But .... if the formats are the same, what is the cause of the error message " Illegal COFF Magic" when trying to statically link with FPC a VCC produced .obj or .lib ?

I found the COFF docs here <http://wiki.osdev.org/COFF> and here <http://msdn.microsoft.com/en-us/gg463119.aspx>

the Visual C++ produced .obj has a header that starts with

00 00 FF FF 01 00 4C 01 ....

The FPC .o has a header that starts with

4C 01 ....

which indicates a standard COFF header (as checked by compiler/ogcoff.pas).

I can not make anything of the Visual C++ produced .obj with the Microsoft provides docs. If that isn't typically Microsoft ... How to corrupt any standard by "slightly modifying" it .... I will look further to dig up some meaningful info.

Regards,

Adriaan van Os

I can not make anything of the Visual C++ produced .obj with the Microsoft provides docs. If that isn't typically Microsoft ... How to corrupt any standard by "slightly modifying" it .... I will look further to dig up some meaningful info.

Amusingly, Microsofts own SDK dumpbin tool says

Microsoft (R) COFF/PE Dumper Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved.

File Type: ANONYMOUS OBJECT

ANON OBJECT HEADER VALUES
1 version
14C machine (x86)
545CC084 time date stamp Fri Nov 07 04:52:20 2014
ClassID: {0CB3FE38-D9A5-4DAB-AC9B-D6B6222653C2}
3F5F size
0 flags

It perfectly well understands FPC generated .o files, but not Visual C++ generated .obj files. Unbelievable.

However, objconv <http://www.agner.org/optimize/#objconv> sheds some light on the issue

Whole program optimization intermediate file for MS compiler. Undocumented

and indeed the Debug version of the same .obj file has a normal COFF header, is recognized by the FPC linker (and produces FPC internal error 200602232).

Anyway, I think the workaround for the "Illegal Coff Magic" linker error is to recompile with Visual C++ turning whole-program-optimization off. It suggest to document this somewhere. Or to improve the error message in compiler/ogcoff.pas for "Whole program optimization intermediate file for MS compiler. Undocumented" files.

I still have to investigate the internal error 200602232.

Regards,

Adriaan van Os

The is no COFF magic.
the first 2 bytes indicate normally a MACHINE type.

The files I produced start etiher by:
0x8664 indicating a x86 coff header
or
0x014c indicating a i386 coff header.

Nevertheless,
0x0000 is also listed as IMAGE_FILE_MACHINE_UNKNOWN

Could it be that your coff object only contains raw data, so that it is usable on different formats?

After some searching, I think that the
answer to your problem is here:
http://llvm.org/docs/doxygen/html/structllvm_1_1COFF_1_1BigObjHeader.html

Your header looks like a BigObjHeader
This means that the object is prepared to handle relocation that are not in the 4-byte
range... A feature that Free Pascal indeed does not support IIRC...

There is probably an option somewhere to use normal 32-bit relocation type objects in you Visual C++ configuration, unless you really need those 64-bit relocations...

Pierre

07.11.2014 17:01, Pierre Free Pascal пишет:

Even if this issue is resolved, linking together binutils-compatible and VC-compatible COFF files is next to impossible, due to significant differences in processing of COMDAT sections, debug information, section naming, etc.

Sergei

Sergei Gorelkin wrote

> Your header looks like a BigObjHeader

Ah, that's interesting, thanks.

Still it would be useful (and not very difficult, see <http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140915/235411.html>) to add BIGOBJ support to the FPC linker. BIGOBJ COFF files could be produced by other compilers than MS-VC, e.g. LLVM.

Regards,

Adriaan van Os

Adriaan van Os wrote

Anybody with hands-on experience compiling with FPC for MASM, including the RTL ? The FPC compiler option is there.

NASM ist probably supported better and should be able to generate a lot of different object file types.

Thanks for the hint. Compiling Pascal code with -Anasmwin32 works fine, both with the internal linker and GNU LD. The advantage over MASM is that it can be used cross (to my astonishment Xcode even installs nasm).

Next, I will try to combine this with LLD or LINK.EXE.

Regards,

Adriaan van Os

Adriaan van Os wrote

(to my astonishment Xcode even installs nasm). Just in case, you find this interesting:

http://forum.nasm.us/index.php?PHPSESSID=sl1i7lf3upjgenov75agnkui56&topic=1972.msg8738#new

I saw that and wondered if nasm can be used with FPC on Mac OS X. What is the status of -Amacho, by the way ?

Regards,

Adriaan van Os

On Fri, November 7, 2014 14:35, Adriaan van Os wrote: .
.

I still have to investigate the internal error 200602232.

Have you tried Pierre's suggestion of testing it with the external linker (-Xe)? However, the Sergei's note about incomaptible use of sections between MS VCC and FPC should be probably also of interest.

BTW, it's better to mention that you're not subscribed to this list in your questions sent here.

Tomas

Yes, that was the first I tried. No success. I am now experimenting with LINK.EXE, but it looks like it requires a compiler hack (something like _imp_dllname_procname rather than $dll$dllname$procname for imports).

(-Xe)? However, the Sergei's note about incomaptible use of sections between MS VCC and FPC should be probably also of interest.

Problems are there to be solved, not to scare away. Some of it may be related to debug info, which isn't available anyway and can be stripped, as FPC doesn't write PDB.

BTW, it's better to mention that you're not subscribed to this list in your questions sent here.

I didn't know that I am not suscribed .....

Regards,

Adriaan van Os

Adriaan van Os wrote

I saw that and wondered if nasm can be used with FPC on Mac OS X. What is the status of -Amacho, by the way ? Stalled. The same place is was 4-5 years ago. i386 only (the only hardware

I had then) and no PIC support
Not sure, if I'll return to it in the next year, but might in 2016.

thanks,
Dmitry