ptreplay.library gets stuck on PTPlay (fd2pragma used wrong?)

[thyslo]

When fd2pragma is used with the wrong parameters, can this be lead to an executable that behaves unstable somehow?

As an example yesterday I tried to use the preplay.library to enable module playback for a little game I write:

    
    #include <dos/dos.h>
    #include <libraries/ptreplay.h>
    #include <proto/ptreplay.h>
    #include <proto/dos.h>
    
    struct Library *PTReplayBase = NULL;
    struct Module *Mod = NULL;
    
    int main(int argc, char* argv[])
    {
      PTReplayBase = OpenLibrary("ptreplay.library",0L);
      if(PTReplayBase == NULL)
      {
        PutStr("Failed to open ptreplay.library.\n");
        exit(RETURN_FAIL);
      }
      
      Mod = PTLoadModule("mod.some_melody");
      if(Mod == NULL)
      {
        CloseLibrary(PTReplayBase);
        PutStr("Failed to load module.\n");
        exit(RETURN_FAIL);
      }
      
      PTPlay(Mod);
      
      do
      {
        ...
      }
      while(gameIsRunning);
      
      PTStop(Mod);
      PTUnloadModule(Mod);
      CloseLibrary(PTReplayBase);
      exit(RETURN_OK);
    }

The problem: When compiling with gcc 6.5 the program gets stuck in the PTPlay(Mod); call. The mod playback starts and continues ok, but the PT_Play() is never leaved. In opposite when compiling it with SAS-C and running that binary the playback starts, PT_play() leaves immediately while the playback continues and the game runs fine.

So I wonder of this could be an issue of me having generated the headers for gcc wrong. I created them according to the fd2pragma.guide.

For the gcc headers:

    fd2pragma fd/ptreplay_lib.fd CLIB clib/ptreplay_protos.h TO inline SPECIAL 40
    fd2pragma fd/ptreplay_lib.fd CLIB clib/ptreplay_protos.h TO proto SPECIAL 35

For SAS-C headers:

    fd2pragma fd/ptreplay_lib.fd CLIB clib/ptreplay_protos.h TO pragma SPECIAL 6
    fd2pragma fd/ptreplay_lib.fd CLIB clib/ptreplay_protos.h TO proto SPECIAL 35

Does the creation of the gcc headers look wrong somehow?

[phx]

Originally Posted by thyslo

So I wonder of this could be an issue of me having generated the headers for gcc wrong. I created them according to the fd2pragma.guide.

Seems correct. Probably your gcc-port is not compatible to previous Amiga ports, or something is missing. Does it provide a correct inline/macros.h? You may want to check the LP1 macro for PTPlay() and whether it really passes the module pointer in register a0.

You can also compile your test program with -S and have a look at the inline code generated for the PTPlay() call.

Your last option would be not to use inlines at all and generate a library with stub functions instead (special 12?).

[thyslo]

With gcc 6.5 there is a inline/macros.h provided but I don't understand enough to tell if it is correct. I've attached it to this post, 'though.

The inline/ptreplay.h which was generated by fd2pragma has the following line:

#define PTPlay(module) \
	LP1(0x2a, ULONG, PTPlay, struct Module *, module, a0, \
	, PTREPLAY_BASE_NAME)

So to me it looks like the pointer is passed in a0. But the syntax is cryptic and probably I have a lack of understanding.

[phx]

Originally Posted by thyslo

inline/macros.h provided but I don't understand enough to tell if it is correct.

I would have to look up that gcc inline-syntax as well. Might be easier to look at the assembler output with -S.

#define PTPlay(module) \
    LP1(0x2a, ULONG, PTPlay, struct Module *, module, a0, \
    , PTREPLAY_BASE_NAME)

So to me it looks like the pointer is passed in a0.

Yes. That's the same which my recent fd2pragma generates. But concerning the LP1-macro I noticed that your macros.h defines it with one extra argument. I would guess that 'bt', the base-type (?), is not passed. It was probably added for gcc6.5? Although it is never used by the macros...

#define LP1(offs, rt, name, t1, v1, r1, bt, bn)

[thyslo]

Strange but I've just compiled the example above and this one works with gcc 6.5 without being stuck.

