68k/OS3.x MatchFirst()/MatchNext()/etc errors on OS4 help need it

@All

Want to fix some old 68k code, sources to which i have, but which unpossible to port to OS4 in acceptable timeframe due to lot of assembler and co, so want to fix just 68k binary to work properly on OS4.

And the issue which i noticed, that when i run binary, i have a DOS window saying:

Quote:


Now i search in the whole source, and fine MatchFirst usage just in one file, in 3 places, and it looks like this:




So and this is the same in all 3 places.

What i tried to do so far is that:



And then change the code like this:



See there i use macro, change . on -> in few places , and remove &.

But when i run binary, it bring me still the same warning window.

Maybe it can come from other DOS functions which inderectly run the MatchXXX functions ?

Remember that this is 68k code and should be keept as 68k one , and not os4 native, as whole os4 port is pain, and used SDK is NDK3.9, not OS4 SDK.

Any help/ideas welcome !

Maybe there any switches/flags which can be used like maybe some -D_OLD_ANCHOR_ or something of that sort ?


EDIT: interesting, when i comment out all MatchFirst() calls in the code, on the running game still bring me the same window! So seems MatchFirst still called somehow under the hood when anchors and stuff are used or something ?

@kas1e
Quote:The Match#?() functions were obsolete functions, only left for compatibility to ancient m68k software, which definitely shouldn't be used inside dos.library itself.
Maybe it's not something directly in the sources you are using, but an old and broken (wrong data alignment) link library using those functions instead, or something in the m68k assembler parts with the same bugs?

IIRC some of the old C libraries (Lattice C, SAS C, etc.) used the dos.library Match#? functions as well.

@joerg
Quote:

Yes it very much looks like it in link librarys of the 68k compiler i use now : i use bebbo's cross-compiler (gcc 6.5x) so seems something going wrong there.

In meantime i will move everything to 68k VBCC instead : that one were proven to be most efficient and bug free C compiler for 68k in last years and better deal with bugs on VBCC which Frank will fix very fast (if there will be any).

@kas1e

GCC 6 has problems, I tried compiling NetSurf with it some time back and the resulting executable didn't work. If you can get it building with vbcc that will be better, alternatively an older GCC version is more likely to be stable. Which compiler was it built with originally?

It may be worth also switching to the 3.2 NDK, in case there's some weird bug in the headers.

@Chris
Original was on StormC , but i found bebbo's gcc buggy even because i just compile simple:



via:



And run it on AOS4, as result : no prinfs, 99% cpu loading and programm in forever loop. So that was enough :)

Currently i switched to VBCC, and while all compiles, it happy crashes in petunia right on the start, after showing first image.

But that no surprise, because original compiler flagsfrom StormC were:




So for 6.5 gcc i had to short it to:



But at least i have working binary, but with VBCC i curently compile them like this (as only those options found):



And if i link it with -lmeees i happy crashes on libs:maths_something.library in petunia, so i had to compile with -lmsoft. Then no crash in those math libraries, but then i crashes after the first image shown.

So not sure what better way now .. Porting to OS4 native will be hard because of about 20 assembler files coming with.

I wonder if the same thing happens if you use AllocMem instead of using auto variables. AllocMem will handle the alignment for you. Just interesting to see if it would work.

@rjd324
I just recompile everything from scratch again via this bebbo's gcc, and this time i don't have MatchFirst errors. Weird random stuff ..

@Chris
I have now make source to be build and for gcc and for vbcc (there almost wasn't any changes), and strangely that GCC version at least runs, go to the menu, etc, etc. But VBCC one, justs show first image and simple crashes..

I was in hope that it's about additional preprocessor options, but i just tried to build via GCC like this:



And the same code by for vbcc like this:



And still have those weird crashes exactly with VBCC version, while GCC version runs the same as before.

Sadly that is 68k, and i can't debug it normally on OS4, but maybe worth to try this VBCC version in WinUAE and at least make it works on WinUAE (if it didn't) and then made it works on OS4.

But that anyway strange .. the same C code , compiled the same, and reacts different when build with different compilers. But yeah.. includes/link-libs/inlines/etc all different..

@kas1e

Yeah, I built some SAS/C code with vbcc and it uncovered bugs that had been hidden. Some code should have never worked, just luck that it did. There's almost certainly a bug in there, which if you find will fix it for vbcc.

@kas1e



in MatchNext() there is additional issues

