update dwarf2 asm unwind info [hppa64-*-* failures]

Steve Ellcey sje@cup.hp.com
Tue Aug 12 23:20:00 GMT 2008


On Tue, 2008-08-12 at 14:18 -0700, Richard Henderson wrote:
> Steve Ellcey wrote:
> > code is actually _URC_END_OF_STACK.  I don't know if that means anything
> > more meaningful to you, I am quite lost in this code.
> 
> It means that we either truely reached the end of the stack (unlikely),
> or we couldn't find unwind info for a bit of code.  The latter can quite
> easily happen when we incorrectly unwind a frame, feeding bogus info
> into the next frame.
> 
> What you need to do is debug non-optmized libgcc, working and
> non-working, with a staticly linked test case side by side and
> see where they diverge.
> 
> 
> 
> r~

Before I do that maybe you or David could help me understand something I
see when running 'readelf -wf'.  If I compile my test, link static, and
run readelf -wf on 'old' code.  I see a single .eh_frame section, with
the changed code I see two .eh_frame sections in the object file.  Is
that OK?  Is it expected?  It doesn't seem right to have two .eh_frame
sections but I am not an ELF expert.

With the new code, looking at readelf -wf output I have:

The section .eh_frame contains:

00000000 00000010 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 4
  Data alignment factor: -8
  Return address column: 2
  Augmentation data:     1b

  DW_CFA_def_cfa: r30 ofs 0

00000014 00000010 00000018 FDE cie=00000000 pc=00024f38..000250b4
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop




And then later I have:

The section .eh_frame contains:

00000000 00000024 00000000 CIE
  Version:               1
  Augmentation:          "zPL"
  Code alignment factor: 1
  Data alignment factor: 8
  Return address column: 2
  Augmentation data:     50 00 00 00 00 00 00 40 00 00 00 00 02 08 d0 00

  DW_CFA_def_cfa: r30 ofs 0
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop



More information about the Gcc-patches mailing list