Re: [rfa] new test, pr-1090.exp, multi-register variables

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Michael Elizabeth Chastain]

drow> You may want to see gdb/214.

I looked.  Ouch!

To my mind, these are critical bugs, because gdb quietly prints the
wrong information.  If we can't fix it for 5.4/6.0 then I want to
add gdb/214 and gdb/1090 to the PROBLEMS file.

Meanwhile, what do you think of adding my new test to the test suite?

Michael C

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Daniel Jacobowitz]

On Sun, Feb 23, 2003 at 10:35:31PM -0600, Michael Elizabeth Chastain wrote:
> drow> You may want to see gdb/214.
> 
> I looked.  Ouch!
> 
> To my mind, these are critical bugs, because gdb quietly prints the
> wrong information.  If we can't fix it for 5.4/6.0 then I want to
> add gdb/214 and gdb/1090 to the PROBLEMS file.

We can.  We should.

> Meanwhile, what do you think of adding my new test to the test suite?

No objections here.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Andrew Cagney]

Just FYI,

> To my mind, these are critical bugs, because gdb quietly prints the
> wrong information.  If we can't fix it for 5.4/6.0 then I want to
> add gdb/214 and gdb/1090 to the PROBLEMS file.

The only critical thing in GDB 5.4/6.0 is ensuring that the new EMACS 
mode has everything it needs without relying on level two annotiations. 
  And that has a very hard deadline :-(

Andrew

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Daniel Jacobowitz]

On Mon, Feb 24, 2003 at 02:29:29AM -0500, Andrew Cagney wrote:
> Just FYI,
> 
> >To my mind, these are critical bugs, because gdb quietly prints the
> >wrong information.  If we can't fix it for 5.4/6.0 then I want to
> >add gdb/214 and gdb/1090 to the PROBLEMS file.
> 
> The only critical thing in GDB 5.4/6.0 is ensuring that the new EMACS 
> mode has everything it needs without relying on level two annotiations. 
>  And that has a very hard deadline :-(

I beg to differ.  Why should Emacs dictate our schedule?  Why shouldn't
critical debugging issues?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Andrew Cagney]

> On Mon, Feb 24, 2003 at 02:29:29AM -0500, Andrew Cagney wrote:
> 
>> Just FYI,
>> 
> 
>> >To my mind, these are critical bugs, because gdb quietly prints the
>> >wrong information.  If we can't fix it for 5.4/6.0 then I want to
>> >add gdb/214 and gdb/1090 to the PROBLEMS file.
> 
>> 
>> The only critical thing in GDB 5.4/6.0 is ensuring that the new EMACS 
>> mode has everything it needs without relying on level two annotiations. 
>>  And that has a very hard deadline :-(
> 
> 
> I beg to differ.  Why should Emacs dictate our schedule?  Why shouldn't
> critical debugging issues?

Did you read the thread on gdb@?

GDB is a member of the GNU project and as such, it is expected to 
balance its own objectives against those of the larger GNU community.

If GDB doesn't fix a debugging problem in this release, it can can be 
fixed in the next release.

However, if GDB doesn't get the MI working quick smart, GDB maintainaers 
(i.e., you) will be stuck maintaining annotation level two from now 
until eternity.

Andrew

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Michael Elizabeth Chastain]

Andrew C writes:

> The only critical thing in GDB 5.4/6.0 is ensuring that the new EMACS 
> mode has everything it needs without relying on level two annotiations. 
>   And that has a very hard deadline :-(

When is that deadline?
How close is MI to meeting supporting the new EMACS mode ?

Michael C

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Daniel Berlin]

On Sun, 23 Feb 2003, Daniel Jacobowitz wrote:

> On Sun, Feb 23, 2003 at 09:55:44PM -0600, Michael Elizabeth Chastain wrote:
> > This is a new test script for pr gdb/1090, which is about register
> > variables which occupy several registers.  Both gdb 5.3 and gdb
> > HEAD%20030223 get this wrong.  In my testbed, this happens with
> > gcc 2.95.3; gcc v3 compilers don't allocate multi-register variables.
> > 
> > The symptom of this bug is that gdb prints the first word of a
> > structure correctly but botches the second word.  The test has a nice
> > KFAIL for this.
> > 
> > Okay to commit?
> 
> You may want to see gdb/214.  Mark posted a proposal for solving it to
> gdb@ some weeks ago and it never went further; I don't remember what
> the verdict was.
> 
> Some day very soon we'll have GDB support to describe this explicitly;
> some day after that GCC will output the appropriate debug info
> (DW_OP_piece).  May be a little while.
As I mentioned, GCC already outputs DW_OP_piece in one specific case.

If you'd like it to do it more often, let me know when you want it 
outputted, and i'll make it so.


> 
> 

Re: [rfa] new test, pr-1090.exp, multi-register variables

[Daniel Jacobowitz]

On Sun, Feb 23, 2003 at 09:55:44PM -0600, Michael Elizabeth Chastain wrote:
> This is a new test script for pr gdb/1090, which is about register
> variables which occupy several registers.  Both gdb 5.3 and gdb
> HEAD%20030223 get this wrong.  In my testbed, this happens with
> gcc 2.95.3; gcc v3 compilers don't allocate multi-register variables.
> 
> The symptom of this bug is that gdb prints the first word of a
> structure correctly but botches the second word.  The test has a nice
> KFAIL for this.
> 
> Okay to commit?

You may want to see gdb/214.  Mark posted a proposal for solving it to
gdb@ some weeks ago and it never went further; I don't remember what
the verdict was.

Some day very soon we'll have GDB support to describe this explicitly;
some day after that GCC will output the appropriate debug info
(DW_OP_piece).  May be a little while.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[rfa] new test, pr-1090.exp, multi-register variables

[Michael Elizabeth Chastain]

This is a new test script for pr gdb/1090, which is about register
variables which occupy several registers.  Both gdb 5.3 and gdb
HEAD%20030223 get this wrong.  In my testbed, this happens with
gcc 2.95.3; gcc v3 compilers don't allocate multi-register variables.

The symptom of this bug is that gdb prints the first word of a
structure correctly but botches the second word.  The test has a nice
KFAIL for this.

Okay to commit?

Michael C

=== pr-1090.c

/* Test program for multi-register variable.
   Copyright 2003 Free Software Foundation, Inc.

   This file is part of the gdb testsuite.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.
 
   This file was written by Michael Elizabeth Chastain (mec@shout.net).  */

struct s_2_by_4
{
  int field_0;
  int field_1;
};

void marker (struct s_2_by_4 s_whatever)
{
  s_whatever = s_whatever;
  return;
}

void foo ()
{
  /* I want this variable in a register but I can't really force it */
  register struct s_2_by_4 s24;
  s24.field_0 = 1170;
  s24.field_1 = 64701;
  marker (s24);
  return;
}

int main ()
{
  foo ();
}

=== pr-1090.exp

# Copyright 2003 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  

# Tests for PR gdb/1090.
# 2003-02-23  Michael Chastain <mec@shout.net>

# This file is part of the gdb testsuite.

if $tracelevel then {
        strace $tracelevel
        }

#
# test running programs
#
set prms_id 0
set bug_id 0

set testfile "pr-1090"
set srcfile ${testfile}.c
set binfile ${objdir}/${subdir}/${testfile}

if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
}

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

if ![runto marker] then {
    perror "couldn't run to breakpoint"
    continue
} 
gdb_test "up" ".*foo.*" "up from marker"

send_gdb "print s24\n"
gdb_expect {
    -re "\\\$\[0-9\]* = \\{field_0 = 1170, field_1 = 64701\\}\r\n$gdb_prompt $" {
	pass "print s24"
    }
    -re "\\\$\[0-9\]* = \\{field_0 = 1170, field_1 = .*\\}\r\n$gdb_prompt $" {
	# happens with gcc 2.95.3, which actually puts s24 in registers.
	# gdb cannot find the second register and prints garbage.
	kfail "gdb/1090" "print s24"
    }
    -re ".*$gdb_prompt $" {
	fail "print s24"
    }
    timeout {
	fail "print s24 (timeout)"
    }
}