From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jim Blandy Cc: Jiri Smid , gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] use of dwarf2 unwind informations Date: Wed, 17 Oct 2001 09:19:00 -0000 Message-id: <87k7xutq5k.fsf@cgsoftware.com> References: X-SW-Source: 2001-10/msg00247.html Jim Blandy writes: > Jiri Smid writes: >> This is code which allows gdb to use dwarf2 frame informations for >> stack unwinding. > > It looks good; could you commit this? > > I have some initial questions, though: > > - How can I get GCC to produce .debug_frame sections to test this? > Do you have a patch for GCC I could use, or is there some flag we > can use to simply have GCC divert its .eh_frame contents to a > .debug_frame section? Errr, gcc trunk will produce debug_frame info by default for dwarf2 now. > > - It's my understanding that the .eh_frame format used by GCC and the > .debug_frame format described in the Dwarf2 standard are actually > slightly different. Which one does your patch support? It depends. Unless he changed the code i gave him a whole lot, which reading through the reading portion, he didn't, it should support both. > > - Is context_cpy correct? It seems to me that it copies the immediate > contents of the `struct context', but then only copies the first > element of the `reg' array. > > - The `read_pointer' function assumes `sizeof (CORE_ADDR)' in GDB > gives the size of pointers appearing the Dwarf 2 information. This > confuses a host type (CORE_ADDR) with what I think is supposed to be > a target-sized address. CORE_ADDR is simply the largest unsigned > integer type GDB can find. I think it should use TARGET_ADDR_BIT / > TARGET_CHAR_BIT, unless the Dwarf 2 info specifies the proper size > somewhere, the way it does for .debug_info data. > > > ... Anyway, I'll keep reading. Thanks very much! -- "I went to court for a parking ticket. I pleaded insanity. I said, "Your honor, why would anyone in their right mind park in the passing lane?" "-Steven Wright