Is Pelles C's jmp_buf compatible with Microsoft C's?

[rptb1]

We're porting the Memory Pool System to Pelles C in order to support Open Dylan.  One of the things we need to do is pick out register contents from the jmp_buf object.  Microsoft publish the contents of this in headers, but Pelles C does not.  Can anyone confirm that Pelles C's setjmp implementation is compatible with Microsoft's?  In other words, can I save a jmp_buf with Pelles C's setjmp and longjmp to it from a Microsoft C compiler object file?  That would ensure that we can use Microsoft's declaration of registers with Pelles C.

The Pelles C setjmp.h header has a comment

Code: [Select]

extern int __cdecl _setjmp3(jmp_buf, int);  /* MS compatible */
So I'm guessing setjmp is compatible too, but I thought I'd better see if anyone knows better.

Thanks!

The code we're working on is here https://github.com/waywardmonkeys/mps-temporary/commit/86cd97995641f4606b6d2930a79cf2331a02f7b6#L2R25

[frankie]

From 'setjmp.h':

Code: [Select]

extern int __cdecl _setjmp3(jmp_buf, int);  /* MS compatible */
jmp_buf is declared as an array of int as per MS spec, so I expect that also the registers order is the same.
For 64bits there is no explicit compatibility declaration.
Maybe you can make a test using debugger, you can trace jmp_buf structure contents after a setjmp call.

[frankie]

If you are doing all this to get the EBX register could be easier:

Code: [Select]

unsigned int _ebx;
_asm mov dword ptr [_ebx], ebx;

return StackScanInner(ss, stackBot, (Addr *)(_ebx), 3);

[rptb1]

The assembler line is a good thought.

We're not just getting the stack pointer.  The scan scanner must be sure to see the callee-save registers as well, them all onto the stack.  We could write custom assembler for that (and we used to) but setjmp does it more simply.

This makes me realise that the comments in the code aren't sufficient, so thanks for that!

[frankie]

I see, but while MS documented the format of his jmp_buf implying that they will not modify it, it is generally not a good idea to use internal function formats because they can change anyway.
In the specific case of your project you are anyway correlated to the hardware so the use of assembler is pefectly legal.
Consider that almost all compiler have predefined symbols to specify the architecture for which you are compiling (PellesC have __POCC_TARGET__ => 1=x86, 2=ARM, 3=x64). It is easy to create conditional assembler compilation compliant for CPU and OS.

[rptb1]

We do indeed use __POCC_TARGET__ in mpstd.h, but thanks for pointing it out.

The setjmp code is almost portable, so it's easier for us to maintain, even if there is a possibility of change.  We try to guard against that with assertions.  The approach works well for us.  We also have a general rule against fine-grained conditional compilation #ifdef because of the gradual code spaghetti this creates over time.  Compare our source with, for example https://github.com/ivmai/bdwgc/blob/master/os_dep.c which I worked on commercially for a time.  In that case, the spaghetti was a significant factor in the failure of the company!

Anyway we're blocked on http://forum.pellesc.de/index.php?topic=5474.0 at the moment.

Thanks for taking the time to look at our project.