[fpc-pascal] New VASM upgrade to 1.9d breaks z80-msxdos and z80-zxspectrum builds

[Pierre Muller]

Le 25/04/2023 à 10:40, Karoly Balogh a écrit :
> Hi,
> 
> On Tue, 25 Apr 2023, Pierre Muller via fpc-pascal wrote:
> 
>>     I tested 1.9d version on a test machine,
>> m68k targets are OK, but z80 targets now fail with:
>>
>> Executing "/FPC/compilers/cross-compiling/bin/z80-msxdos-vasmz80_std" with
>> command line "-quiet -Fvobj -o
>> /FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.o
>> /FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si
>> error 39 in line 95 of
>> "/FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.s":
>> illegal relocation
>>   >	.word	.Lc2,.Lc1-.Lc2
>> _prc.s"
>> si_prc.pp(67,4) Error: Error while assembling exitcode 1
>> si_prc.pp(67,4) Fatal: There were 2 errors compiling module, stopping
>> Fatal: Compilation aborted
> 
> I'm not sure it was Nikolay's intention to support vasm for Z80, it was a
> hack from be before the internal assembler existed... -.-'
> 
> Anyway, can you figure out when did it break? Did it work with 1.9c? Which
> was the previous version you used?

   I finally managed to take a look at this issue:
it seems to be related to some 'bug' inside our code:
rtl/zxspectrum/si_prc.pp contains this:

{ this *must* always remain the first procedure with code in this unit }
procedure _start; assembler; nostackframe; public name 'start';
label
   bstart,bend,loop,loop2,our_int_handler,key_int;
asm
     { init the stack }
     ld sp, offset fpc_stackarea_end

.... (Some z80 assembly code removed *)
     { When using the SDCC-SDLDZ80 linker, the first object module defines the
       order of areas (sections). Since this module contains the startup code,
       it is loaded first, so we define all the sections we use in the proper
       order. }
     area '_DATA'
     area '_BSS'
bstart:
     area '_BSSEND'
bend:
     area '_HEAP'
     area '_STACK'
     area '_CODE'
end;

end.

The problem is that the assembly always generates some .debug_frame section,
even if -g- is used, and this section contains:
	.word	.Lc2,.Lc1-.Lc2
With .Lc2 being the start of _start code, and .Lc1 supposed to be at the end of _start.

But the area pseudo-instructions do generate new .section instructions,
which lead vasmz80_std to rightfully consider that
  .Lc1-.Lc2 is illegal because the two labels do not belong to the same section anymore...

The problem is that I have no idea how to fix this issue...
Would it be possible to move the area pseudo-instructions elsewhere?

Pierre


PS:
   Copying the .section entry of _start right before .Lc1 (like below) fixes the assembly using vasmz80_std

         .section .text.n_si_prc_$$__start,"acrx"
.Lc1:

Pierre