Re: 8-byte register values on a 32-bit machine

Andrew Cagney
2003-03-12T16:57:50Z

> 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