search for: dw_cfa_nop

...es made with the new compiler, you'll see extra dwarf unwind instructions at the end like: ... DW_CFA_advance_loc4 (64) #<-- advance to near end of function DW_CFA_restore (rbp) DW_CFA_def_cfa (rsp, 8) DW_CFA_nop DW_CFA_nop The linker's conversion to compact unwind "runs" the dwarf unwind info for a function and then records the state at the end. Adding unwind info for the epilog breaks this. In the long term, I can add heuristics to the linker to detect that what loo...

...g_frame contents: 0x00000000: CIE length: 0x00000010 CIE_id: 0xffffffff version: 0x01 augmentation: "" code_align: 1 data_align: -4 ra_register: 0x08 DW_CFA_def_cfa (4 (esp), 4) DW_CFA_offset (8 (eip), 0) DW_CFA_nop DW_CFA_nop Instructions: Init State: CFA=esp+4 eip=[CFA] 0x00000014: FDE length: 0x00000028 CIE_pointer: 0x00000000 I'm not sure how the contents of this structure relate to the various LLVM API calls used in creating debugging info... > > Jonas >...

..._frame part of output of command 'readelf -at -wf myelf.bin': 00003374 00000018 00003378 FDE cie=00000000 pc=00021520..000215ce DW_CFA_advance_loc: 1 to 00021521 DW_CFA_def_cfa_offset: 16 DW_CFA_offset: r6 at cfa-16 DW_CFA_advance_loc: 3 to 00021524 DW_CFA_def_cfa_reg: r6 DW_CFA_nop DW_CFA_nop DW_CFA_nop You can see that the last section of .eh_frame begins at 0x2cb14 in file, and has 4 (size value DWORD)+0x18(data)=0x1C bytes. There is the string table immediately after .eh_frame. The problem with this is that __register_frame function (in libgcc_s.so), registering...

On Fri, Sep 18, 2009 at 11:13:52AM -0700, Nick Kledzik wrote: > > The important thing is that only one unwinder is used. The > _Unwind_Context data structure is different between the darwin and FSF > implementations, so you can't pass it between two different > implementations. Since darwin uses two-level namespace and swapping in > a new libgcc_s.dylib at runtime

On 01 Sep 2010, at 08:47, Talin wrote: > Once again, I have no idea what this means or how to go about > debugging it. > This is my biggest frustration with DIFactory - there's absolutely > no way to > verify that the DWARF debugging information that I've emitted into > my module > is correct or even sensible. The only way to test it is to try and > debug

...ngth: 0x00000010 > CIE_id: 0xffffffff > version: 0x01 > augmentation: "" > code_align: 1 > data_align: -4 > ra_register: 0x08 > DW_CFA_def_cfa (4 (esp), 4) > DW_CFA_offset (8 (eip), 0) > DW_CFA_nop > DW_CFA_nop > Instructions: Init State: CFA=esp+4 eip=[CFA] > > > 0x00000014: FDE > length: 0x00000028 > CIE_pointer: 0x00000000 > > > I'm not sure how the contents of this structure relate to the various LLVM > API calls used i...

On Sat, Aug 28, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > >> On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: >> >>> >>> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >>> >>>> I

...> you'll see extra dwarf unwind instructions at the end like: > > ... > DW_CFA_advance_loc4 (64) #<-- advance to near end of > function > DW_CFA_restore (rbp) > DW_CFA_def_cfa (rsp, 8) > DW_CFA_nop > DW_CFA_nop > > The linker's conversion to compact unwind "runs" the dwarf unwind info > for a function and then records the state at the end. Adding unwind > info for the epilog breaks this. In the long term, I can add > heuristics to the linker t...

...t; .debug_frame contents: 0x00000000: CIE length: 0x00000010 CIE_id: 0xffffffff version: 0x01 augmentation: "" code_align: 1 data_align: -4 ra_register: 0x08 DW_CFA_def_cfa (esp, 4) DW_CFA_offset (eip, 0) DW_CFA_nop DW_CFA_nop Instructions: Init State: CFA=esp+4 eip=[esp+4] 0x00000014: FDE length: 0x00000028 CIE_pointer: 0x00000000 Segmentation fault If I grep through the output of dwarfdump, there are no other CIE or FDE definitions that occur before this point, so I assum...