I posted the example C program above by copy and paste from the game I'm playing around with. That game is more complex than this example here. Things are loaded, GELs and display are initialized etc. So maybe that one gets stuck because some of these things are done before. Nevertheless the question remains why it only gets stuck when running the gcc binary, not on SAS-C one. But this is something I'll have to dig out.

Attached is the C example and the gcc output ASM file in case there is something to discover.

[phx]

Originally Posted by thyslo

That game is more complex than this example here. Things are loaded, GELs and display are initialized etc. So maybe that one gets stuck because some of these things are done before.

Quite likely. All the library calls from your example code look fine.

Nevertheless the question remains why it only gets stuck when running the gcc binary, not on SAS-C one.

Could be anything. Like a coding bug which trashes memory at more harmful locations than the SAS/C version does.

[thyslo]

Yesterday I made several tests.

First I created a linker lib for ptreplay.libray with 'fd2pragma fd/ptreplay_lib.fd SPECIAL 12'

And changed the prototype include from proto/ to clib/

With these changes my game has the same freeze / unstability as when using the inlines.

All further tests I've done with the linker lib / clib include.

Without ptreplay.library my game code 'seems' to be fine. I've MuForce and MuGuardianAngel running in the background. No MuForce hits.

As soon as I use the first function from ptreplay.library there are MuForce hits. At this point I only used PTLoadModule(), not even PTPlay().

I've built it with all compilers I've installed: StormC4 (gcc2.95), vbcc 0.9f, SAS-C 6.5 and gcc 6.5 from bebbo (on Linux).

All built binaries except the SAS-C one produce MuForce hits as soon as at least PTLoadModule() is used.

Uncommenting some of my own function calls before and after the PTLoadModule() revealed that the hits likely occur when my functions call a library function. In this case it was an iffparse.library call to read an ILBM file.

The only idea I have (apart from having a big problem in my code that I'm just not able to find at the moment) is: All compilers I use support auto-opening the well-known AmigaOS libraries. So I don't open them with OpenLibrary(), I just use their functions. The only library I open manually is the ptreplay.library. Could this mix of auto-opened and manually opened libraries be a problem?

[alkis]

Your sample plays fine in emulated A1200 compiled with gcc for me.

What I did:
fd2sfd Include/fd/ptreplay_lib.fd Include/clib/ptreplay_protos.h -o ptreplay.sfd

mkdir proto
mkdir inline
sfdc --mode=proto ptreplay.sfd -o Include/proto/ptreplay.h
sfdc --mode=macros ptreplay.sfd -o Include/inline/ptreplay.h

m68k-amigaos-gcc -s -noixemul -O3 -IPTReplay/Include ptplay.c -o ptplay

[thyslo]

Yeah this example works for me too. But the more complicated game I tried to extend by mod playback doesn't work properly.

You can have a look at Github if you're intersted.

(The repository may not be public for a long time as I neither own the assets nor the game idea..)

[alkis]

Umm, looking at you cmakelists.txt

why set(EXTRALIBS_LINK_FLAGS "-lptreplay")?
dynamic libraries don't need that. Only static .lib files. Am I reading this wrong?

[alkis]

Ok, its the stubs for the library. I didn't used that at all when compiling the sample. (that's what the inlines are for, so you dont need stubs)

[thyslo]

Yeah before I used the static linker lib I also tried to use to inlines. Because my program got stuck then on PTPlay() I thought there's something wrong with the inlines. And switched to use linker lib. But it didn't help, it gets stuck anyhow.

But don't reverted to use inlines. Because with stubs I can include <clib/ptreplay_protos.h> and VSCode (what I often use) works better with these.

[alkis]

Originally Posted by thyslo

But don't reverted to use inlines. Because with stubs I can include <clib/ptreplay_protos.h> and VSCode (what I often use) works better with these.

You can fix that with:

#ifdef __clang__
#include <clib/exec_protos.h>
#include <clib/dos_protos.h>
#include <clib/ptreplay_protos.h>
#else
#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/ptreplay.h>
#endif

intellisense sees the clib/ and actual compiling the proto/

[thyslo]

Ah thanks for this hint. I'll surely use it:-)

[thyslo]

I've changed all my .c files to use proto instead of clib ... and now, I don't know why but it works!

The game runs, the mod playback works, no crash at exit etc. This is great, thanks for the hint, alkis!

As as neat side effect the binary size reduced from 21,6 KB to to 19,8 KB:-)