[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libunwind] using dwarf_step on x86 and amd64

From: Max Asbock
Subject: Re: [libunwind] using dwarf_step on x86 and amd64
Date: Thu, 4 Mar 2004 15:53:14 -0800
User-agent: KMail/1.5.4

>   Max> I have been trying the dwarf parser in the bk tree of
>   Max> libunwind.  When I run it on x86 it fails. The callback()
>   Max> function complains it doesn't find all the required
>   Max> information. It either finds text or eh_header but not both
>   Max> together. Are there any compiler options that I need to produce
>   Max> all the info? (gcc 3.3.1) If I run the same program compiled
>   Max> with the same gcc options on amd64 (as a 64-bit binary)
>   Max> callback() finds everything alright. This is with gcc 3.2.2.
> I believe the theory is that on x86, you should get the necessary
> unwind info with -fexceptions (or compile with g++).  Last time I
> tried, it worked fine with the compiler that ships with RH9 (something
> based on gcc 3.2.x) but not with gcc 3.3.  At first, I thought this
> was a bug in the Debian compiler and I brought it up with the
> maintainer, but then he checked and confirmed that the same behavior
> exists in the main-line gcc 3.3.3.  I don't have a satisfactory answer
> yet why this is so.

Ok, -fexceptions works.
However I noticed that in parse_cie() fde_encoding is initialized to
DW_EH_PE_OMIT. When an appropriate augmentation string is
present this is set to something meaningful. In my case the augmentation
string is empty, therefore the dwarf_parse_fde() fails to read the start
IP and IP range values and bails out. I believe in the absence of an
augmentation string fde_encoding needs to be set to DW_EH_PE_sdata4
for x86 and DW_EH_PE_sdata8 for amd64 (or'ed with DW_EH_PE_datarel?).
Or is the compiler always supposed to generate the augmentation string?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]