Re: [testsuite & dwarf2] How to handle store.exp failure on AMD64?

[Andrew Cagney <ac131313@redhat.com>]

> On Thu, Aug 07, 2003 at 10:58:48AM -0400, Andrew Cagney wrote:
> 
>> >On Thu, Aug 07, 2003 at 10:49:59AM +0200, Michal Ludvig wrote:
>> >
> 
>> >>4) let GDB pretend that all registers have the same value unless said 
>> >>otherwise later in the .debug_frame and convince GCC to put a note when 
>> >>their value is overwritten.
>> >>
>> >>Opinions?
> 
>> >
>> >
>> >See the archives of this list, from about a month ago.  I discussed
>> >this with Richard but never got around to writing a patch.
> 
>> 
>> And I forgot to commented on the thread also  :-(
>> 
>> There are several bugs:
>> 
>> - An architecture should mark a limited set of registers as, for want of 
>> a better phrase, `always unwind'.  System registers, for instance, would 
>> fall into that category.  No preserve registers, however, are a more 
>> interesting problem.
>> 
>> - GCC should be generate, and GDB should consume, more complete 
>> variable location information.  If a variable isn't preserved across a 
>> function call then GCC/GDB should report the variable as being unavailable.
> 
> 
> I'm not talking about variable location information.  I'm talking about
> register unwind information; and Richard's claim that the default
> should be unmodified makes sense in the context of unwinding.
> 
> Variable locations are a different problem.  A serious one, maybe, but
> unrelated.

Ah, relax, no need to rush the reply.  To expand my first point:

Registers outside of the ABI should probably always be unwound.  ABI 
registers, though, split into callee preserved and scratch.  If GCC 
provides no information on each of these classes then what assumptions 
can and should GDB make?  Does GCC even generate CFI info for 
no-preserve registers -> forcing GDB to assume that the are not 
preserved?  Can GDB point at the dwarf2 spec and justify any assumption 
it makes?

For this specific ABI and problem, did GCC put the value in a preserved 
regiter ...

>> - GCC -O0 should should not eliminate variables, and should preserve all 
>> variables across function calls.
>> 
>> Given that is compiled with -O0, I think GCC is failing on count #3 here.

or a scratch register?

Andrew