* [TUHS] OT: compiler back-end bug @ 2019-09-29 9:21 Warren Toomey 2019-09-29 9:47 ` Ralph Corderoy 0 siblings, 1 reply; 6+ messages in thread From: Warren Toomey @ 2019-09-29 9:21 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] OT: compiler back-end bug 2019-09-29 9:21 [TUHS] OT: compiler back-end bug Warren Toomey @ 2019-09-29 9:47 ` Ralph Corderoy 2019-09-29 10:03 ` Warren Toomey 0 siblings, 1 reply; 6+ messages in thread From: Ralph Corderoy @ 2019-09-29 9:47 UTC (permalink / raw) To: tuhs 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] OT: compiler back-end bug 2019-09-29 9:47 ` Ralph Corderoy @ 2019-09-29 10:03 ` Warren Toomey 2019-09-29 10:50 ` Ralph Corderoy 0 siblings, 1 reply; 6+ messages in thread From: Warren Toomey @ 2019-09-29 10:03 UTC (permalink / raw) To: Ralph Corderoy; +Cc: tuhs 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] OT: compiler back-end bug 2019-09-29 10:03 ` Warren Toomey @ 2019-09-29 10:50 ` Ralph Corderoy 2019-10-03 20:03 ` Steve Johnson 0 siblings, 1 reply; 6+ messages in thread From: Ralph Corderoy @ 2019-09-29 10:50 UTC (permalink / raw) To: tuhs 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] OT: compiler back-end bug 2019-09-29 10:50 ` Ralph Corderoy @ 2019-10-03 20:03 ` Steve Johnson 2019-10-03 20:03 ` Nemo Nusquam 0 siblings, 1 reply; 6+ messages in thread From: Steve Johnson @ 2019-10-03 20:03 UTC (permalink / raw) To: Ralph Corderoy, tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] OT: compiler back-end bug 2019-10-03 20:03 ` Steve Johnson @ 2019-10-03 20:03 ` Nemo Nusquam 0 siblings, 0 replies; 6+ messages in thread From: Nemo Nusquam @ 2019-10-03 20:03 UTC (permalink / raw) To: tuhs 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.) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-03 20:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-29 9:21 [TUHS] OT: compiler back-end bug Warren Toomey 2019-09-29 9:47 ` Ralph Corderoy 2019-09-29 10:03 ` Warren Toomey 2019-09-29 10:50 ` Ralph Corderoy 2019-10-03 20:03 ` Steve Johnson 2019-10-03 20:03 ` Nemo Nusquam
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).