Re: patch for printing 64-bit values in i386 registers; STABS format

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Apr 28, 2003 at 11:22:52AM -0400, Andrew Cagney wrote:
> >   Date: Fri, 25 Apr 2003 23:32:47 -0400
> >   From: Andrew Cagney <ac131313 at redhat dot com>
> >
> >   > I'm afraid I don't understand, and I still don't see your reasoning
> >   > against this approach.
> >
> >   It isn't necessary, just like register convertible and register 
> >   raw/virtual size; .... that go before it, also were not necessary.  And 
> >   now all these years later, GDB is still yet to expunge.
> >
> >I still don't see how you can get rid of the register convertible
> >stuff.  On the i386 I still need it for variables stuffed into the
> >floating point registers.
> 
> That case is fine.  A while ago I split the mechanism in half:
> 
> - given a single FP register convert the type into its true form
> - the MIPS jungle of combining sub-parts and adjacent FP and integer 
> register values
> 
> >   Until someone does the right think - add support for values scattered 
> >   across registers and memory - hacks should be confined to architecture 
> >   specific code.
> >
> >But even if someone does add support for values scattered across
> >multiple registers and/or memory, we still need the architecture
> >method I proposed.  There simply is too much debugging info out there
> >that can't express values being scattered across multiple registers.
> 
> 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.

> >And I don't think the hack you proposed is a good idea.  I think it's
> >better to add a new architecture method with a clear purpose than
> >abuse an existing mechanism for something that it wasn't quite
> >intended for.  Even if the architecture method in question would only
> >be used by a single target.
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer