Re: Improve end check on rs6000 prologue analyzer

[Wu Zhou <woodzltc at cn dot ibm dot com>]

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 <drow@false.org>
> > >
> > > 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.