#3765 .lst assembled without -p option incompatible with .rst generation

[Mariusz]

HI,
Last releases has problem with compilation code as is attached.

We have resulat as:

  00022A                        294 dispadd:
  000324 **E5 7E**            [ 7]  295         LD A, #'['
  000326 FE 00 FE         [17]  296         CALL _putchar

and

  000318 **95 01**            [ 7]  272                 CP      a, #eos  
  00031A **CD 23**            [ 7]  273                 CP  a, #0

Of course selected values are wrong and bin doesn't work.
What is happend?

[Philipp Klaus Krause]

Please provide instruction on how to reproduce the issue.

When assembling your memtest.asm on my Debian GNU/Linux testing system using sdasz80 -plosgff from current trunk, I get:

    0000021B FE 00            [ 7]  272                 CP      a, #eos  
    0000021D FE 00            [ 7]  273                 CP  a, #0               ; End of string reached?

That looks okay to me.

[Mariusz]

It is last release 4.4 for Win32 and Win64.

Compilation way is like it:

sdasz80 -l -o -s .\debug\memtest.rel memtest.asm

And is producted memtest.rst file like that.

  000318 95 01            [ 7]  272                 CP      a, #eos  
  00031A CD 23            [ 7]  273                 CP  a, #0               ; End of string reached?
  00031C 03 E1            [12]  274                 jr      z, puts_end     ; Yes
  00031E C9 00 00         [17]  275                 call    _putchar

  But memtest.lst

        00021B FE 00            [ 7]  272                 CP      a, #eos  
  00021D FE 00            [ 7]  273                 CP  a, #0               ; End of string reached?
  00021F 28 06            [12]  274                 jr      z, puts_end     ; Yes
  000221 CD 00 00         [17]  275                 call    _putchar
  000224 23               [ 6]  276                 inc     hl              ; Increment character pointer
  000225 18 F3            [12]  277                 jr      puts_loop       ; Transmit next character
  000227 E1               [10]  278 puts_end:       pop     hl
  000228 F1               [10]  279                 pop     af
  000229 C9               [10]  280                 ret

  Code doesn't work.

  I attached all project. make.bat launch all process. Marius

[Janko Stamenović]

The .rst is produced by linker and it doesn't have to mean that the linked binary code corresponds to what is in that .rst, just comparing the .lst and .rst I could imagine it's an error in processing the .lst to .rst which could be independent from other generated files: specifically, it seems that during that processing the part of the "page header" is matched by the ".lst to .rst" processing routine (wrongly considered as the code that should be "fixed" using the rellocations) and that confuses all the values that happen afterwards:

@@ -122 +122 @@
-Hexadecimal [24-Bits]
+Hexadecimal  65-Bits]

P.S. for the example to run, the following file has to be added:

screen.h

  void clrscr(void);

To state more clearly: it doesn't seem to me that the binary code contains the specific errors which exist in the .rst:

in the .bin it's: "ern \0Read"

000000b0: 7373 2000 2077 6974 6820 6269 7420 7061  ss . with bit pa
000000c0: 7474 6572 6e20 0052 6561 6420 616e 6420  ttern .Read and 

int the .rst it's: "ern rn \0Read" (i.e. an insertion of additional 'r' 'n' and space) which can't be seen in the binary:

      0001B4 20 77 69 74 68 20 62   100 MSGBITS:     .ascii   " with bit pattern "
             69 74 20 70 61 74 74
ASxxxx Assembler V02.00 + NoICE + SDCC mods  (Zilog Z80 / Hitachi HD64180 / ZX-Next / eZ80 / R800)                          Page 3
Hexadecimal  65-Bits]



             65 72 6E 20
      0001C3 72                     101              .db eos
      0001C4 6E 20 00 52 65 61 64   102 MSG00:       .ascii   "Read and write 

[Mariusz]

When .ascii directive is exchanged with .str directive whole *.rst file looks well.

I use *.rst files for looking bugs, because addresses help locate place on system under debuging.

[Janko Stamenović]

When .ascii directive is exchanged with .str directive whole *.rst file looks well.

Thanks. Is the only issue the wrong .rst after linking or is there some other issue still observable now?

[Mariusz]

Subject is still under observation...

[Mariusz]

Probably it is badly generated *.rst file only.

[Janko Stamenović]

Checking this further, the simple workaround to avoid the bug you observe is to use the -p option when assembling:

Instead:

sdasz80  -l -o -s .\debug\memtest.rel memtest.asm

use

sdasz80  -plos .\debug\memtest.rel memtest.asm

There p means " Disable automatic listing pagination", and "los create ".lst" ".rel" (a.k.a "object") and ".sym" files, which you already used as -l -o -s.

Note: Philipp used for his test the p option and therefore hasn't observed any problem.

Maybe it's not worth attempting to fix this in SDCC now because, if I understand, there is some work in progress to synchronize with the more recent upstream versions of assembler and linker code, and the more recent version of ASxxxx has since 2019 a "rewrite" of the .rst translation:

https://shop-pdp.net/ashtml/aschng.htm

January 2019 Version 5.3
...
   (3)  General linker updates
        fix library path file strings
        rewrite of .lst to .rst translation

[Philipp Klaus Krause]

I see @b-s-a is the owner of this ticket. But I don't see when he assigned this to himself (usually, when the owner of a ticket gets changed, there is an entry, e.g. "assigned_to: Philipp Klaus Krause" or so at the end of one of the replies for when I assign a ticket to myself). What happened?

[Maarten Brock]

The creator @Mariusz of this ticket already assigned the owner at creation.
This should not be possible IMHO but SourceForge allows it.
It should not be up to the creator of the ticket to assign people unless they are willing to pay them a salary. And otherwise it is up to the volunteers to pick up a ticket to work on.

[Janko Stamenović]

Maybe the description of this could be ".lst assembled without -p option incompatible with .rst generation"?

[Philipp Klaus Krause]

Yes; I changed the title.