VASM and illegal relocations

[reassembler]

Quick VASM and Linking question.

Assume I do this in file 1:

PLANE_LENGTH     EQU         (320*224)/8

Then in file 2 I do the following:

lea             -PLANE_LENGTH(a4),a4

The files link together and everything executes fine and as expected.

However, on individually compiling file 2 on its own, VASM throws an "illegal relocation" error.

The current workaround is to not allow the assembler to calculate PLANE_LENGTH. So doing the following is ok:

PLANE_LENGTH     EQU         8960

However, other than ignoring the error, is there a more formal/structured way I should be organizing where my EQUs get defined to avoid the error completely?

[Galahad/FLT]

Originally Posted by reassembler

Quick VASM and Linking question.

Assume I do this in file 1:

PLANE_LENGTH     EQU         (320*224)/8

Then in file 2 I do the following:

lea             -PLANE_LENGTH(a4),a4

The files link together and everything executes fine and as expected.

However, on individually compiling file 2 on its own, VASM throws an "illegal relocation" error.

The current workaround is to not allow the assembler to calculate PLANE_LENGTH. So doing the following is ok:

PLANE_LENGTH     EQU         8960

However, other than ignoring the error, is there a more formal/structured way I should be organizing where my EQUs get defined to avoid the error completely?

Surely that last plane_length calculation is wrong?

Shouldn't it be (320/8)*224 ?

[reassembler]

I can promise you the calculation is fine and is what I want.

It's the ability to use the VSCode plugin with per-file compilation turned on, without it spewing out a ton of errors that vanish during the linking process I'm after.

[hooverphonique]

Why would using

PLANE_LENGTH     EQU         8960

work as a workaround? If PLANE_LENGTH is not defined, you should get an error regardless of if you declare it as a number, or an arithmetic expression, no?

[hooverphonique]

Ahh.. so you need to tell the assembler, the symbol will be found during linking..

try "xref PLANE_LENGTH" in source #2, and perhaps "xdef PLANE_LENGTH" in source #1 .. I'm not sure if that only works with labels though.

[reassembler]

Yep, I'd tried xdef/xref - but to no success.

The bizarre thing is - with some of my other source files, it picks up the EQU calculation fine! So I can only assume it's some sort of VASM 'internal order of doing things' that I'm violating - possibly through my own ignorance.

I did Google, and this Megadrive coder was having a similar issue:
https://huguesjohnson.com/programmin...is/game-state/

This could be some kind of ordering issue where vasm is applying the macro first but since the label doesn't have an address yet it can't continue. If the label already had an address then maybe it would be fine. Perhaps Psygnosis asm68k handles these in the opposite order as vasm. After some trial and error I resolved this in a very not elegant way by hard-coding the instrument addresses:

[hooverphonique]

If you assemble each file individually without xdef/xref the symbol, I don't understand why it sometimes would assemble at all, since PLANE_LENGTH is completely unknown (both the symbol *and* its value) when you assemble src #2.

I think there is posts on here about something related where vasm can't figure out the value of a label in a single pass (or something along those lines), and then fails.

[a/b]

PLANE_LENGTH should be defined in a common include file, used by both files.

[reassembler]

Originally Posted by hooverphonique

If you assemble each file individually without xdef/xref the symbol, I don't understand why it sometimes would assemble at all, since PLANE_LENGTH is completely unknown (both the symbol *and* its value) when you assemble src #2.

I think there is posts on here about something related where vasm can't figure out the value of a label in a single pass (or something along those lines), and then fails.

At a higher level...

main.s:
INCLUDE "file1.i"
INCLUDE "file2.i"

file1.i
;;;PLANE_LENGTH EQU (320*224)/8 ; Does not work in file2
PLANE_LENGTH EQU 8960 ; Does work in file2

file2.i
lea -PLANE_LENGTH(a4),a4

---

Anyway, yes must be something to do with the way vasm works. I was hoping someone would say "use the following command line parameter you idiot and read the manual better!

[reassembler]

Originally Posted by a/b

PLANE_LENGTH should be defined in a common include file, used by both files.

I tried that previously, but then VASM throws a hard error about it being a "repeatedly defined symbol".

Like I say, none of this is a blocker. In the VSCode Assembly plugin there is an option to turn off per-file compilation. And maybe it's for this reason. On a full compile everything links and executes perfectly.

But I usually assume I am doing something wrong when an error is thrown, and I need to understand what. (And I probably am doing something wrong!)

[paraj]

Add include guards to the common header file (see system includes for example).

If you have file1.s and file2.s that can run on their own, and main.s that includes file1.s and file2.s and file1/2 need common stuff, then create common.i (with include guards) for your equates etc. All three files can then include common.i and in main.s you can include file1.s and file2.s and call their functions etc.

You might want to structure your project a bit differently though..

[DanScott]

Try putting brackets around the whole expression....

PLANE_LENGTH EQU ((320*224)/8)

[hooverphonique]

Originally Posted by DanScott

Try putting brackets around the whole expression....

This is generally good advice for macros (especially in C/C++) because otherwise you might get bitten by operator precedence and other nasty things as the macro gets expanded

[phx]

Originally Posted by reassembler

Then in file 2 I do the following:

lea             -PLANE_LENGTH(a4),a4

The files link together and everything executes fine and as expected.

However, on individually compiling file 2 on its own, VASM throws an "illegal relocation" error.

I cannot follow you at this point. Above you wrote "the files link together", so you must have already assembled file1 and file2 individually. How else could you get two object files, file1.o and file2.o, which the linker links together?

