[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: Matthieu Delahaye
Subject: Re: [libunwind] using dwarf_step on x86 and amd64
Date: Mon, 22 Mar 2004 17:44:35 +0100
User-agent: Mutt/1.5.4i

On Thu, Mar 04, 2004 at 04:43:00PM -0800, David Mosberger wrote:
> >>>>> On Thu, 4 Mar 2004 15:53:14 -0800, Max Asbock <address@hidden> said:
>   Max> However I noticed that in parse_cie() fde_encoding is
>   Max> initialized to DW_EH_PE_OMIT. When an appropriate augmentation
>   Max> string is present this is set to something meaningful. In my
>   Max> case the augmentation string is empty, therefore the
>   Max> dwarf_parse_fde() fails to read the start IP and IP range
>   Max> values and bails out. I believe in the absence of an
>   Max> augmentation string fde_encoding needs to be set to
>   Max> DW_EH_PE_sdata4 for x86 and DW_EH_PE_sdata8 for amd64 (or'ed
>   Max> with DW_EH_PE_datarel?).  Or is the compiler always supposed to
>   Max> generate the augmentation string?
> I'm not sure.  All of this stuff seems rather poorly documented.
> Can you check with the binutils folks?

Find details below. But for what I've read on readelf code, the encoding
should be in that case DW_EH_PE_udata4 on platform using Elf32 and
DW_EH_PE_udata8 for those using Elf64. No datarel.

Btw, in file in the bk tree:
src/dwarf/Gpe-dwarf.c, line 88 I have:

  case DW_EH_PE_sleb128:
    if ((ret = dwarf_read_uleb128 (as, a, addr, &val, arg)) < 0)
Shouldn't it be dwarf_read_sleb128 (...) ?

Here is what I've found:
On binutils sources, file binutils/readelf.c
Function display_debug_frames

You can see the inside of this function, from the initialisation of fc
and cie to the print of information, fc->fde_encoding is never modified
and stay to 0.

At line 8697:

          fc->pc_begin = get_encoded_value (start, fc->fde_encoding);
                    if ((fc->fde_encoding & 0x70) == DW_EH_PE_pcrel)
                                fc->pc_begin += section->sh_addr +
                                (start - section_start);

As fde_encoding is set to 0, the readed data is not considered as a pcrel.

And a call to get_encoded_value simple read directly, depending if is_32bit_elf 
is set or not, 4 or 8 bytes.

reply via email to

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