System takeover crashes in some cases

[sparhawk]

I have a source for a system takeover and restore here: https://github.com/skeetor/amiga-uti...stemTakeover.s


Now, when I compile and execute this with my gcc projects it appears to work. Started it several times and had no problem.

https://github.com/skeetor/amiga-uti...evelop/VAsmGCC


Strangely, when I use this in an ASM only project, I always get a Task Held requestor and a guru meditation.

https://github.com/skeetor/amiga-uti...velop/VAsmOnly


I debugged it in metascope and there it worked, and on the shell I also ran it and I had some times where it worked, but mostly it seems to crash, though I don't know why.


Nay ideas whats wrong with this?

[Asman]

@sparhawk
It is really not a good idea to store hardware registers when dma and/or ints are active. Because some int and/or copperlist can change them and you will stay with invalid values.

Personally I think that is really good thing to check how others handle with system takeover, for example how StingRay takeover system in his MiniStartup.

[sparhawk]

Actually I was taking this from some sample code, expecting that it works, but I will look at this startup you mentioned.

[phx]

Originally Posted by sparhawk

I have a source for a system takeover and restore here: https://github.com/skeetor/amiga-uti...stemTakeover.s

Probably doesn‘t matter, but I would call Forbid() at the start of SystemSave, and I wouldn‘t restore INTREQ. A real takeover should also disable all DMA and interrupts, while you only load a NULL view.

Now, when I compile and execute this with my gcc projects it appears to work. Started it several times and had no problem.

The startup code makes a difference? Although, it is hard for anybody to analyze your code when you don‘t show the exact command lines for compiler, assembler, linker.

For example: did you compile with register arguments enabled? ASMstrlen expects the pointer in a0, while the standard C-ABI for 68k is to pass all arguments on the stack.

Strangely, when I use this in an ASM only project, I always get a Task Held requestor and a guru meditation.

What kind of Guru? Always the same? Running under Kickstart 1.x?

[sparhawk]

Running on KS 1.3. And it was always Guru 4. Anyway, I will look at the ministartup and work from there.
The compilation is done via the CMake project, from that repository. Using bebbos gcc compiler suite as a base with MSYS2. But the guru only happens in the ASM project only, so there is no additional startup code involved.

https://github.com/skeetor/amiga-uti...AsmOnly/main.s

Actually I was a bit surprised about this code anyway, as I would expect to use Forbid()/Disable() pretty early. But I'm not sure what system functions can still be called after that.

[phx]

Originally Posted by sparhawk

and on the shell I also ran it and I had some times where it worked

Which means, you are running it from WB? I saw no WB startup code in your assembler-only version. But then I still see no reason for a crash when started from shell...

I would even try to build your VasmOnly-test myself, but as mentioned before there is too much information missing or hidden. How do you call vasm or the linker? Which options? Any libraries you are linking with?

Does it also crash if you comment the calls to SystemSave/SystemRestore out?

EDIT: Managed to assemble and link all your sources (main.s, strlen.s, SystemTakeover.s). The resulting executable is attached (516 Bytes). Tested on an emulated A500 with WB 1.3 in the shell. No problems.

vasmm68k_mot -Fhunk -o main.o main.s
vasmm68k_mot -Fhunk -o strlen.o strlen.s
vasmm68k_mot -Fhunk -o SystemTakeover.o SystemTakeover.s
vlink -bamigahunk -o VasmOnly.68k -s -x main.o strlen.o SystemTakeover.o

[sparhawk]

I'm now converting the ministartup. I was not running it from WB, only from shell, and sometimes it worked, but I don't really know why.

[Asman]

Originally Posted by sparhawk

I'm now converting the ministartup. I was not running it from WB, only from shell, and sometimes it worked, but I don't really know why.

Converting ??? If I were you I would first check ministartup with some basic stuff like some bars on black screen. Just to be sure how it works.

Perhaps you did some mistake(s). Its hard to guess without source. Please post the source.

[sparhawk]

I have to convert it, because it doesn't assemble with vasm. Or maybe it needs some special options?

The current version can be found here, but it's not finished yet.
https://github.com/skeetor/amiga-uti...AmigaUtils/src

[sparhawk]

I converted this now, and it works now! Thanks for the help!

I still want to do some minor cosmetic changes, but at least I can now start to experiment with the stuff I wanted to. So next I want to get some Copper stuff working. The bars, Asman was mentioning, wil be next.

[Asman]

Originally Posted by sparhawk

I converted this now, and it works now! Thanks for the help!

I still want to do some minor cosmetic changes, but at least I can now start to experiment with the stuff I wanted to. So next I want to get some Copper stuff working. The bars, Asman was mentioning, wil be next.

Great. you can also use RS directive to deal with variables. You can check for example my old source in github link
It is just black interleaved screen.

[sparhawk]