Otherwise, it is to be expected that

-SYMBOL

cannot generate any valid relocation type, when

SYMBOL

is unknown. All common relocations work with addends on symbols, like

unknownsymbol + addend

. Negating an externally defined symbol's value is not possible, as with most other arithmetic operations, like shift, multiplications, etc..

The current workaround is to not allow the assembler to calculate PLANE_LENGTH. So doing the following is ok:

PLANE_LENGTH     EQU         8960

As others already wrote, this cannot make any difference when the definition is in file1 and you assemble file2 with

PLANE_LENGTH

completely unknown.

Originally Posted by reassembler

main.s:
INCLUDE "file1.i"
INCLUDE "file2.i"

file1.i
;;;PLANE_LENGTH EQU (320*224)/8 ; Does not work in file2
PLANE_LENGTH EQU 8960 ; Does work in file2

file2.i
lea -PLANE_LENGTH(a4),a4

This is a different situation. You will only assemble main.s, as file1.i and file2.i are already included and everything is known. This has nothing to do with linking or individually assembling files. I'm confused.

Still there is the question why you have any problems even when everything is known and included. Maybe some information is hidden, like 320 and 224 are also symbols, which are defined at a later point?

Anyway, I cannot reproduce any problem out of this:

frank@nerthus cat file1.i
PLANE_LENGTH    equ     (320*224)/8
frank@nerthus cat file2.i
        lea     -PLANE_LENGTH(a4),a4
        rts
frank@nerthus cat main.s
        include "file1.i"
        include "file2.i"
frank@nerthus vasmm68k_mot -Fhunk main.s
vasm 2.0beta (c) in 2002-2023 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.6c (c) 2002-2023 Frank Wille
vasm motorola syntax module 3.18 (c) 2002-2023 Frank Wille
vasm hunk format output module 2.14c (c) 2002-2022 Frank Wille

CODE(acrx2):               6 bytes

Can you provide a real example which reproduces your issue?

[phx]

Originally Posted by reassembler

I did Google, and this Megadrive coder was having a similar issue:
https://huguesjohnson.com/programmin...is/game-state/

Similar is that you cannot do any arithmetic operation with a relocation symbol. Acessing a label, even when known, generates a relocation (to make its address relocatable by the linker or the loader), which still only allows

label+addend

. You cannot shift a label around.

The solution would have been to enter absolute mode (

org

directive) and assemble your code for a fixed address. Then you can do everything you like with labels as no relocations will be generated.

EDIT: No, forget what I wrote above!
The example from the link above is completely unrelated. The coder just didn't know how macros work in Motorola syntax, and assumed

addr

is a macro argument while it should have been

\1

. As a result

addr

was undefined and caused relocation errors.

[reassembler]

Can you provide a real example which reproduces your issue?

Thanks for your detailed response. I did just try to recreate this as an isolated test case outside of my main codebase, and no joy - everything works as expected. The code compiles without errors. I can edit each individual file without errors. It does not matter if my EQU contains some a formula or is a single number.

With my larger project:
1/ A straight compile in VASM is fine - via the VSCode Amiga Assembly plugin. I hit Ctrl+F5. Everything compiles. No errors. It runs as expected.

2/ Then I switch to the offending file that references the EQU in the project IDE. I save it again unchanged. (I believe the VSCode Amiga Assembly Framework then compiles that file again in isolation.) This is when the compilation error is thrown to the console. The offending line is highlighted in red syntax in the IDE.

3/ The error in part 2 only occurs when there is a formula in the EQU.

4/ The error in part 2 does not occur on a full compile.

5/ As above, I cannot recreate this in my very simple project (recreating what I described in the thread)

Short of sending the entire project over, I'll pause on this one for now. If I find out what was causing it, I'll update the thread. It's not blocking me and I don't want to waste anyone's time any further!!

[phx]

Originally Posted by reassembler

4/ Ther error in part 2 does not occur on a full compile.

Is your project still structured like shown above, i.e. with a main.s source including file1.i and file2.i? Then it is no suprise that assembling file2.i individually fails...

Short of sending the entire project over

You can also contact me by email (refer to vasm documentation / home page) and I will treat the source confidentially.

[reassembler]

Originally Posted by phx

You can also contact me by email (refer to vasm documentation / home page) and I will treat the source confidentially.

Thank you - I may well take you up on the offer although I'd like to mess around a little myself first and try to figure out how to reproduce this outside of my main project!

I have a suspicion that this isn't a VASM issue - but potentially the way the 'Amiga Assembly' framework incrementally compiles pieces of code on save.

In answer to your question, yes my project is structured in the same way as the example. Well, with many more files, sections, INCBINs and other mess.

You may have spotted I'm working on an OutRun port which has entailed
rewriting things so many times, there's some housekeeping urgently needed! Once things are tidied up I'll fire it over.

[hooverphonique]

Originally Posted by reassembler

2/ Then I switch to the offending file that references the EQU in the project IDE. I save it again unchanged. (I believe the VSCode Amiga Assembly Framework then compiles that file again in isolation.) This is when the compilation error is thrown to the console. The offending line is highlighted in red syntax in the IDE.

The Amiga assembly extension assembles the file on save to alert you of any syntax errors, etc, so if this causes referencing of unknown symbols, you get errors. You can probably disable it somehow.

Originally Posted by reassembler

3/ The error in part 2 only occurs when there is a formula in the EQU.

This one I can't explain - I would expect an error regardless of formula or not.