From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12564 invoked by alias); 18 Oct 2006 05:41:59 -0000 Received: (qmail 12553 invoked by uid 22791); 18 Oct 2006 05:41:57 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp04.au.ibm.com (HELO ausmtp04.au.ibm.com) (202.81.18.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Oct 2006 05:41:53 +0000 Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [202.81.18.225]) by ausmtp04.au.ibm.com (8.13.8/8.13.5) with ESMTP id k9I5pWp4271946 for ; Wed, 18 Oct 2006 15:51:32 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0109e.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9I5j1JX125098 for ; Wed, 18 Oct 2006 15:45:08 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9I5bGvh028679 for ; Wed, 18 Oct 2006 15:37:16 +1000 Received: from [9.181.133.215] ([9.181.133.215]) by d23av02.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9I5bEqV028565; Wed, 18 Oct 2006 15:37:15 +1000 Message-ID: <4535BE8B.8000003@cn.ibm.com> Date: Wed, 18 Oct 2006 05:41:00 -0000 From: Wu Zhou User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Mark Kettenis , gdb-patches@sourceware.org CC: brobecker@adacore.com Subject: Re: Improve end check on rs6000 prologue analyzer References: <20060929213726.GA1770@nevyn.them.org> <200609301932.k8UJW0kw030997@elgar.sibelius.xs4all.nl> <20061017212114.GC12643@nevyn.them.org> In-Reply-To: <20061017212114.GC12643@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00212.txt.bz2 Daniel Jacobowitz wrote: > On Sat, Sep 30, 2006 at 09:32:00PM +0200, Mark Kettenis wrote: >>> Date: Fri, 29 Sep 2006 17:37:26 -0400 >>> From: Daniel Jacobowitz >>> >>> Any comments on this patch? Otherwise, I'll plan to commit it in a few >>> days. >> I get quite a few new regressions on OpenBSD/powerpc. Please don't >> commit this. > > Hi Mark, > > Do you think you could try out this one, instead? I worked out what > was going wrong for me: sign extension. I was testing a 64-bit GDB > binary on 32-bit programs, which caused (op >> 22) == 0x20f to fail; > when it didn't fail, on a 32-bit host, that check allows any load into > r31 to be considered part of the prologue. But it was advancing so far > that for small functions, the breakpoint was placed after the restore > of r31 in the epilogue - much too far. > > This patch fixes the original bug, fixes the sign extension problem, > and generally overhauls the prologue skipping (as opposed to scanning) > to work more like MIPS's. It tests with no regressions on > powerpc-linux, using a 32-bit binary this time. It seems that powerpc-linux is skipped as a whole: if {[istarget *-*-aix*] || ![istarget "powerpc-*-*"]} then { verbose "Skipping PowerPC prologue tests." return } What about open this for powerpc-linux? I commented the above code and have a test in both 32-bit and 64-bit mode on a ppc64 box. For 32-bit mode, there are six more PASS. And for 64-bit mode, we have still 1 PASS and 9 FAIL. Why not just keep these FAIL there, to remind us that these are places we need to improve? Just my two cents anyway. :-) I have yet another proposal to incorporate the bl_to_blrl patch, which is discussed in http://sources.redhat.com/ml/gdb/2006-10/msg00085.html, into this one. Both are improvement for rs6000 prologue analyzer. And I don't find any regression for bl_to_blrl patch right now. When the inferior has more than 600 checkpoints, it is easy to see internal buffer full error. And when I run it manually, no error is reported. For the 15 more PASS and 5 more FAIL in tls.exp, it is indeed a progress: un-patched gdb will display a backtrace at sem_wait like this: where^M #0 0x0fc3ba38 in sem_wait@GLIBC_2.0 () from /lib/tls/libpthread.so.0^M #1 0x0fc3ba1c in sem_wait@GLIBC_2.0 () from /lib/tls/libpthread.so.0^M #2 0x0fc3ba1c in sem_wait@GLIBC_2.0 () from /lib/tls/libpthread.so.0^M #3 0x0fc3ba1c in sem_wait@GLIBC_2.0 () from /lib/tls/libpthread.so.0^M Previous frame inner to this frame (corrupt stack?)^M (gdb) PASS: gdb.threads/tls.exp: backtrace of thread number 4 not relevant FAIL: gdb.threads/tls.exp: No thread backtrace reported spin (vsyscall kernel problem?) and it doesn't find a frame for spin, so it skip some tests. And patched gdb will display a backtrace like this: where^M #0 0x0fc3ba38 in sem_wait@GLIBC_2.0 () from /lib/tls/libpthread.so.0^M #1 0x10000834 in spin (vp=0x0) at ../../../src/gdb/testsuite/gdb.threads/tls.c:97^M #2 0x0fc359ec in start_thread () from /lib/tls/libpthread.so.0^M #3 0x0ff31ed8 in clone () from /lib/tls/libc.so.6^M Previous frame inner to this frame (corrupt stack?) which is much more correct. What is more, all these FAIL are on the valueprint and typeprint of the TLS variables, which are already there (for a long time I guess) in tls-shared.exp and tls-nodebug.exp. There TLS errors occurs where td_thr_tls_get_addr return TD_ERR, so I guess this is related to libthread_db.