Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Mark Kettenis <kettenis@chello.nl>,
	colins@google.com, gdb-patches@sources.redhat.com
Subject: Re: patch for printing 64-bit values in i386 registers; STABS format
Date: Mon, 28 Apr 2003 16:15:00 -0000	[thread overview]
Message-ID: <3EAD51F1.8050605@redhat.com> (raw)
In-Reply-To: <20030428153247.GA28501@nevyn.them.org>


>> The stabs reader will need to be modified so that it generates a proper 
>> location description.  Note that it is STABS centric.  dwarf2 doesn't 
>> need that mechanism since (presumably) GCC is generating the correct 
>> info (....).
> 
> 
> No, that's incorrect.  GDB wouldn't even be able to find half the value
> if GCC was putting out correct information.  We can't fix that until
> GDB is ready to not choke on the result.  We will have to handle the
> incorrect debug info probably forever.

I made two assertions:

- stabs
- dwarf2 (where I included a ``presumably'')

You're saying that both are incorrect?

> This is one of the intended purposes of this mechanism, and as I 
>> indicated, is needed by MIPS.  Being able to project an arbitrary [debug 
>> info] view of the registers onto the raw register buffer.
>> 
>> BTW, what happens when there is an attempt to write a long long value? 
>> GDB again assumes that it can write to contigious registers - the reason 
>> why REGISTER_BYTE can't be killed.
> 
> 
> That ugliness could go away too with Mark's introduced method.  GDB
> could be fixed to find the next register properly.

GDB also uses it to encode offsets into a register.  It also does not 
help the MIPS where the debug register does need to be projected into 
the raw registers.   Why have add more mechanisms when the existing one 
is sufficient.  Focus the effort on fixing the real problem.

BTW, my comment about no names was wrong.  They can be named, that 
restriction should have been removed by the introduction of reggroups.

Andrew



  reply	other threads:[~2003-04-28 16:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-25  0:27 Colin Smith
2003-04-25  2:07 ` Daniel Jacobowitz
2003-04-25 22:18   ` Mark Kettenis
2003-04-25 22:24     ` Daniel Jacobowitz
2003-04-26  3:05       ` Andrew Cagney
2003-04-26  3:20         ` Daniel Jacobowitz
2003-04-26  3:32           ` Andrew Cagney
2003-04-26  3:39             ` Daniel Jacobowitz
2003-04-26  8:25               ` Andrew Cagney
2003-04-27  3:47                 ` Daniel Jacobowitz
2003-04-28 15:22                 ` Mark Kettenis
2003-04-28 16:09                   ` Andrew Cagney
2003-04-28 16:14                     ` Daniel Jacobowitz
2003-04-28 16:15                       ` Andrew Cagney [this message]
2003-04-28 16:37                         ` Daniel Jacobowitz
2003-04-28 19:26                           ` Andrew Cagney
2003-04-28 22:47                             ` Daniel Jacobowitz
2003-04-29  2:15                               ` re-ordered i386 regcache Andrew Cagney
2003-04-29  4:45                                 ` Daniel Jacobowitz
2003-04-29 14:30                                   ` Andrew Cagney
2003-04-29 15:08                                     ` Daniel Jacobowitz
2003-04-29 15:25                                       ` Andrew Cagney
2003-04-30  3:37                                         ` Daniel Jacobowitz
2003-04-30 14:28                                           ` Andrew Cagney
2003-04-30 18:20                                             ` Daniel Jacobowitz
2003-04-28 20:06                       ` Re: patch for printing 64-bit values in i386 registers; STABS format Colin Smith
2003-04-28  0:51         ` Mark Kettenis
2003-04-28 16:18           ` Andrew Cagney
2003-04-28 17:30             ` Daniel Jacobowitz
2003-04-25  0:29 Colin Smith

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=3EAD51F1.8050605@redhat.com \
    --to=ac131313@redhat.com \
    --cc=colins@google.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@chello.nl \
    /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