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

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

[Michal Ludvig]

Hi all,
on AMD64 I'm getting these failures:

Running /ttt/64/gdb-head/gdb/testsuite/gdb.base/store.exp ...
FAIL: gdb.base/store.exp: up print old r - charest
FAIL: gdb.base/store.exp: up print old r - short
FAIL: gdb.base/store.exp: up print old r - int
FAIL: gdb.base/store.exp: up print old r - long
FAIL: gdb.base/store.exp: up print old r - longest
FAIL: gdb.base/store.exp: up print old r - float
FAIL: gdb.base/store.exp: up print old r - double

Maybe these failures should be turned into "expected failures" or 
something alike [see below for other solutions]. Why?

This is an extracted testcase:
=============
int add_int (register int u, register int v)
{
   return u + v;
}

int wack_int (register int u, register int v)
{
   register int l = u, r = v;
   l = add_int (l, r);
   return l + r;
}

int main (void)
{
   return wack_int (-1, -2);
}
=============

Compile it and do the steps that store.exp does:
$ ./gdb store
GNU gdb 5.3.90_2003-08-07-cvs
[...]
This GDB was configured as "x86_64-unknown-linux-gnu"...
(gdb) break add_int
Breakpoint 1 at 0x40040c: file store.c, line 6.
(gdb) run
Starting program: /ttt/64/tst/store
Breakpoint 1, add_int (u=-1, v=-2) at store.c:6
6         return u + v;
(gdb) up
#1  0x0000000000400429 in wack_int (u=-1, v=-2) at store.c:13
13        l = add_int (l, r);
(gdb) print r
$1 = <value optimized out>
(gdb)

The testsuite expects that 'r' will have a value '-2' which is not the 
case here. The problem is, that 'r' lives in the register (%rbx) but 
.debug_frame doesn't contain information how to unwind it's previous 
value. When I manually added the appropriate rule 
(DW_CFA_same_value[rbx]) to the generated asm file store.s it worked, 
but GCC obviously doesn't put it there.
The testsuite also works if I undefine the 'register' keyword. Then the 
variables live in the memory and everything is fine.

What's the purpose of having the 'register' keyword in this testcase? 
When the code isn't optimized it doesn't matter where the value lives 
and if you optimize it then GCC itself decides if it should go to the 
register or not.

So I see these possible solutions for inhibiting AMD64 testcase failures:
1) undefine 'register' keyword when running the testsuite on AMD64, or
2) make these failures expected on AMD64, or
3) convince GCC to put 'DW_CFA_same_value' for all non-destroyed 
registers, or
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?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

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

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

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

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

Andrew

PS: My TODO list includes start a, er GCC vs GDB flame war about -O levels.

PPS: This is just the start.  Higher optimization levels mean that GCC 
will need to generate debug info describing how to recover eliminated 
variables.

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

[Daniel Jacobowitz]

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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> 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

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

[Michal Ludvig]

Andrew Cagney wrote:
> 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?

Into the preserved register (%rbx).
When I added the appropriate DW_CFA_same_value instruction to the .s 
file, the register was correctly unwound and the value of the variable 
in an upper frame shown.

Michal Ludvig

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

[Andrew Cagney]

Ref: Dwarf unwinder problems with store.exp and preserved regs
http://sources.redhat.com/ml/gdb/2003-07/msg00026.html

> Andrew Cagney wrote:
> 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?
> 
> Into the preserved register (%rbx).
> When I added the appropriate DW_CFA_same_value instruction to the .s file, the register was correctly unwound and the value of the variable in an upper frame shown.

Ok.  Looking at the debug info (bet everyones compiler is different :-/) 
I'm seeing a very non-descrptive CIEs vis:

00000018 00000014 ffffffff CIE
   Version:               1
   Augmentation:          ""
   Code alignment factor: 1
   Data alignment factor: -8
   Return address column: 16

   DW_CFA_def_cfa: r7 ofs 8
   DW_CFA_offset: r16 at cfa-8
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop
   DW_CFA_nop

