[TUHS] OT: compiler back-end bug

[TUHS] OT: compiler back-end bug

[Warren Toomey]

All, very off-topic for TUHS but you have a bounty of experience. If any
of you have Intel ia64 skills and/or fixing compiler back-end bugs, could
you contact me off-list? I'm writing a back-end for the SubC compiler and
I have 'one last bug'™ before it can compile itself, and I'm stuck.

Details at: https://minnie.tuhs.org/wktcloud/index.php/s/QdKZAqcBytoFBkQ/download?path=%2F&files=help.txt

Thanks, Warren

Re: [TUHS] OT: compiler back-end bug

[Ralph Corderoy]

Hi Warren,

> If any of you have Intel ia64 skills and/or fixing compiler back-end
> bugs, could you contact me off-list?

Sorry, on list, but it may help the willing eyeballs if

> To see the original compiler's assembly version of fwrite():
>
>         $ ./scc0 -S lib/fwrite.c
>
> To see my compiler's [faulty] assembly version of fwrite():
>
>         $ ./myscc -S lib/fwrite.c

these two were made easily available, e.g. a pastebin like 

    curl -sSF 'f:1=<-' ix.io <lib/fwrite.c

as then spotting the cause of

> At present, my compiler fwrite() code is passing bogus arguments to
> memcpy() where it crashes with a segfault.

wouldn't involve downloads, make, etc., that make it easy to think one
doesn't have the time to look.  :-)

-- 
Cheers, Ralph.

Re: [TUHS] OT: compiler back-end bug

[Warren Toomey]

On Sun, Sep 29, 2019 at 10:47:26AM +0100, Ralph Corderoy wrote:
> these two were made easily available, e.g. a pastebin like 
> wouldn't involve downloads, make, etc., that make it easy to think one
> doesn't have the time to look.  :-)

Good point Ralph:
https://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path=%2FSfiles

Thanks! Warren

Re: [TUHS] OT: compiler back-end bug

[Ralph Corderoy]

Hi Warren,

> Good point Ralph:
> https://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path=%2FSfiles

I've always tried to avoid x86 and friends for ARM, so I may be wrong,
but the run up to the first of the two memcpy() calls looks the same to
me.  Here's the assembler, values given an RBP of 100, and the stack
contents.  Good version first, bad second.

                                rbp = 100
    L29:
        movq  -8(%rbp),%rax     rax = *92
        pushq %rax                                            *92
        movq  16(%rbp),%rax     rax = *116
        pushq %rax                                            *92 *116
        movq  $64,%rax          rax = 64
        pushq %rax                                            *92 *116 64
        movq  32(%rbp),%rax     rax = *132
        popq  %rcx              rcx = 64                      *92 *116
        addq  %rcx,%rax         rcx = 64+*132
        movq  (%rax),%rax       rax = *(64+*132)
        pushq %rax                                            *92 *116 *(64+*132)
        movq  $40,%rax          rax = 40
        pushq %rax                                            *92 *116 *(64+*132) 40
        movq  32(%rbp),%rax     rax = *132
        popq  %rcx              rcx = 40                      *92 *116 *(64+*132)
        addq  %rcx,%rax         rax = 40+*132
        movq  (%rax),%rax       rax = *(40+*132)
        popq  %rcx              rcx = *(64+*132)              *92 *116
        addq  %rcx,%rax         rax = *(64+*132)+*(40+*132)
        pushq %rax                                            *92 *116 *(64+*132)+*(40+*132)
        call  Cmemcpy

                                rbp = 100
    L29:
        movq  -8(%rbp),%r8      r8 = *92
        pushq %r8                                             *92
        movq  16(%rbp),%r8      r8 = *116
        pushq %r8                                             *92 *116
        movq  $64,%r8           r8 = 64
        movq  32(%rbp),%r9      r9 = *132
        addq  %r9,%r8           r8 = *132+64
        movq  (%r8),%r8         r8 = *(*132+64)
        movq  $40,%r9           r9 = 40
        movq  32(%rbp),%r10     r10 = *132
        addq  %r10,%r9          r9 = *132+40
        movq  (%r9),%r9         r9 = *(*132+40)
        addq  %r9,%r8           r8 = *(*132+64)+*(*132+40)
        pushq %r8                                             *92 *116 *(*132+64)+*(*132+40)
        call  Cmemcpy

