Testsuite failures in gdb.base/callfuncs.exp

Testsuite failures in gdb.base/callfuncs.exp

[Andreas Schwab]

This fixes these testsuite failures on ia64:

FAIL: gdb.base/callfuncs.exp: gdb function calls preserve register contents
FAIL: gdb.base/callfuncs.exp: continue after stop in call dummy preserves register contents
FAIL: gdb.base/callfuncs.exp: return after stop in call dummy preserves register contents

The problem is that the bspstore register is specially tied with the bsp
register, and this can't be controlled by gdb.

Andreas.

2007-01-31  Andreas Schwab  <schwab@suse.de>

	* gdb.base/callfuncs.exp (do_get_all_registers): Filter out
	bspstore register on ia64.

--- gdb/testsuite/gdb.base/callfuncs.exp.~1.18.~	2007-01-10 11:18:57.000000000 +0100
+++ gdb/testsuite/gdb.base/callfuncs.exp	2007-01-31 13:28:38.000000000 +0100
@@ -248,6 +248,11 @@ proc do_get_all_registers { } {
     gdb_expect {
 	-re "info all-registers\r\n(.*)$gdb_prompt $" {
 	    set all_registers_content $expect_out(1,string)
+	    if [istarget "ia64-*-*"] {
+		# Filter out bspstore which is specially tied to bsp,
+		# giving spurious differences.
+		regsub {\nbspstore[^\n]*\n} $all_registers_content "\n" all_registers_content
+	    }
 	}
 	default {}
     }

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.base/callfuncs.exp

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 01:33:26PM +0100, Andreas Schwab wrote:
> This fixes these testsuite failures on ia64:
> 
> FAIL: gdb.base/callfuncs.exp: gdb function calls preserve register contents
> FAIL: gdb.base/callfuncs.exp: continue after stop in call dummy preserves register contents
> FAIL: gdb.base/callfuncs.exp: return after stop in call dummy preserves register contents
> 
> The problem is that the bspstore register is specially tied with the bsp
> register, and this can't be controlled by gdb.

How does this work - i.e. how do we guarantee that the restored state
is equivalent?  Does it indicate extra registers written to the
register stack?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Testsuite failures in gdb.base/callfuncs.exp

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Jan 31, 2007 at 01:33:26PM +0100, Andreas Schwab wrote:
>> This fixes these testsuite failures on ia64:
>> 
>> FAIL: gdb.base/callfuncs.exp: gdb function calls preserve register contents
>> FAIL: gdb.base/callfuncs.exp: continue after stop in call dummy preserves register contents
>> FAIL: gdb.base/callfuncs.exp: return after stop in call dummy preserves register contents
>> 
>> The problem is that the bspstore register is specially tied with the bsp
>> register, and this can't be controlled by gdb.
>
> How does this work - i.e. how do we guarantee that the restored state
> is equivalent?  Does it indicate extra registers written to the
> register stack?

bsp can only be modified by writing to bspstore, which is what the kernel
does behind our back.  gdb itself never writes to bspstore.  Thus the
value of bspstore does not really matter.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.base/callfuncs.exp

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 02:56:16PM +0100, Andreas Schwab wrote:
> bsp can only be modified by writing to bspstore, which is what the kernel
> does behind our back.  gdb itself never writes to bspstore.  Thus the
> value of bspstore does not really matter.

Could we restore it if we tried?  Sounds like it would be a bit tricky,
given the comment in ia64-linux-nat.c.

What I'm getting at is that this sounds like a legitimate, if not
terribly important, bug found by the test rather than a bug in the
test.  I'm not terribly sure of that though having read a little about
bspstore.  Very confusing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Testsuite failures in gdb.base/callfuncs.exp

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Jan 31, 2007 at 02:56:16PM +0100, Andreas Schwab wrote:
>> bsp can only be modified by writing to bspstore, which is what the kernel
>> does behind our back.  gdb itself never writes to bspstore.  Thus the
>> value of bspstore does not really matter.
>
> Could we restore it if we tried?

Why would we want to?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.base/callfuncs.exp

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 03:56:57PM +0100, Andreas Schwab wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > On Wed, Jan 31, 2007 at 02:56:16PM +0100, Andreas Schwab wrote:
> >> bsp can only be modified by writing to bspstore, which is what the kernel
> >> does behind our back.  gdb itself never writes to bspstore.  Thus the
> >> value of bspstore does not really matter.
> >
> > Could we restore it if we tried?
> 
> Why would we want to?

I don't know.  To leave the inferior's state as untouched as possible
after an artificial function call.

If you're convinced that's not useful, patch is OK.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Testsuite failures in gdb.base/callfuncs.exp

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Jan 31, 2007 at 03:56:57PM +0100, Andreas Schwab wrote:
>> Daniel Jacobowitz <drow@false.org> writes:
>> 
>> > On Wed, Jan 31, 2007 at 02:56:16PM +0100, Andreas Schwab wrote:
>> >> bsp can only be modified by writing to bspstore, which is what the kernel
>> >> does behind our back.  gdb itself never writes to bspstore.  Thus the
>> >> value of bspstore does not really matter.
>> >
>> > Could we restore it if we tried?
>> 
>> Why would we want to?
>
> I don't know.  To leave the inferior's state as untouched as possible
> after an artificial function call.

We already do that by writing to bsp, which by side effect restores the
state of the RSE as much as possible.  The RSE is running in background in
a way that cannot really be controlled by user level anyway.

> If you're convinced that's not useful, patch is OK.

Thanks.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.base/callfuncs.exp

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 04:35:21PM +0100, Andreas Schwab wrote:
> We already do that by writing to bsp, which by side effect restores the
> state of the RSE as much as possible.  The RSE is running in background in
> a way that cannot really be controlled by user level anyway.

OK, that makes enough sense for me.  Thanks for your patience.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Testsuite failures in gdb.base/callfuncs.exp

[Mark Kettenis]

> Date: Wed, 31 Jan 2007 10:10:01 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Wed, Jan 31, 2007 at 03:56:57PM +0100, Andreas Schwab wrote:
> > Daniel Jacobowitz <drow@false.org> writes:
> > 
> > > On Wed, Jan 31, 2007 at 02:56:16PM +0100, Andreas Schwab wrote:
> > >> bsp can only be modified by writing to bspstore, which is what the kernel
> > >> does behind our back.  gdb itself never writes to bspstore.  Thus the
> > >> value of bspstore does not really matter.
> > >
> > > Could we restore it if we tried?
> > 
> > Why would we want to?
> 
> I don't know.  To leave the inferior's state as untouched as possible
> after an artificial function call.
> 
> If you're convinced that's not useful, patch is OK.

No I think there actually is a problem.  Either the bspstore matters
or it doesn't.  If it doesn't, GDB should just not include it in the
list of registers it displays.  If it does matter, the test is showing
a genuine bug.

Mark

Re: Testsuite failures in gdb.base/callfuncs.exp

[Andreas Schwab]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:

> No I think there actually is a problem.  Either the bspstore matters
> or it doesn't.  If it doesn't, GDB should just not include it in the
> list of registers it displays.  If it does matter, the test is showing
> a genuine bug.

I don't think a register should be left out just because it is read-only.
It is still part of the processor state and can present information that
may be needed for debugging.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.base/callfuncs.exp

[Daniel Jacobowitz]

On Fri, Feb 02, 2007 at 12:29:11AM +0100, Andreas Schwab wrote:
> Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> 
> > No I think there actually is a problem.  Either the bspstore matters
> > or it doesn't.  If it doesn't, GDB should just not include it in the
> > list of registers it displays.  If it does matter, the test is showing
> > a genuine bug.
> 
> I don't think a register should be left out just because it is read-only.
> It is still part of the processor state and can present information that
> may be needed for debugging.

Then can we avoid corrupting it, e.g. by adjusting both registers in a
way that lets us write arbitrary values to it?

I'm going to let you and Mark sort this out; I don't have a strong
opinion.

-- 
Daniel Jacobowitz
CodeSourcery