Re: [RFC/RFA] use of dwarf2 unwind informations

[Daniel Berlin <dan@cgsoftware.com>]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Jiri Smid <smid@suse.cz> 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