English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 19 May 2020, 00:53   #1
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 87
vasm/vlink issue causing Guru 81000005

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:

Code:
**************
 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:

Code:
$(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):

Code:
$(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:

Code:
$(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:

Code:
$(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

Last edited by DanielAllsopp; 19 May 2020 at 01:23. Reason: Added link to files.
DanielAllsopp is offline  
Old 19 May 2020, 02:03   #2
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 235
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.
Antiriad_UK is offline  
Old 19 May 2020, 10:05   #3
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 327
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.
sparhawk is offline  
Old 19 May 2020, 11:16   #4
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,671
Quote:
Originally Posted by DanielAllsopp View Post
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.

Quote:
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 is offline  
Old 19 May 2020, 11:23   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,671
Quote:
Originally Posted by sparhawk View Post
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:
Code:
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.
phx is offline  
Old 19 May 2020, 14:35   #6
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 87
Quote:
Originally Posted by Antiriad_UK View Post
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!

Quote:
Originally Posted by sparhawk View Post
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.

Code:
    *--- 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:

Code:
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.
DanielAllsopp is offline  
Old 19 May 2020, 15:16   #7
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 626
Quote:
Originally Posted by DanielAllsopp View Post
. Are there advantages to using bsr.s?
Saves 2 bytes
DanScott is offline  
Old 19 May 2020, 16:17   #8
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 87
Quote:
Originally Posted by DanScott View Post
Saves 2 bytes
Handy to know!
DanielAllsopp is offline  
Old 19 May 2020, 18:07   #9
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,671
Quote:
Originally Posted by DanielAllsopp View Post
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.
phx is offline  
Old 20 May 2020, 00:37   #10
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 235
Quote:
Originally Posted by phx View Post
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?
Antiriad_UK is offline  
Old 20 May 2020, 11:11   #11
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 327
Quote:
Originally Posted by phx View Post
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).
sparhawk is offline  
Old 20 May 2020, 17:27   #12
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,671
Quote:
Originally Posted by Antiriad_UK View Post
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!
phx is offline  
Old 20 May 2020, 17:34   #13
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 235
Quote:
Originally Posted by phx View Post
Now there is. I added the new option
-nomsg=<n>
, which can suppress specific informational messages. Try tomorrow's source snapshot!
Thanks!
Antiriad_UK is offline  
Old 21 May 2020, 10:56   #14
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 235
Quote:
Originally Posted by phx View Post
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.
Antiriad_UK is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
VLINK / VBCC / VASM linking order issue adrianpbrown Coders. C/C++ 6 14 January 2020 07:10
vasm / vlink undefined symbol zeGouky Coders. General 2 02 January 2019 08:49
Vasm/Vlink odd issue linking roondar Coders. Asm / Hardware 7 10 December 2017 20:19
Trying out vlink and vasm cla Coders. General 2 30 September 2016 20:30
VLINK multiple VASM objects roondar Coders. Asm / Hardware 2 24 April 2016 01:03

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.08382 seconds with 13 queries