[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.