@All
So how this code should looks like if it will be rewritten "good" and bein 68k/os4 compatible (with the same code, or with ifdefs, not that matter):



Thanks!

@kas1e

Do you dream in code?

@rjd324
I mean some skilled programmer will rewrote it if one will have interest and i can just copy+paste it, without recreating a wheel and loosing time on things i didn't know good enough.

@kas1e
struct AnchorPath myAnchor;

Is not an acceptable way to allocate space on the stack for an Anchor or FIB or anything that requires longword alignment,
regardless of whether it's 68K or anything else, you are still going to trash memory,
(except on OS4 where you get the warning and it does a workaround to prevent memory trashing.)

The reason here is that the Anchor has a FileInfoBlock (FIB) embedded inside it.

When old or new DOS calls an old style packet FileSystem with the fallback (or in the V40 68K case, the only) Examine() call,
it has to pass the FIB as a BCPL pointer;
It makes the BCPL pointer (BPTR) with the macros in dos.h MKBADDR() and converts it back with BADDR() to a CPTR (c-pointer) again.

The problem occurs due to the conversion of a non-longword C-address to a BPTR and back again to a CPTR.

EG:
CPTR 16: MKBADDR(16)=4 -> BPTR BADDR(4)=16 (OK)
CPTR 18: MKBADDR(18)=4 -> BPTR BADDR(4)=16 (FAIL)
CPTR 20: MKBADDR(20)=5 -> BPTR BADDR(5)=20 (OK)

As you can see, the middle one (non longword aligned) results in the filesystem writing the FIB data 2 bytes before the storage area,
thereby corrupting whatever is behind the storage area in memory, or on the stack in this case.

The D_S macro will work well enough to prevent this memory trashing problem.

As far as these MatchXXX functions go, they are still supported in OS4 and have been recently updated with macros in dos/anchorpath.h
to also handle 64 bit file sizes and all new extended features like multi-assignments and long names.

@Colin
Andrea help me with this function , and that what we have:



So when i compile it with newlib for os4 directly all fine. But when i compile it for os3 (via their gcc 6.5) then i have heavy crashes.

Also if i compile that with clib2 also for os4, it again bring DOS warning windowses about "bad usage of MatchFirst", and bring bugs and errors.

Seems it still bad enough anyway.. But i need that kind of code to be working on OS4 and OS3, so i can run both versions of different HW to check for bugs and compare how it all works, etc.

Firstly, you cannot use the new OS4 AnchorPath definition if you expect this to work on OS3 (68K),
Incase you are using the OS4 includes, you will need to declare the USE_OLD_ANCHORPATH definition
BEFORE including the OS4 dos/anchorpath.h include file, or anthing that may inadvertantly include it,
(if that is what you are using) to make absolutely sure you are using the old 68K definition that
OS3 DOS expects internally, otherwise you will crash your brains out.

So do this before including anything, (it won''t hurt for OS3);
#define USE_OLD_ANCHORPATH
#include dos/anchorpath.h

The line; "struct AnchorPath *myAnchor __attribute__ ((aligned));"
is pointless, the pointer alignment is unimportant, it's the memory it points to that must
be aligned to a 4 byte address, so lose the "__attribute__ ((aligned));"

OS4 is backwardly compatible to OS3 methods, OS3 is NOT forwardly compatible.
So to get the backward compatibility, you need to use "backward" methods everywhere.

The OS4 AnchorPath call in AllocDosObject() is not available on OS3 so it can't be called,
otherwise it will simply assume you are using the new structure definition, because you are
obviously running on OS4, so it may not work as intended and may do OS4 initialisations on
the OS4 structure it allocates that won't end up in the right places for OS3 structures.

So just use this OS3 method for both systems, and it will work;
myAnchor = AllocMem( sizeof(struct AnchorPath),MEMF_ANY|MEMF_CLEAR);

That way, you won't get OS4 confused into thinking you have the new OS4 structure definition
which automatically happens when you use OS4's AllocDosObject().

AFAIK, the malloc() call you are using does not appear to guarantee longword alignment either.
I never used it, so i'm not sure what the various clib releases do, so to be safe, i'd use the
exec AllocMem() and FreeMem() functions instead to guarantee longword alignment on both systems,
those work and do guarantee longword alignment.

Also, for your sanity, add some error checking and test your return codes, it is possible for
a memory allocation to fail you know.