I tested the startup code and it worked in the example where I use only assembler. I have another example project, where I use gcc interfacing with assembler, and strangely it did not work there, instead it just got stuck. So I debugged it and found the reason why this was the case.

In the original code, I had this:

	move.w	#$7FFF,d0
	bsr	WaitRaster

In the assembler only example it seems that the bsr was near enough to jump to the proper address. In the gcc example, it seems that the symbols where so far apart, that the bsr pointed to some weird address. Now I'm not sure if this is a problem with gcc, or something else, but I would have expected that I get some error if a symbol is not reachable with this instruction. After changing it to:

	move.w	#$7FFF,d0
	jsr	WaitRaster

it worked, of course.

So any idea, why I didn't even get a warning or an error in that case? I'm not even sure where the problem may be.

The assembler doesn't know the address of the symbol at compile time, so it probably can not warn me. Since this is in an library, it will not know it, until it is actually linked. So I would expect that I get an error at link time at latest, right?

[phx]

Originally Posted by sparhawk

The assembler doesn't know the address of the symbol at compile time, so it probably can not warn me. Since this is in an library, it will not know it, until it is actually linked. So I would expect that I get an error at link time at latest, right?

Correct. The linker should tell you something like "16-bit pc-relative reference at sectioname+offset for symbol xyz out of range!".

Which linker is it and which command line options does it get?

[sparhawk]

 m68k-amigaos-g++  --save-temps -Wall -pedantic -mcrt=nix13 -O3 -mregparm -O3 -DNDEBUG CMakeFiles/VASMGcc.dir/main.cpp.o CMakeFiles/VASMGcc.dir/strlen.cpp.o CMakeFiles/VASMGcc.dir/strlen.asm.o  -o bin/VASMGcc.exe -Wl,--out-implib,bin/libVASMGcc.dll.a /opt/amiga/utils/lib/libAmigaUtils.a /opt/amiga/utils/lib/libAmigaGCCUtils.a

Maybe I should post an issue on bebbo's git repository, as this appears to be a cmopiler/linker problem.

[bebbo]

Originally Posted by phx

Correct. The linker should tell you something like "16-bit pc-relative reference at sectioname+offset for symbol xyz out of range!".

Which linker is it and which command line options does it get?

Well, m68k-amigaos-ld inserts long jump tables and adjusts the word/short jumps to the next jump table (do you remember?)


Maybe there's an error...

[phx]

Originally Posted by bebbo

Well, m68k-amigaos-ld inserts long jump tables and adjusts the word/short jumps to the next jump table (do you remember?)

Ah, yes! Also called ALV (Automatic Link Vector) in BLink and PhxLnk. I always wanted to support that in vlink.

Maybe there's an error...

Most likely the vector doesn't point to the right place.
Is there an option? ALVs shouldn't be enabled by default, IMHO.

[sparhawk]

I have fixed the issues when building with CMake under Linux, so this should work now. I built the executables under Linux as well, and tested them, and the same problem persists.
I also created a screenshot to illustrate it better, but I hope that you can now also build it, following the instructions on the repo.

The left side shows that the "bsr" points to "somewhere" while the right side "jsr" correctly points to "_WaitRaster".

[bebbo]

Ok, I tracked it down

Consider this example code:

_X:
        nop
        nop
        bsr foo
        rts

The output of vasm with -Fhunk differs from the as output.

vasm:

   0:   4e71            nop
   2:   4e71            nop
   4:   6100 0000       bsr.w 0x6
   8:   4e75            rts

m68k-amigaos-as:

   0:   4e71            nop
   2:   4e71            nop
   4:   6100 fffa       bsr.w 0x0
   8:   4e75            rts

and the binutils linker expects the latter version to link with correct offsets.

You may call this a bug or feature - but vasm and as aren't compatible if a bsr is used to an extern symbol.

[sparhawk]

Can I easily convert the code to AS? As far as I understood it, AS is not really designed to be used for "human" assembly programming, as it is mostly designed to be used by gcc right? That's actually the reason why I was using vasm instead, assuming that it is a good choice for Amiga programming and compatible with gcc.

Since I'm still at the start, I could switch to AS if it is worth it, so I wonder if that should be the way to go.
Such a bug is a bit frightening, if it compiles without warning whatsoever.

Still, thanks for your analysis. And also for the feedback on my cmake build as I now have at least some feedback from some external source. "Works on my machine" never guarantees that the next guy can also use it.

[phx]

Originally Posted by bebbo

You may call this a bug or feature - but vasm and as aren't compatible if a bsr is used to an extern symbol.

When as outputs a hunk-format object file, then it is a bug in as. And when ld expects pc-relative relocs in such a form (in hunk objects) then it is also a bug in ld.

To calculate the addend of pc-relative relocs relative to the section-base is only done in a.out format. This is not how hunk-format works. Probably some old a.out code is lurking somewhere...