A glance at the second memcpy() call look equivalent too.

So perhaps it's not calculating the parameters to memcpy() that's wrong,
but the inputs into those calculations being faulty?  I'd use gdb(1) to
break at particular instructions, examine memory, etc., to work
backwards through the bad version until spotting where good data becomes
bad.

-- 
Cheers, Ralph.

Re: [TUHS] OT: compiler back-end bug

[Steve Johnson]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]


I have all to much experience with back end bugs, usually when someone
porting PCC asked for help.

The advice I always gave first was:  "what would the correct output
look like?"

90% of the time, they didn't know.  And it's hard to hit the target
if you don't know where it is...

Once you know what you want, then you figure out the first instruction
that isn't right and hit it with everything you have...

Hope this helps...

Steve

----- Original Message -----
From: "Ralph Corderoy" <ralph@inputplus.co.uk>
To:<tuhs@tuhs.org>
Cc:
Sent:Sun, 29 Sep 2019 11:50:16 +0100
Subject:Re: [TUHS] OT: compiler back-end bug

 Hi Warren,

 > Good point Ralph:
 >
https://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path=%2FSfiles

 I've always tried to avoid x86 and friends for ARM, so I may be
wrong,
 but the run up to the first of the two memcpy() calls looks the same
to
 me. Here's the assembler, values given an RBP of 100, and the stack
 contents. Good version first, bad second.

 rbp = 100
 L29:
 movq -8(%rbp),%rax rax = *92
 pushq %rax *92
 movq 16(%rbp),%rax rax = *116
 pushq %rax *92 *116
 movq $64,%rax rax = 64
 pushq %rax *92 *116 64
 movq 32(%rbp),%rax rax = *132
 popq %rcx rcx = 64 *92 *116
 addq %rcx,%rax rcx = 64+*132
 movq (%rax),%rax rax = *(64+*132)
 pushq %rax *92 *116 *(64+*132)
 movq $40,%rax rax = 40
 pushq %rax *92 *116 *(64+*132) 40
 movq 32(%rbp),%rax rax = *132
 popq %rcx rcx = 40 *92 *116 *(64+*132)
 addq %rcx,%rax rax = 40+*132
 movq (%rax),%rax rax = *(40+*132)
 popq %rcx rcx = *(64+*132) *92 *116
 addq %rcx,%rax rax = *(64+*132)+*(40+*132)
 pushq %rax *92 *116 *(64+*132)+*(40+*132)
 call Cmemcpy

 rbp = 100
 L29:
 movq -8(%rbp),%r8 r8 = *92
 pushq %r8 *92
 movq 16(%rbp),%r8 r8 = *116
 pushq %r8 *92 *116
 movq $64,%r8 r8 = 64
 movq 32(%rbp),%r9 r9 = *132
 addq %r9,%r8 r8 = *132+64
 movq (%r8),%r8 r8 = *(*132+64)
 movq $40,%r9 r9 = 40
 movq 32(%rbp),%r10 r10 = *132
 addq %r10,%r9 r9 = *132+40
 movq (%r9),%r9 r9 = *(*132+40)
 addq %r9,%r8 r8 = *(*132+64)+*(*132+40)
 pushq %r8 *92 *116 *(*132+64)+*(*132+40)
 call Cmemcpy

 A glance at the second memcpy() call look equivalent too.

 So perhaps it's not calculating the parameters to memcpy() that's
wrong,
 but the inputs into those calculations being faulty? I'd use gdb(1)
to
 break at particular instructions, examine memory, etc., to work
 backwards through the bad version until spotting where good data
becomes
 bad.

 -- 
 Cheers, Ralph.



[-- Attachment #2: Type: text/html, Size: 4510 bytes --]

Re: [TUHS] OT: compiler back-end bug

[Nemo Nusquam]

On 10/03/19 16:03, Steve Johnson wrote (in part):
> Once you know what you want, then you figure out the first instruction 
> that isn't right and hit it with everything you have...
+42

N.

(And sorry, Warren, I haven't written iapx assembler in over a decade.)