problems parsing dwarf frame info on amd64 optimized code

problems parsing dwarf frame info on amd64 optimized code

[Max Asbock]

Hi all,

I am trying to parse the dwarf frame info on amd64 using the dwarf parser
from libunwind which I had to slightly modify to run on amd64.
The parser works correctly in unoptimized code that uses frame pointers.
When I turn on the -O flag things fall apart. This is with gcc 3.2.2.
The parser finds two rules in the CIE:
CFA_def_cfa r7+0x8           (rsp)
CFA_offset r16 at cfa-0x8  (return address)
and then in the FDE it finds:
...
CFA_def_cfa_offset <offset>
...

This works for stepping from the first frame to the second, but
on the next step it fails, since the CFA is read again from r7 (rsp)
which hasn't changed. And it seems that the CFA <offset> is the
offset relative to the current CFA, not relative to the value in rsp.
I hope I am making sense. I am not a gcc nor a dwarf expert, so 
I don't really know if the compiler is generating the correct dwarf info
and the parser needs to do something different or the other way
around.

Any help or hints would be greatly appreciated.

regards,
max 

Re: problems parsing dwarf frame info on amd64 optimized code

[Jim Wilson]

Max Asbock wrote:
> The parser works correctly in unoptimized code that uses frame pointers.
> When I turn on the -O flag things fall apart. This is with gcc 3.2.2.

Try a newer gcc version, or a gcc from the development tree.  Maybe 
something has been fixed.

The dwarf unwind info is only used by the gcc builtin dwarf unwinder, 
and the semantics are pretty much defined by what the gcc unwinder does. 
  If the gcc unwinder is working, then step through it to see how it works.

It is possible that the dwarf2 unwind info is not sufficiently detailed 
for all libunwind features to work.  We generally only emit enough info 
for C++ EH to work, which means we need consistent unwind info at call 
points, but not anyplace else.  In particular, most ports do not emit 
unwind info for epilogues.  I think only IA-64 does at the moment, and 
it doesn't use dwarf unwind info.  We do emit unwind info for prologues 
as that is useful for gdb.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: problems parsing dwarf frame info on amd64 optimized code

[Richard Henderson]

On Mon, Mar 08, 2004 at 10:44:03AM -0800, Max Asbock wrote:
> When I turn on the -O flag things fall apart. This is with gcc 3.2.2.
> The parser finds two rules in the CIE:
> CFA_def_cfa r7+0x8           (rsp)
> CFA_offset r16 at cfa-0x8  (return address)
> and then in the FDE it finds:
> ...
> CFA_def_cfa_offset <offset>

This is correct.

> This works for stepping from the first frame to the second, but
> on the next step it fails, since the CFA is read again from r7 (rsp)
> which hasn't changed.

Huh?  I think you need to provide a concrete example because what
you're saying doesn't make any sense.  Particularly "stepping from
first frame to the second".  There's only one frame in any function
generated by gcc...

> And it seems that the CFA <offset> is the
> offset relative to the current CFA, not relative to the value in rsp.

Incorrect.



r~

Re: problems parsing dwarf frame info on amd64 optimized code

[Max Asbock]

Hi Richard,

sorry for being unclear. I will try again:
I am unwinding through -O optimized amd64 C code using the dwarf unwind info.
(gcc version 3.5.0 20040308)

First Frame:
The dwarf parser finds two rules in the CIE:
CFA_def_cfa r7+0x8           (rsp)
CFA_offset r16 at cfa-0x8  (return address)
and then in the FDE it finds:
...
CFA_def_cfa_offset <offset1>
When applying the rules I set
cfa1 = r7 + offset1
There is no rule for r7, so I was assuming r7 stays unchanged.

Second Frame:
CFA_def_cfa r7+0x8
CFA_offset r16 at cfa-0x8
...
CFA_def_cfa_offset <offset2>
Applying the rules gives
cfa2 = r7 + offset2
however this is incorrect, the actual value is
cfa2 = cfa1 + offset2

From this I infer that the assumption I made about r7 remaining unchanged 
when there is no rule for it is incorrect and what I really have to do is something
like:
Frame 1:
cfa1 = r7 + offset1
if (r7 unspecified)	r7 = cfa1
Frame 2:
cfa2 = r7 + offset2
....
Is this the correct approach or are there cases where it would fail?

thanks,
max

Re: problems parsing dwarf frame info on amd64 optimized code

[Richard Henderson]

On Thu, Mar 11, 2004 at 10:07:36AM -0800, Max Asbock wrote:
> There is no rule for r7, so I was assuming r7 stays unchanged.

Ah hah.  I see what you're talking about now.

No, there's an implicit assumption that the CFA corresponds
to the stack pointer at the point of the call instruction.
This can be overridden by the actual CFI data if the target
wants to describe the old stack pointer value saved in some
register or in memory.

The normal case, the old stack pointer not saved anywhere
directly only as a known offset from a register, is not
representable in dwarf2/3.  There has been talk about adding
something for this case but nothing has materialized yet.

> From this I infer that the assumption I made about r7 remaining unchanged 
> when there is no rule for it is incorrect and what I really have to do is
> something
> like:
> Frame 1:
> cfa1 = r7 + offset1
> if (r7 unspecified)	r7 = cfa1
> Frame 2:
> cfa2 = r7 + offset2
> ....
> Is this the correct approach or are there cases where it would fail?

This is correct.


r~