vasm/vlink issue causing Guru 81000005

[DanielAllsopp]

Evening!

I'm getting a strange crash when exiting my program, which all I can narrow it down to is the order in which I have my object files linked.

The files which I'm referring to below are all sprite data files, which contain a section at the bottom like this:

**************
 SECTION ChipData,DATA_C
**************

  CNOP 0,8
SpriteData:
  INCLUDE "data/sprite.background.64x48x4.s"
  END

So back to the crash, for example, if the linker order goes like this:

$(OBJDIR)/startup.o \
$(OBJDIR)/main.o \
$(OBJDIR)/utility.o \
$(OBJDIR)/macros.o \
$(OBJDIR)/copper.o \
$(OBJDIR)/display.o \
$(OBJDIR)/sprites.o \
$(OBJDIR)/background.o \
$(OBJDIR)/character.o \
$(OBJDIR)/input.o

Then everything works as expected. If I have my linker order like this (remove character.o, which is also a sprite object file):

$(OBJDIR)/startup.o \
$(OBJDIR)/main.o \
$(OBJDIR)/utility.o \
$(OBJDIR)/macros.o \
$(OBJDIR)/copper.o \
$(OBJDIR)/display.o \
$(OBJDIR)/sprites.o \
$(OBJDIR)/background.o \
$(OBJDIR)/input.o

Then when I exit I immediately get a Guru Meditation with the code 81000005.

Another issue, if I move background.o further up the list:

$(OBJDIR)/startup.o \
$(OBJDIR)/main.o \
$(OBJDIR)/background.o \
$(OBJDIR)/utility.o \
$(OBJDIR)/macros.o \
$(OBJDIR)/copper.o \
$(OBJDIR)/display.o \
$(OBJDIR)/sprites.o \
$(OBJDIR)/input.o

Then I don't get a Guru Meditation, everything exits cleanly but the sprite data is just garbage on the screen.

If I move background.o below the copper.o object file, which contains my copper list:

$(OBJDIR)/startup.o \
$(OBJDIR)/main.o \
$(OBJDIR)/utility.o \
$(OBJDIR)/macros.o \
$(OBJDIR)/copper.o \
$(OBJDIR)/background.o \
$(OBJDIR)/display.o \
$(OBJDIR)/sprites.o \
$(OBJDIR)/input.o

Then I don't get a Guru Meditation, but rather a recoverable alert when I exit with the error code: 0100000F.

Any ideas? I've been looking at this, and the vlink docs all day and don't understand why the ordering has such an effect on the execution of the code.

Thanks.

Edit: Here's a link to the executables that are crashing. Everything works absolutely fine, until I exit (LMB): Link

[Antiriad_UK]

It won’t be anything to do with vlink. It will almost certainly be a buffer overrun in your code. When you change the order of linking you are changing which bit of code your buffer overrun is writing. Tricky to find :/

Comment out subroutines until it exits cleanly and then go from there.

[sparhawk]

Are you using 'bsr.s'? I had a similar problem because the offset was to big, when the target was to far away, and got no error or warning, so I thought the code would work and in assembly it usually worked because the code was more compact and the offset worked. When using 'jsr' instead it works.

[phx]

Originally Posted by DanielAllsopp

I'm getting a strange crash when exiting my program, which all I can narrow it down to is the order in which I have my object files linked.

As far as I understand your own executable crashs, not vlink? Then chances are high that Antiriad is right.

Then I don't get a Guru Meditation, everything exits cleanly but the sprite data is just garbage on the screen.

If this is reproducible and the sprite data should be static, then it seems like the best starting point for debugging. With some effort you will find the reason for the trashed data. Either check the data at different places of your code to narrow down the bug, or use a debugger and set a watch-point on the sprite-data. Also UAE's watchpoint command will work nicely.

[phx]

Originally Posted by sparhawk

Are you using 'bsr.s'? I had a similar problem because the offset was to big, when the target was to far away, and got no error or warning

Hard to believe. That would be a serious bug, but I cannot reproduce it:

frank@miriel cat bsr1.s
        code
        bsr.s   x
        rts
frank@miriel cat bsr2.s
        code
        ds.b    200
        xdef    x
x:
        rts
