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

[Andrew Cagney <ac131313@redhat.com>]

> On Wed, Aug 13, 2003 at 10:39:41AM -0400, Andrew Cagney wrote:
> 
>> The initial status of each register is drawn from the CIE, and not the FDE.
> 
> 
> I understand that.
> 
> 
>> If GCC is going to move forward with optimizations that involve local 
>> functions not complying to the ABI, it will need to supply complete 
>> INITIAL_INSTRUCTIONS information.
> 
> 
> WHY?
> 
> I just gave you an argument why that information doesn't do you
> any particular good, NO MATTER WHAT THE ABI IS.  Please refute
> it rather than ignoring it.

This is a standards question - does the standard specify required 
behavior, and does GCC comply to the standard.  ``logcial'' and 
``obvious'', unfortunatly, don't tend to come into such a debate :-( :-)

> Moreover, the algorithm I suggested that you use -- assume saved --
> is also completely independant of the ABI, so its' not like GDB 
> needs to hard code ABI specific information either.

It doesn't work in general.
On a register window machine, it could use a fairly complex starting 
state vis:
	globals: same
	locals: where saved on stack
	input: undefined
	output: in input
(register windows give me a headache so don't assume this one is correct :-)

It is open to per compiler interpretation.
Unless clearly defined by the spec, GCC's interpretation is strictly 
that - GCCs interpretation.  An alternative toolchain is equally at 
liberty to start with the assumption that registers are undefined.

A complete CIE initialization can make for more compact CFI
If the initial state is preserve->same and scratch->undefined, the CFI 
need only describe the preserved registers that get moved.

My current best guess is that this is should be defined by either dwarf2 
or the relevant ABI committee.

[perhaphs I should have cross posted this with dwarf2 :-)]

Andrew