From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id dd8d70fb for ; Thu, 3 Oct 2019 20:04:31 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 211199BCCD; Fri, 4 Oct 2019 06:04:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 14AA99BC99; Fri, 4 Oct 2019 06:04:09 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=yaccman.com header.i=@yaccman.com header.b="dlCdTrEI"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id E05E29BC99; Fri, 4 Oct 2019 06:04:06 +1000 (AEST) Received: from baboon.elm.relay.mailchannels.net (baboon.elm.relay.mailchannels.net [23.83.212.8]) by minnie.tuhs.org (Postfix) with ESMTPS id 6F9E49BC98 for ; Fri, 4 Oct 2019 06:04:05 +1000 (AEST) X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8A86F6A248F; Thu, 3 Oct 2019 20:04:04 +0000 (UTC) Received: from pdx1-sub0-mail-a98.g.dreamhost.com (100-96-35-138.trex.outbound.svc.cluster.local [100.96.35.138]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BA7C26A2486; Thu, 3 Oct 2019 20:04:03 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com Received: from pdx1-sub0-mail-a98.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Thu, 03 Oct 2019 20:04:04 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: dreamhost|x-authsender|scj@yaccman.com X-MailChannels-Auth-Id: dreamhost X-Tank-Relation: 66cc4748564ab848_1570133044257_3475472088 X-MC-Loop-Signature: 1570133044256:3702949885 X-MC-Ingress-Time: 1570133044256 Received: from pdx1-sub0-mail-a98.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a98.g.dreamhost.com (Postfix) with ESMTP id DA23F7F216; Thu, 3 Oct 2019 13:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=yaccman.com; h=message-id :from:to:in-reply-to:subject:date:content-type:mime-version; s= yaccman.com; bh=DtX0QwYjqUQsUDIq4Quw06aYr2Q=; b=dlCdTrEIkjbbQlHY FFRD14qN8W4jzyCU/DfYIbc3txytFWwiQ0jo0R00oj0cmU7dTgebq6MEMyJe6kAv KwpDp9CQqGxnlfNhLn5mDWBYut/2rjrdBBBjwx73M8L90Eh+xzy+lTDUz4j0CE49 mCrt9fMxQH4nGPu3YQvHgmnkCEQ= Received: from localhost (ip-66-33-200-4.dreamhost.com [66.33.200.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: scj@yaccman.com) by pdx1-sub0-mail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 6ED167F212; Thu, 3 Oct 2019 13:03:57 -0700 (PDT) Message-Id: <6696fb88a31a97eeae2c0f9970476ff6aa55e9d4@webmail.yaccman.com> X-DH-BACKEND: pdx1-sub0-mail-a98 From: "Steve Johnson" To: "Ralph Corderoy" , tuhs@tuhs.org X-Mailer: Atmail 7.8.0.2 X-Originating-IP: 10.35.42.221 in-reply-to: <20190929105016.92665200AB@orac.inputplus.co.uk> Date: Thu, 03 Oct 2019 13:03:57 -0700 Content-Type: multipart/alternative; boundary="=_fa7ccd6bee061328f3717e68c3c8a0cd" MIME-Version: 1.0 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrgeekgddugeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvffoihgjuffftgggsegrtderreertdejnecuhfhrohhmpedfufhtvghvvgculfhohhhnshhonhdfuceoshgtjheshigrtggtmhgrnhdrtghomheqnecuffhomhgrihhnpehtuhhhshdrohhrghenucfkphepieeirdeffedrvddttddrgedpuddtrdefhedrgedvrddvvddunecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepieeirdeffedrvddttddrgedprhgvthhurhhnqdhprghthhepfdfuthgvvhgvucflohhhnhhsohhnfdcuoehstghjseihrggttghmrghnrdgtohhmqedpmhgrihhlfhhrohhmpehstghjseihrggttghmrghnrdgtohhmpdhnrhgtphhtthhopehtuhhhshesthhuhhhsrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd Subject: Re: [TUHS] OT: compiler back-end bug X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --=_fa7ccd6bee061328f3717e68c3c8a0cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0AI have all to much experience with back end bugs, usually when someon= e=0Aporting PCC asked for help.=0A=0AThe advice I always gave first was:= =C2=A0 "what would the correct output=0Alook like?"=0A=0A90% of the time= , they didn't know.=C2=A0 And it's hard to hit the target=0Aif you don't= know where it is...=0A=0AOnce you know what you want, then you figure o= ut the first instruction=0Athat isn't right and hit it with everything y= ou have...=0A=0AHope this helps...=0A=0ASteve=0A=0A----- Original Messag= e -----=0AFrom: "Ralph Corderoy" =0ATo:=0ACc:=0ASent:Sun, 29 Sep 2019 11:50:16 +0100=0ASubject:Re: [TUHS]= OT: compiler back-end bug=0A=0A Hi Warren,=0A=0A > Good point Ralph:=0A= >=0Ahttps://minnie.tuhs.org/wktcloud/index.php/s/HQjsggHb4i6wdWM?path= =3D%2FSfiles=0A=0A I've always tried to avoid x86 and friends for ARM, s= o I may be=0Awrong,=0A but the run up to the first of the two memcpy() c= alls looks the same=0Ato=0A me. Here's the assembler, values given an RB= P of 100, and the stack=0A contents. Good version first, bad second.=0A= =0A rbp =3D 100=0A L29:=0A movq -8(%rbp),%rax rax =3D *92=0A pushq %rax= *92=0A movq 16(%rbp),%rax rax =3D *116=0A pushq %rax *92 *116=0A movq $= 64,%rax rax =3D 64=0A pushq %rax *92 *116 64=0A movq 32(%rbp),%rax rax= =3D *132=0A popq %rcx rcx =3D 64 *92 *116=0A addq %rcx,%rax rcx =3D 64+= *132=0A movq (%rax),%rax rax =3D *(64+*132)=0A pushq %rax *92 *116 *(64+= *132)=0A movq $40,%rax rax =3D 40=0A pushq %rax *92 *116 *(64+*132) 40= =0A movq 32(%rbp),%rax rax =3D *132=0A popq %rcx rcx =3D 40 *92 *116 *(6= 4+*132)=0A addq %rcx,%rax rax =3D 40+*132=0A movq (%rax),%rax rax =3D *(= 40+*132)=0A popq %rcx rcx =3D *(64+*132) *92 *116=0A addq %rcx,%rax rax= =3D *(64+*132)+*(40+*132)=0A pushq %rax *92 *116 *(64+*132)+*(40+*132)= =0A call Cmemcpy=0A=0A rbp =3D 100=0A L29:=0A movq -8(%rbp),%r8 r8 =3D *= 92=0A pushq %r8 *92=0A movq 16(%rbp),%r8 r8 =3D *116=0A pushq %r8 *92 *1= 16=0A movq $64,%r8 r8 =3D 64=0A movq 32(%rbp),%r9 r9 =3D *132=0A addq %r= 9,%r8 r8 =3D *132+64=0A movq (%r8),%r8 r8 =3D *(*132+64)=0A movq $40,%r9= r9 =3D 40=0A movq 32(%rbp),%r10 r10 =3D *132=0A addq %r10,%r9 r9 =3D *1= 32+40=0A movq (%r9),%r9 r9 =3D *(*132+40)=0A addq %r9,%r8 r8 =3D *(*132+= 64)+*(*132+40)=0A pushq %r8 *92 *116 *(*132+64)+*(*132+40)=0A call Cmemc= py=0A=0A A glance at the second memcpy() call look equivalent too.=0A=0A= So perhaps it's not calculating the parameters to memcpy() that's=0Awro= ng,=0A but the inputs into those calculations being faulty? I'd use gdb(= 1)=0Ato=0A break at particular instructions, examine memory, etc., to wo= rk=0A backwards through the bad version until spotting where good data= =0Abecomes=0A bad.=0A=0A -- =0A Cheers, Ralph.=0A=0A --=_fa7ccd6bee061328f3717e68c3c8a0cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have all to much experience with back end bugs, usually w= hen someone porting PCC asked for help.

The adv= ice I always gave first was:=C2=A0 "what would the correct output look l= ike?"

90% of the time, they didn't know.=C2=A0= And it's hard to hit the target if you don't know where it is...
<= div>
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



----- Origi= nal Message -----
From:
"Ralph Corderoy" <ralph@input= plus.co.uk>

To:
<tuhs@tuhs.org>
Cc:

Sent:Sun, 29 Sep 2019 11:50:16 +0100
Subject:
Re: [TUHS= ] OT: compiler back-end bug


=0AHi Warren,

=0A> Good= point Ralph:
=0A> https://minnie.tuhs.org/wktcloud/index.php/s/HQ= jsggHb4i6wdWM?path=3D%2FSfiles

=0AI've always tried to avoid x86= and friends for ARM, so I may be wrong,
=0Abut the run up to the fir= st of the two memcpy() calls looks the same to
=0Ame. Here's the ass= embler, values given an RBP of 100, and the stack
=0Acontents. Good= version first, bad second.

=0A rb= p =3D 100
=0A L29:
=0A movq -8(%rbp),%rax rax =3D *= 92
=0A pushq %rax *= 92
=0A movq 16(%rbp),%rax rax =3D *116
=0A push= q %rax *92 *116
=0A = movq $64,%rax rax =3D 64
=0A pushq %rax = *92 *116 64
=0A movq 32(%rb= p),%rax rax =3D *132
=0A popq %rcx rcx =3D 6= 4 *92 *116
=0A addq %rcx,%rax rc= x =3D 64+*132
=0A movq (%rax),%rax rax =3D *(64+*132)=0A pushq %rax *92 *= 116 *(64+*132)
=0A movq $40,%rax rax =3D 40
=0A = pushq %rax *92 *116 *(= 64+*132) 40
=0A movq 32(%rbp),%rax rax =3D *132
=0A = popq %rcx rcx =3D 40 *92 *116 *= (64+*132)
=0A addq %rcx,%rax rax =3D 40+*132
=0A = movq (%rax),%rax rax =3D *(40+*132)
=0A popq %r= cx rcx =3D *(64+*132) *92 *116
=0A a= ddq %rcx,%rax rax =3D *(64+*132)+*(40+*132)
=0A pushq= %rax *92 *116 *(64+*132)+*(4= 0+*132)
=0A call Cmemcpy

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

=0AA glance at the second memcpy(= ) call look equivalent too.

=0ASo perhaps it's not calculating th= e parameters to memcpy() that's wrong,
=0Abut the inputs into those c= alculations being faulty? I'd use gdb(1) to
=0Abreak at particular i= nstructions, examine memory, etc., to work
=0Abackwards through the b= ad version until spotting where good data becomes
=0Abad.

=0A-= -
=0ACheers, Ralph.

--=_fa7ccd6bee061328f3717e68c3c8a0cd--