29 August 2020, 01:31 | #1 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
VASM/VLINK relocation issues
I'm trying to get Breathless compiled with vasm/vlink contained in Bebbo's toolchain.
https://github.com/mheyer32/Breathless I'm pretty close to get it linked, but encounter multiple issues of this type during linking: Code:
Error 32: Target amigahunk: Unsupported relocation type R_ABS (offset=0, size=16, mask=ffffffffffffffff) at .text+0x10402. Error 32: Target amigahunk: Unsupported relocation type R_ABS (offset=0, size=16, mask=ffffffffffffffff) at .text+0x10498. Error 32: Target amigahunk: Unsupported relocation type R_ABS (offset=0, size=16, mask=ffffffffffffffff) at .text+0x1052e. Error 32: Target amigahunk: Unsupported relocation type R_ABS (offset=0, size=16, mask=ffffffffffffffff) at .text+0x105cc. Code:
move.l Yoffset(a5,d7.w*4),a1 or move.l Yoffset(a5,d7.w*4),a1 and also tst.w pause(a1) CODE (i.e. .text) contains code and constant tables __MERGED,bss contains runtime variables, base-relative addressed through a5 ("near data") TABLES,bss contains runtime data too large for __MERGED ("far data") In the code above, Yoffset and pause are xref'd / xdef'd in separate files. Both are placed into __MERGED. The lines of nature 'tst.w pause(a1)' that the linker complains about are referencing __MERGED through a1. I don't really understand what the issue is, I suspect a bug in vasm/vlink maybe? There's also some other bug I ran into: The linker placed _LinkerDB into the last bss section it encounters, not always __MERGED. So if TABLES is the last new bss section it runs into, _LinkerDB will be placed into TABLES, which won't work. I had the impression, the linker knows about __MERGED and would treat it accordingly? And finally, the assembler would complain about illegal relocations when doing this: Code:
lea ObjectsPunList-4(a5),a1 |
29 August 2020, 20:15 | #2 | ||||||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Any 16-bit absolute references should be constants (equates) and will be resolved by the linker. 16-bit address (label) references can only happen with small data, but that would be an R_SD reloc type, not R_ABS. Quote:
Quote:
That doesn't help you with Yoffset(a5,d7.w), though, because only d16(An) addressing modes are recognized for small data. BTW, I would be interested to know which assembler was originally used for Breathless? Did it really create small-data references for these lines? Quote:
Theoretically you could fix that, because it is a 16-bit base register displacement addressing mode. When it would be pause(a2)you only need near a2on top of it to make vasm generate the correct relocation type. But unfortunately only A2 - A6 are allowed for the NEAR directive, because I was under the impression that a base register which is volatile (according to the m68k C-ABI), like A0 and A1, makes no sense. Now I would agree that such an artificial restriction is stupid. If you want to use A1 as your base register temporarily, why should I stop you? Will change that. It's an easy fix. Quote:
Quote:
Quote:
Quote:
|
||||||||
29 August 2020, 22:14 | #3 | |||||||
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
Hi,
Thanks for your repsonse! I encourage you to checkout the linked repository and try 'make' in the 'Sorgenti' directory. The project structure is simple and will help you to understand whats going on. Quote:
So I think the assembler is not properly recognizing that this is a 16bit relative relocation and wrongly emits a 16bit abslolute relocation. Quote:
Quote:
Quote:
Quote:
Code:
FROM TMap.o+TMapMain.o+DrawScreen.o+c2p8.o+3d.o+Interrupt.o+movement.o+sincos.o+Text.o+Animations.o+Objects.o+Scores.o+devices.o+Loader.o+FileAccess.o+Terminal.o+Audio.o+Map.o+SecurityCode1.o+Player/Music.o+Presentation.o+Last.o LIB Work:Aztec5/lib/libs/amiga.lib TO TMap ADDSYM MAP TMap.map f,h Quote:
What I did instead is to embrace the code in question with Code:
basereg $7FFE,a1 .... tst.w pause(a1) .... endb But it would still complain about the exact same code. Quote:
(see https://github.com/mheyer32/Breathle...76c6b7304R1155 ) This way __MERGED is the last unique section name the linker will see and this way it placed _LinkerDB into __MERGED. |
|||||||
31 August 2020, 17:08 | #4 | |||||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Quote:
Quote:
Ok. I added support for it through the new command line option -extsd. The option is necessary for not breaking compatibility with older sources. You find that option together with support for "near a1" in tomorrow's daily source snapshot of vasm. Quote:
Quote:
Quote:
Quote:
You certainly want to use the full 64K range of the small data segment? Not just 32K. This means that the addend, used in a small-data relocation, has to be unsigned. Sorry, there is nothing I can or will do. When any other assembler supports it, then it either does no range error checks at all or only supports 32K small data segments. Last edited by phx; 31 August 2020 at 17:15. Reason: clarification: it's an addend, not a displacement |
|||||||
31 August 2020, 20:21 | #5 | ||
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
Quote:
Thanks for adding -extsd! I wanted to try it out, but apparently this modification did not end up in the daily source snapshot :-( 'near a1', though, worked. Code:
I can have a look at this issue, if you want to send me all the object files, and the linker options used, by email. Quote:
The code here doesn't really want to address ObjectsPunList at offset -4, but I think it'll apply some sort of preincrement before accessing the data. There's some other examples where the code attempts to obfuscate accessing the same symbol multiple times: Code:
xref SecCodeRow,SecCodeCol lea SecCodeRow-$228(a5),a1 moveq #36,d1 jsr Rnd addq.w #1,d0 move.w d0,a0 move.l a0,$228(a1) ;SecCodeRow moveq #10,d1 jsr Rnd add.w #65,d0 move.w d0,a0 move.l a0,$228+4(a1) ;SecCodeCol Luckily I can disable all of these places as they are copy protection related anyways |
||
01 September 2020, 15:44 | #6 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Quote:
Yes, I see the vlink errors. The 8-bit R_ABS references are all due to (Yoffset,a5,d7.w) where vasm defaults to 8-bit, when Yoffset is unknown. You can fix that by adding a .w suffix to Yoffset, so -extsd will work with it. Then only a few errors are left which originate from Audio.asm, but there is no Yoffset in it. Quote:
When you have small-data relocs, i.e. the referenced symbol is known, the addend/offset stored with it must be unsigned, because the AmigaDos HUNK_DREL16 relocation table expects an offset to the start of the object's small data section. This is usually not a problem, unless you use a negative displacement on the first symbol in this section. With small-data external references I agree that a signed 16-bit addend would make sense, but vlink reads the R_SD-addends in both cases as unsigned to put them in the same internal reloc table. Maybe I should tackle this problem now. I ignored it for too long. Will have a look how much effort it takes to pass a flag from the hunk-format loader module down to the core routines... |
|||
01 September 2020, 18:20 | #7 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
I just tested the latest vasm. Only two issues are left, which seem to have every imaginable complication in them:
Code:
move.l Yoffset.w+4(a5,d1.w*4),a1 Thank you for helping out! Very much appreciated! |
02 September 2020, 15:03 | #8 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
There are problems with your syntax.
Yoffset.w+4is not correct, because the +4 should be part of the displacement, which is terminated by the .w suffix. Yoffset+4.wwill work, although I would recommend to use the newstyle syntax when working with 020+ addressing modes. With ((Yoffset+4).w,d1.w*4)you can also use parentheses, which makes it clearer. Update: I probably managed to make the addends in external small-data references signed, while keeping the relocs unsigned. To try it you have to update vasm and vlink with the next source snapshot (in 12 hours). So only the issue with _LinkerDB pointing to a wrong section remains. How do I reproduce that? |
02 September 2020, 18:52 | #9 | ||
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
Quote:
https://github.com/mheyer32/Breathle...76c6b7304R1155 Removing Quote:
|
||
04 September 2020, 16:00 | #10 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Yes, got it! And fixed. See next vlink snapshot.
It was just a display problem. The "Linker symbols:" header was missing in the map file, so it looked like _LinkerDB belongs to the last section listed. The generated executable was certainly identical in both cases. |
04 September 2020, 16:53 | #11 |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
I'm sorry if I'm hijacking this thread but I didn't want to create yet another vasm one.
First of all I must thank phx for his work on vasm -- such a great tool! My problem: Currently I'm working on a quite small project consisting of a few .s files, assembling and linking them together using vasm/vlink (through Amiga-assembly plugin in VSCode). Everything works flawlessly, however when something is wrong it is most probably in a linking phase when linker reports about unsupported relocation (hence why I'm using this thread). Usually I know why it happens yet it is sometimes very hard to figure out the exact line in the code which uses addressing mode which linker has problems with. For example this error line: Error 32: Target amigahunk: Unsupported relocation type R_PC (offset=0, size=16, mask=ffffffffffffffff) at Program+0x27de My guess is that offset exceeds 16bit signed boundary, however it is hard to find which line of code does it since Program section is quite large and offset 0x27de doesn't say much to me. Is there a way how I could be informed about the line of code which violates restriction or about a symbol which is causing it? Maybe the answer is obvious? Thank you. |
04 September 2020, 17:43 | #12 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
In my case I was lucky, vlink had already produced an output file. I used objdump to get a disassembly of the whole thing which gave me the offset plus the corresponding assembly. The offending offset will not directly show up as “line number” as the relocation is part of an instruction, but you’ll get close. Use this as reference in the original sources to lookup the actual offending instruction. Maybe there’s a more elegant way. But this worked for me.
|
04 September 2020, 20:52 | #13 | |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
Quote:
Thank you for your tip! I tried to use objdump to disassemble and to find a generated code which can't be relocated, according to your description. However vasm/vlink package comes with vobjdump which can parse VOBJ format only. In my case, vlink produces a hunk executable from .o files which are not in VOBJ format (by taking a look at vobjdump source code, VOBJ file must begin with a series of magic numbers which my .o files do not...). So this is currently the dead end for me. However your example led me to another way which was successful: Step #1: vlink can produce a mapping file ("-M" parameter). There I could see at which offsets all code sections start. By comparing offset from a vlink error message (e.g. ....at Program+0x636), I could find which code section the error is at and compute a relative offset to the instruction byte. Step #2: vasm can produce a listing file ("-L" parameter). In there, I could see what instruction is at previously computed offset. And voila -- that's my culprit! Yes, it is tedious. Most probably I am missing something. Some obvious way how to find which instruction in my source code the linker can't relocate. P.S.: Can debug info (in .o file) help somehow? |
|
05 September 2020, 02:14 | #14 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
I used objdump from Bebbo’s GCC. It can deal with hunk object files (-Fhunk vasm Option).
But it requires the code section to have the name “.text”. Vasm uses “CODE” by default. The linker may be taught to use debug info to infer the closest symbol and improve the error message, but that’s up to Phx to decide if that would be reasonable to implement. |
05 September 2020, 07:37 | #15 | |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
Quote:
When do you think the recent changes will be reflected in a new release, so I can nag Bebbo to update his toolchain Breathless now compiles and runs...sometimes. I don't know yet what is causing that. I think its an initialization issue. Does this look legitimate to clear the BSS? Code:
GETDBASE MACRO xref _LinkerDB lea _LinkerDB,a5 ENDM GETDBASE ;*** Azzera tutte le variabili della section __MERGED,BSS move.l a5,a0 move.l #LastBSSdata,d0 sub.l a5,d0 lsr.l #2,d0 subq.w #1,d0 clrbss clr.l (a0)+ dbra d0,clrbss |
|
05 September 2020, 12:59 | #16 | ||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
VOBJ is a vasm/vlink internal object file format, which can be used when no other sane object file format exists. It is generally available for all architectures.
For the other object file formats I expect that you have some disassembly tool available. Most reassemblers can also disassemble object files. Quote:
Quote:
Quote:
Quote:
|
||||
05 September 2020, 13:17 | #17 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Quote:
With vlink setting _LinkerDB to __MERGED+32766 I fear that your recompiled version does not really clear the BSS-area and overwrites unallocated memory after that. You are lucky that there are no initialized __MERGED,data sections, so replacing "move.l a5,a0" by "lea -32766(a5),a0" should fix it. Otherwise vlink, like the SAS/C linkers blink and slink, provides symbols for clearing the BSS-part of a small-data section: __BSSBAS (the start address) and __BSSLEN (length in longwords). |
||
05 September 2020, 14:23 | #18 | |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
Quote:
Thank you very much for your reply. I was just worried that I was missing some obvious method and doing things utterly wrong. Fortunately, these relocation errors do not occur often and always are a product of mangling with the code by moving blocks here and there, out of 16bit range. |
|
06 September 2020, 04:32 | #19 |
Zone Friend
Join Date: Mar 2004
Location: Middle Earth
Age: 40
Posts: 2,127
|
Good luck with getting this to assemble. I wouldn't mind seeing a NTSC 320x200 version to get that extra 1-2 fps on a 020.
It seems to be hard coded to PAL. |
18 May 2021, 00:51 | #20 |
Registered User
Join Date: Apr 2020
Location: Pisa/Italy
Posts: 16
|
Sorry for dig this thread up. I manged to compile Breathless under windows using pipper's updated code and phx's latest vasm and vlink. The executable that I get is not working 100% though. It has 3 main issues:
1. no sound effects (title and ingame musics are played correctly) 2. random sky/floor rendering error 3. crashes on exit (error 0x80000006 or 0x8000000B) if launching the game I get the sky/floor rendered properly, it crashes when returning to WB. the opposite, if sky/floor rendering is glitched no crashes when exit. have you encountered any of these? looking at the original source code and comments, point 1 seems affected by ObjectsPunList-4, whereas point 2 takes into account Yoffset+4 several times, but it's pure speculation. No clue how to sort this out. |
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 |
|
|