frank@miriel vasmm68k_mot -quiet -Fhunk bsr1.s -o bsr1.o
frank@miriel vasmm68k_mot -quiet -Fhunk bsr2.s -o bsr2.o
frank@miriel vlink -bamigahunk bsr1.o bsr2.o
Error 28: bsr1.o (CODE+0x1): Relative reference to relocatable symbol x=0xcc + 0xffffffffffffffff (value to write: 0xca) doesn't fit into 8 bits.

I even tried it with an older V0.16c vlink.

[DanielAllsopp]

Originally Posted by Antiriad_UK

It won’t be anything to do with vlink. It will almost certainly be a buffer overrun in your code. When you change the order of linking you are changing which bit of code your buffer overrun is writing. Tricky to find :/

Comment out subroutines until it exits cleanly and then go from there.

This! This is exactly what it was; adding #800 bytes in a loop one more times than I should have been. Sprite count was 4, I was looping 5 times. School boy error!

It did take some tracking down though! Thanks for the tip Antiriad_UK!

Originally Posted by sparhawk

Are you using 'bsr.s'? I had a similar problem because the offset was to big, when the target was to far away, and got no error or warning, so I thought the code would work and in assembly it usually worked because the code was more compact and the offset worked. When using 'jsr' instead it works.

There are a couple of bsr.s in there, which had been causing me a bit of an issue earlier, e.g.

    *--- save int+dma ---*

	lea $dff000,a6
	bsr.s WaitEOF			             ;wait out the current frame
	move.l $1c(a6),-(sp)		     ;save intena+intreq
	move.w 2(a6),-(sp)		       ;and dma
	move.l $6c(a4),-(sp)		     ;and also the VB int vector for sport.
	bsr.s AllOff			             ;turn off all interrupts+DMA

    *--- call main ---*

	movem.l a4-a6,-(sp)

  bsr Main

	movem.l (sp)+,a4-a6

    *--- restore all ---*

If I left all of the bsr.s in there, I got the following assembler warning:

error 2029 in line 50 of "startup.s": branch destination out of range

when adding more 'bsr' calls below Main.

I've fixed it by shuffling some bsr calls around, but it would be nice to know why this causes and issue. I usually use bsr by itself. Are there advantages to using bsr.s?

Thanks again for the help by the way.

[DanScott]

Originally Posted by DanielAllsopp

. Are there advantages to using bsr.s?

Saves 2 bytes

[DanielAllsopp]

Originally Posted by DanScott

Saves 2 bytes

Handy to know!

[phx]

Originally Posted by DanielAllsopp

Are there advantages to using bsr.s?

When assembling in vasm default mode - none. You can force an 8-bit branch with it, but usually it is better to leave the size-extension away an let the assembler find the best option. That's what an assembler is for.

[Antiriad_UK]

Originally Posted by phx

When assembling in vasm default mode - none. You can force an 8-bit branch with it, but usually it is better to leave the size-extension away an let the assembler find the best option. That's what an assembler is for.

This is a good time for this question. I like having vasm optimize things and I also turn on the option to output the optimisations (-showopt) so that I can learn and then manually change them. But I can't seem to hide the bsr optmizations (message 2054) which I would be happy to let the assembler do without my input. Ideally I always want the assembler to optmize my bsr functions but I don't want 1000 messages about it (for example when I assemble your ptreplay I get loads of bsr optimization messages). Is there a way to show optmizations but also hide output of bsr optimizations?

[sparhawk]

Originally Posted by phx

Hard to believe. That would be a serious bug, but I cannot reproduce it:

Hmm. Not sure now. Could be I'm confusing it, because I'm using bebbos suite, and only, depending on the type of project, vlink (if it is a pure assembly project).

[phx]

Originally Posted by Antiriad_UK

Is there a way to show optmizations but also hide output of bsr optimizations?

Now there is. I added the new option

-nomsg=<n>

, which can suppress specific informational messages. Try tomorrow's source snapshot!

[Antiriad_UK]

Originally Posted by phx

Now there is. I added the new option

-nomsg=<n>

, which can suppress specific informational messages. Try tomorrow's source snapshot!

Thanks!

[Antiriad_UK]

Originally Posted by phx

Now there is. I added the new option

-nomsg=<n>

, which can suppress specific informational messages. Try tomorrow's source snapshot!

Built last night's snapshot with Visual Studio 2017 command line with no issues.

-nomsg=2054 -nomsg=2050

Works great! Thank you.