Dave's nasmjf Dev Log 03

    Picking up at the error discovered in the last log,
    we need to figure out what's happening to the string
    stored at the label 'errmsg'.

    (I keep having to re-learn that GBD needs an '&' before
    a label for it to be used as an address expression,
    otherwise it uses the value _at_ that label. Hope I remember
    it this time after fumbling around for a while...which is
    not pictured here.)

    The string is correct ("PARSE ERROR: ") when the program starts.
    (Though it looks like I didn't get the newline escape right
    in NASM because I have a literal '\n' in my string!"

Reading symbols from nasmjf...
(gdb) info addr errmsg
Symbol "errmsg" is at 0x804a315 in a file compiled without debugging.
(gdb) x/20c &errmsg
0x804a315 <errmsg>:     80 'P'  65 'A'  82 'R'  83 'S'  69 'E'  32 ' '  69 'E'  82 'R'
0x804a31d:      82 'R'  79 'O'  82 'R'  58 ':'  32 ' '  92 '\\' 110 'n' 0 '\000'
0x804a325:      0 '\000'        0 '\000'        0 '\000'        0 '\000'

    I set a watchpoint on the label and run it.

(gdb) watch (int)errmsg
Watchpoint 2: (int)errmsg
(gdb) c
Continuing.
foo

Watchpoint 2: (int)errmsg

Old value = 1397899600
New value = 1392508928
code_INTERPRET () at nasmjf.asm:214
214         call _FIND              ; Returns %eax = pointer to header or 0 if not found.
(gdb)

    Okay, so I guess that means that the line _before_ 214 must
    be the culprit. Ah, yeah. That looks likely because here's
    how the memory is reserved:

        interpret_is_lit: db 0        ; 1 means "reading a literal"
        errmsg: db "PARSE ERROR: "

    And here's the line before 214:

        mov [interpret_is_lit], eax ; 0 means not a literal number (yet)

    Yup, that sure makes sense! We reserved a byte for the
    interpret_is_lit flag, but eax is a full word (4 bytes),
    so the flag is getting set _and_ the remaining three
    bytes clobber the string in errmsg. It's things like this that
    make a person appreciate the safety features of higher
    level languages.

    Angway, the data size was "int" in the JonesForth GAS original.
    So mine should be 'w' for word:

        interpret_is_lit: dw 0        ; 1 means "reading a literal"

    Let's try it:

(gdb) file nasmjf
Reading symbols from nasmjf...
(gdb) break 271
Note: breakpoints 3, 4 and 5 also set at pc 0x80490ba.
Breakpoint 6 at 0x80490ba: file nasmjf.asm, line 271.
(gdb) r
Starting program: /home/dave/nasmjf/nasmjf
foo

Breakpoint 3, code_INTERPRET.parse_error () at nasmjf.asm:271
271         int 80h
PARSE ERROR:

    Yay, that's restored the PARSE ERROR string.
    Unfortunately, it still ends in a segfault.
    Oops! Both the errmsgnl and __NR_write labels
    should be the addresses, not the values at the
    addresses at lines 284 and 286.

273         mov [currkey],ecx       ; the error occurred just before currkey position
274         mov edx,ecx
275         sub edx,buffer          ; edx = currkey - buffer (length in buffer before currkey)
276         cmp edx,40              ; if > 40, then print only 40 characters
277         jle .print_error
code_INTERPRET.print_error () at nasmjf.asm:280
280         sub ecx,edx             ; ecx = start of area to print, edx = length
281         mov eax,__NR_write      ; write syscall
282         int 80h
284         mov ecx,[errmsgnl]      ; newline
285         mov edx,1               ; 1 char long
286         mov eax,[__NR_write]    ; write syscall

Program received signal SIGSEGV, Segmentation fault.

    Okay, easy fix. I also noticed I stll had the operands
    transposed on line 273. And I swapped out the double
    quotes around the errmsgnl string literal to backquotes
    as required by NASM for backslash escape support.

    Let's see how it goes now:

Continuing.
foo
PARSE ERROR: foo

[Inferior 1 (process 2582) exited normally]

    Yay!