8-byte register values on a 32-bit machine

[Andrew Cagney]

> 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.

There are other ways forward on this - moving the algorithm to libiberty 
(like the demangler).

> 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.

As we've now re-discovered, the assumption is is there, its real, but it 
is implicit.
> 
> I still don't understand what code you're referring to in the reader.

Andrew