public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Michael Elizabeth Chastain <mec@shout.net>,
	stcarrez@nerim.fr, brobecker@gnat.com, gdb@sources.redhat.com,
	kettenis@chello.nl
Subject: Re: 8-byte register values on a 32-bit machine
Date: Wed, 12 Mar 2003 15:51:00 -0000	[thread overview]
Message-ID: <20030312155116.GA3669@nevyn.them.org> (raw)
In-Reply-To: <3E6F53B3.6010803@redhat.com>

On Wed, Mar 12, 2003 at 10:35:15AM -0500, Andrew Cagney wrote:
> >Okay, I got some sleep and drank some tea and stuff.  I'm a bit more
> >calm now.  :)
> >
> >I filed a proper PR, so that Daniel J (or anybody) can flow it into
> >their TODO list.  Daniel said he has several things to do in this code
> >so I want to get in line properly.
> >
> >I did mark it severity=critical because gdb prints incorrect values, and
> >priority=high because Stephane C says that it happens a lot on the HC11.
> >
> >gdb 5.3 has a different bug in the same area, so this is only sort-of a
> >regression.  The specific program store.exp in the test suite regressed
> >between 2003-02-15 and 2003-02-23, but my test program r8.c in the PR is
> >busted with both gdb 5.3 and gdb 2003-03-01-cvs.
> 
> Shouldn't the new code have been made conditional until it at least 
> equalled the functionality of the old mechanism?
> 
> By failing to do this to do this, the next release of GDB has gained a 
> dependency on the timetable of an internal change.  That is bad.

The new code fixes some reported wrong-value-reported bugs in other debugging
situations; one of them was reported just recently.  So I don't think
'equalled the functionality of the old mechanism' is really quite fair.

I was also not aware that we had sketchy multi-register support until
it was pointed out to me, because the support isn't in any of the
places I was working in directly; it's off in the generic value code,
isn't it?  So I didn't know this was going to happen.  We have a plan
to fix it, too.  Mark posted it, and then ran out of time (?).  You
didn't like his plan because:

   I think it is very dangerous.  It's assuming a specific algorithm
   in the compiler.  That locks both GDB and GCC into something of a
   death spiral.  I think its far better to try and get a proper
   location mechanism working.

Well, that's what we did before, in the "old mechanism", and we don't
have any new debug info that we didn't have then so it's what we need
to keep doing until support for the new debug info is ready (then GCC
can emit it more broadly).

By the way, you wrote:
On Sun, Feb 02, 2003 at 11:14:29AM -0500, Andrew Cagney wrote:
> If only it were that easy.  The dwarf2 reader, for instance, also 
> contains the assumption that registers are allocated sequentially.
> 
> Is the proposal to modify such readers so that they check against this 
> next_allocated_regnum algorithm?

And I wrote back:
> Where?  I can't find this; it doesn't even acknowledge multi-register
> values.

I still don't understand what code you're referring to in the reader.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2003-03-12 15:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-02 16:59 Michael Elizabeth Chastain
2003-03-12 15:35 ` Andrew Cagney
2003-03-12 15:51   ` Daniel Jacobowitz [this message]
2003-03-12 16:57     ` Andrew Cagney
2003-03-12 17:01       ` Daniel Jacobowitz
2003-03-12 18:15         ` Andrew Cagney
2003-03-12 18:29     ` Andrew Cagney
2003-03-12 18:35       ` Daniel Jacobowitz
2003-03-12 18:38         ` Andrew Cagney
2003-03-12 18:48         ` Paul Koning
2003-03-12 19:00           ` Daniel Jacobowitz
2003-03-12 21:04             ` Andrew Cagney
2003-03-12 20:06               ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2003-03-14 16:27 Michael Elizabeth Chastain
2003-03-13  4:18 Michael Elizabeth Chastain
2003-03-13 17:05 ` Andrew Cagney
2003-03-12 19:09 Michael Elizabeth Chastain
2003-03-12 20:47 ` Andrew Cagney
2003-03-02  6:52 Michael Elizabeth Chastain
2003-03-02  9:35 ` Stephane Carrez
2003-03-03  4:50   ` Daniel Jacobowitz
2003-03-01 20:57 Michael Elizabeth Chastain
2003-03-01 22:46 ` Mark Kettenis
2003-02-24  2:36 Michael Elizabeth Chastain
2003-03-01 13:35 ` Mark Kettenis
2003-03-01 20:33   ` Joel Brobecker
2003-03-01 22:38     ` Mark Kettenis
2003-03-01 23:41       ` Andrew Cagney
2003-03-02  0:28         ` Daniel Jacobowitz
2003-03-03 11:26           ` Richard Earnshaw
2003-03-03 11:52             ` Keith Walker
2003-03-01 23:39     ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030312155116.GA3669@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=ac131313@redhat.com \
    --cc=brobecker@gnat.com \
    --cc=gdb@sources.redhat.com \
    --cc=kettenis@chello.nl \
    --cc=mec@shout.net \
    --cc=stcarrez@nerim.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).