I would have expected the CIE.INITIAL_INSTRUCTIONS to specify the 
default state of all DWARF2 registers, and not just a select few.  The 
dwarf2 example, spells out the initial state of all registers vis:

cie              32                             length
cie+4            0xffffffff                     CIE_id
cie+8            1                              version
cie+9            0                              augmentation
cie+10           4                              code_alignment_fact
cie+11           -4                             data_alignment_fact
cie+12           8                              R8 is the return ad
cie+13           DW_CFA_def_cfa (7, 0)          CFA = [R7]+0
cie+16           DW_CFA_same_value (0)          R0 not modified (=0
cie+18           DW_CFA_undefined (1)           R1 scratch
cie+20           DW_CFA_undefined (2)           R2 scratch
cie+22           DW_CFA_undefined (3)           R3 scratch
cie+24           DW_CFA_same_value (4)          R4 preserve
cie+26           DW_CFA_same_value (5)          R5 preserve
cie+28           DW_CFA_same_value (6)          R6 preserve
cie+30           DW_CFA_same_value (7)          R7 preserve
cie+32           DW_CFA_register (8, 1)         R8 is in R1
cie+35           DW_CFA_nop                     padding
cie+36

and GCC put simply is not doing this.

Andrew

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

[Richard Henderson]

On Tue, Aug 12, 2003 at 11:54:32PM -0400, Andrew Cagney wrote:
> I would have expected the CIE.INITIAL_INSTRUCTIONS to specify the 
> default state of all DWARF2 registers, and not just a select few.

Folks already complain unwind info is too large.

As I said, GCC's unwinder assumes DW_CFA_same_value unless otherwise
stated.  Since scratch registers aren't live across the call, it
doesn't matter that we don't mark registers DW_CFA_undefined; any
(accurate) debug information you'll find at the call site in the 
caller simply won't say that values are live in those registers.
Anything else would be a bug.

So assuming DW_CFA_same_value produces the most compact representation.


r~

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

[Andrew Cagney]

> On Tue, Aug 12, 2003 at 11:54:32PM -0400, Andrew Cagney wrote:
> 
>> I would have expected the CIE.INITIAL_INSTRUCTIONS to specify the 
>> default state of all DWARF2 registers, and not just a select few.
> 
> 
> Folks already complain unwind info is too large.

Sounds like a furphy, the difference really is in the noise.

> As I said, GCC's unwinder assumes DW_CFA_same_value unless otherwise
> stated.  Since scratch registers aren't live across the call, it
> doesn't matter that we don't mark registers DW_CFA_undefined; any
> (accurate) debug information you'll find at the call site in the 
> caller simply won't say that values are live in those registers.
> Anything else would be a bug.
> 
> So assuming DW_CFA_same_value produces the most compact representation.

Hmm, an important detail I should have re-iterated (Daniel's original 
post mentioned it but it appears to been lost in that exchange).  The 
unwind info is in two parts:

CIE: This is a global structure shared between many many FDEs
FDE: This is the thing that describes an unwind table.

The initial status of each register is drawn from the CIE, and not the 
FDE.  In the case of the example in question (store.c) there are 3 CIEs 
(I halved everthing as .eh_frame makes the info appear twice) and 30 
FDEs.  Breaking it down: 1 CIE appears to have 0 references; 1 has 1 
reference; and 1 (the only real one) has the remaining 29 references. 
At worst GCC would need to add the information to 3 CIEs, at best 1.

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.  Might as well fix this bug and start 
doing it now.

Andrew

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

[Richard Henderson]

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.

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.


r~

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

[Andrew Cagney]

> 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

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

[Richard Henderson]

> >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 :-)

This has to be handled with the same magic that handles register windows
in the first place.  I.e. DW_CFA_GNU_window_save.  Dwarf2 doesn't handle
windows itself at all.

You could also do it with explicit dw2 operations, but that's no different
than a non-windowed system than starts with all DW_CFA_same_value and
adds DW_CFA_undefined, DW_CFA_register and DW_CFA_offset notes as needed.

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

Probably.


r~