[fpc-devel] safecall_exceptions in OSX

[David Jenkins]

I have been using the safecall functionality in linux and it has been 
working.  I now am porting the same code to OSX and find that 
safecall_exceptions is not turned on.  In particular I need the 
functionality that catches the HRESULT and passes it back to the calling 
function.  I see that tf_safecall_exceptions is only enabled in 
tsysteminfo for i_linux and i_win.


Is it possible to enable tf_safecall_exceptions for i_macos.

Thanks
David Jenkins
da...@scootersoftware.com

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Dmitry Boyarintsev]

On Fri, Nov 7, 2014 at 12:55 PM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Florian Klaempfl wrote:

Am 07.11.2014 10:35, schrieb Adriaan van Os:

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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Florian Klaempfl]

Am 07.11.2014 10:35, schrieb Adriaan van Os:
> 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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Sergei Gorelkin wrote:

Your header looks like a BigObjHeader


Ah, that's interesting, thanks.

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

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.


Still it would be useful (and not very difficult, see 
) 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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Sergei Gorelkin]

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

   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,
0x 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...

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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Pierre Free Pascal]

  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, 
0x 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

> -Message d'origine-
> De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
> boun...@lists.freepascal.org] De la part de Adriaan van Os
> Envoyé : vendredi 7 novembre 2014 13:10
> À : FPC developers' list
> Objet : Re: [fpc-devel] Masm
> 
> > 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  and here
> 
> 
> 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
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

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  and here


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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Pierre Free Pascal]

  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


> -Message d'origine-
> De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
> boun...@lists.freepascal.org] De la part de Adriaan van Os
> Envoyé : vendredi 7 novembre 2014 11:25
> À : FPC developers' list
> Objet : Re: [fpc-devel] Masm
> 
> Marco van de Voort wrote:
> > 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
> >>  between-the-omf-and-coff-format>
> >> and  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  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
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Adriaan van Os]

Marco van de Voort wrote:

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

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Masm

[Marco van de Voort]

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 
> 
>  
> and  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 ?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Masm

[Adriaan van Os]

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 
 
and  that doesn't seem to be the case).


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel