Listfiles become garbage when using .include

[Stewmath]

I came across this while browsing snesdev. I noticed a user ranting about a feature I hadn't ever tried before:

The one huge (and I mean HUGE HUGE HUGE) advantage ca65 has over WLA DX is that it's listing generation mode actually works, while WLA DX acts like a complete moron when you use .include (or is it .incsrc) within an assembly file -- the listing generation contains interspersed output (and this is still the case on the most recent WLA DX github build too). I STRONGLY advocate using listing files, because they help you diagnose issues in your code; "I expected the assembler to do this, but it's doing this instead".

So, this looks like it could be a handy feature. But this is what mine looks like:

                                        ;; The main file containing all the code in the game.
                                        ;;

                                        .include "include/rominfo.s"
                                        .include "include/constants.s"
                                        .include "include/structs.s"
                                        .include "include/wram.s"
$21 $15 $43                             .include "include/hram.s"
$21 $92 $5E                             .include "include/macros.s"
$21 $09 $48                             .include "include/script_commands.s"
$21 $09 $48                             .include "include/simplescript_commands.s"
$21 $92 $5E                             
$21 $DD $69                             .include "objects/macros.s"
$21 $5C $41                             .include "include/gfxDataMacros.s"
$21 $F7 $41                             .include "include/musicMacros.s"
$21 $77 $78                             
$21 $F7 $41                             .include "build/textDefines.s"
$21 $A3 $5E                             
$21 $97 $5D                             
$21 $9F $5D                             .BANK $00 SLOT 0
$21 $F7 $41                             
$21 $F7 $41                             .ORGA $0000
$21 $2D $46                             ; rst_jumpTable
$21 $2D $46                                 add a           ; $0000

Yeah, this makes no sense at all. It does work for some of the sample projects, but I guess the .include directive is breaking it here. Though I haven't verified if that's truly the culprit.

[crzysdrs]

I am also encountering an issue with listfiles and includes and I believe this to be of a similar root cause.

Attempting to assemble "10-bit ops.s" from the GB Rom Tests CPU Instrs suite (http://gbdev.gg8.se/files/roms/blargg-gb-tests/) with listfiles enabled will crash wlalink.

Makefile:

all: test.gb

test.o:
    wla-gb -i -o test.o "10-bit ops.s"

test.gb: test.o
    wlalink -i linkfile test.gb

StackTrace of wlalink:

Program received signal SIGSEGV, Segmentation fault.
0x00005555555678f4 in listfile_write_listfiles (e=0x5555557a6960)
    at /home/crzysdrs/downloads/wla-dx-9.7/wlalink/listfile.c:159
(gdb) bt
#0  0x00005555555678f4 in listfile_write_listfiles (e=0x5555557a6960)
    at /home/crzysdrs/downloads/wla-dx-9.7/wlalink/listfile.c:159
#1  0x0000555555557c47 in main (argc=4, argv=0x7fffffffe4d8)
    at /home/crzysdrs/downloads/wla-dx-9.7/wlalink/main.c:485

The issue appears to be a confusion about line numbering, it keeps looking for line number 90 in an 80 line file until hits the end of the file buffer and crashes.

[vhelin]

Finally, after all these years, I managed to get here. :) Just tried with the latest sources (29-May-2019):

$ ../../wla-dx-master-2/binaries/wla-gb.exe -v -i -o 10-bit\ ops.o 10-bit\ ops.s Pass 1... Directive checks... Internal pass 1... Internal pass 2... Free space at $0000-$00ff. Free space at $0134-$0142. Free space at $0144-$0146. Free space at $0149-$01ff. Free space at $0219-$3fff. Free space at $4ae2-$7fff. Bank 00 has 16304 bytes (99.51%) free. Bank 01 has 13598 bytes (83.00%) free. 29902 unused bytes of total 32768.

Seems to assemble just fine. I'll try to look more into this, somehow, some way...

[vhelin]

Uh, yes, it seems that WLALINK segfaults... Sorry, I've had a few too many beers this evening, missed that information. :) Anyway, I'm on it!

[vhelin]

I'm not 100% certain, but when you make a macro M call in file A, and macro M is in file B, macro M's lines are put to listfile as they were in file A... This is what it looks like. I just need to handle macro calls correctly when outputting listfile data?

[vhelin]

I found other problems in listfile generation, hopefully I got them all... Anyway, if you try the latest sources, will listfile generation work better than before?

I had to disable listfile generation for .REPEATs and macro calls as they would easily flood the listfiles with data...

[vhelin]

This is one of the bugs I want to fix before releasing WLA DX v9.8 final... So the faster anyone can test this and close, the faster we'll have v9.8 final out. :)

[cr1901]

@vhelin I just wanted to thank you for your hard work, and congrats on the imminent release of 9.8! :D

[crzysdrs]

It doesn't crash anymore which is an improvement but I am running the original testcase I described and I am a little confused by the output. There appears to be only two generated listfiles (renamed to .txt): build_rom.txt console.txt

Neither of these listfiles contains the instructions I want to see which should be listed for the files common/instr_test.s which includes the main entry point or the testing code from 10-bit_ops.s. Is there something I am missing?

[vhelin]

Currently WLA DX cannot generate listfile information for code that is outside sections, so you'll need to put common/instr_test.s's code inside a section to get any listfile data for it...

[vhelin]

@vhelin I just wanted to thank you for your hard work, and congrats on the imminent release of 9.8! :D

Thanks! :) It's been a long time since v9.7's release and the CHANGELOG has grown long since then...

[vhelin]

The fastest way to get a listfile for common/instr_test.s would be to put its code inside

.section "main" force ... .ends

[vhelin]

If anyone could test this (and possibly close) before 8th of June 2019, that'd be great as I'll be at my parents' cottage then and could compile final v9.8 binaries for Windows. If the v9.8 final relase goes beyond that I don't know when I'm going to visit them... They have a Windows 7 computer I'd use to make the exes. I only have a modern Windows 10 computer at home myself.

[vhelin]

I'll close this as to my eye the list file generator works now much better than before. If you have more issues regarding list file, please open a new issue here in GitHub.