dwarf_begin_elf() won't create handle without .debug_* sections

dwarf_begin_elf() won't create handle without .debug_* sections

[Sasha Da Rocha Pinheiro]

Hi all, 

I have some binaries that do not have .debug_* sections but have .eh_frame and .gcc_except_table.
Looking at:
    https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/dwarf_begin_elf.c;hb=144b73c49acf3ed894e4635aedb9b0d1208ade2e#l50
it seems that dwarf_begin_elf() will not create a Dwarf handle for this file. Am I correct?

So, the functions 
    dwarf_cfi_addrframe, 
    dwarf_frame_info, 
    dwarf_frame_cfa, and
    dwarf_frame_register
will get info from .debug_frame while dwarf_next_cfi can get info either from .debug_frame or .gcc_except_table, but without some abstractions?

Since
    /* Opaque type representing a CFI section found in a DWARF or ELF file.  */
    typedef struct Dwarf_CFI_s Dwarf_CFI;
can we say Dwarf_CFI is only about .debug_frame? Even though dwarf_next_cfi uses Dwarf_CFI_Entry but not Dwarf_CFI?

I know .eh_frame has slightly different format from .debug_frame, and it's not defined by the DWARF specification but LSB, so is it the reason why this is kinda confusing?

Regards,
Sasha

Re: dwarf_begin_elf() won't create handle without .debug_* sections

[Mark Wielaard]

On Wed, 2018-05-23 at 20:09 +0000, Sasha Da Rocha Pinheiro wrote:
> Hi all, 
> 
> I have some binaries that do not have .debug_* sections but have
> .eh_frame and .gcc_except_table.
> Looking at:
>     https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/dwarf_b
> egin_elf.c;hb=144b73c49acf3ed894e4635aedb9b0d1208ade2e#l50
> it seems that dwarf_begin_elf() will not create a Dwarf handle for
> this file. Am I correct?

Yes, this is correct. libdw relies on having at least a .debug_info
section. See the valid_p () function:

  /* We looked at all the sections.  Now determine whether all the
     sections with debugging information we need are there.

     XXX Which sections are absolutely necessary?  Add tests if
     necessary.  For now we require only .debug_info.  Hopefully this
     is correct.  */
  if (likely (result != NULL)
      && unlikely (result->sectiondata[IDX_debug_info] == NULL))
    {
      Dwarf_Sig8_Hash_free (&result->sig8_hash);
      __libdw_seterrno (DWARF_E_NO_DWARF);
      free (result);
      result = NULL;
    }

I have been a little reluctant to change this because I am afraid that
there is code that relies on at least sectiondata[IDX_debug_info] never
being NULL. And in general (you point out exceptions below) most libdw
data structures rely on having an associated DWARF CU DIE (which will
come from the .debug_info section).

But I certainly wouldn't mind if someone did some testing and changed
the above "sanity" check to allow to create a Dwarf *handle in more
cases.

> So, the functions 
>     dwarf_cfi_addrframe, 
>     dwarf_frame_info, 
>     dwarf_frame_cfa, and
>     dwarf_frame_register
> will get info from .debug_frame while dwarf_next_cfi can get info
> either from .debug_frame or .gcc_except_table, but without some
> abstractions?
> 
> Since
>     /* Opaque type representing a CFI section found in a DWARF or ELF
> file.  */
>     typedef struct Dwarf_CFI_s Dwarf_CFI;
> can we say Dwarf_CFI is only about .debug_frame? Even though
> dwarf_next_cfi uses Dwarf_CFI_Entry but not Dwarf_CFI?
> 
> I know .eh_frame has slightly different format from .debug_frame, and
> it's not defined by the DWARF specification but LSB, so is it the
> reason why this is kinda confusing?

Right. But note that dwarf_getcfi_elf () (unlike every other dwarf_...
function) takes an Elf *handle, not a Dwarf *handle.

So given an Elf *elf handle gotten with elf_begin () you can do:

Dwarf_CFI *cfi = dwarf_getcfi_elf (elf);

And then use that cfi with dwarf_cfi_addrframe () to get a Dwarf_Frame
*, which you can then use with dwarf_frame_register (), etc. They don't
care whether the CFI came from a Dwarf .debug_frame or Elf .eh_frame.

Cheers,

Mark

Re: dwarf_begin_elf() won't create handle without .debug_* sections

[Sasha Da Rocha Pinheiro]

I certainly could help with the testing, but I would need help on them, to figure all cases we would cover.

I just fixed something interesting in Dyninst. We were assuming that the FDEs were following the CIE in the eh_frame section, but this is not correct. I found them mixed in an ARM binary and this caused wrong parsing. 
So we I did dwarf_next_cfi() in the loop to go through the FDE's, and I had to use it again in the loop to get the corresponding CIE. I don't think it's a problem, just kinda not intuitive, for who wants to understand after me.

I thought you would like to know about this mixed FDEs possibility.

Sasha

 
From: Mark Wielaard <mark@klomp.org>
Sent: Thursday, May 24, 2018 11:28 AM
To: Sasha Da Rocha Pinheiro; elfutils-devel@sourceware.org
Subject: Re: dwarf_begin_elf() won't create handle without .debug_* sections
  

On Wed, 2018-05-23 at 20:09 +0000, Sasha Da Rocha Pinheiro wrote:
> Hi all, 
> 
> I have some binaries that do not have .debug_* sections but have
> .eh_frame and .gcc_except_table.
> Looking at:
>     https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/dwarf_b
> egin_elf.c;hb=144b73c49acf3ed894e4635aedb9b0d1208ade2e#l50
> it seems that dwarf_begin_elf() will not create a Dwarf handle for
> this file. Am I correct?

Yes, this is correct. libdw relies on having at least a .debug_info
section. See the valid_p () function:

  /* We looked at all the sections.  Now determine whether all the
     sections with debugging information we need are there.

     XXX Which sections are absolutely necessary?  Add tests if
     necessary.  For now we require only .debug_info.  Hopefully this
     is correct.  */
  if (likely (result != NULL)
      && unlikely (result->sectiondata[IDX_debug_info] == NULL))
    {
      Dwarf_Sig8_Hash_free (&result->sig8_hash);
      __libdw_seterrno (DWARF_E_NO_DWARF);
      free (result);
      result = NULL;
    }

I have been a little reluctant to change this because I am afraid that
there is code that relies on at least sectiondata[IDX_debug_info] never
being NULL. And in general (you point out exceptions below) most libdw
data structures rely on having an associated DWARF CU DIE (which will
come from the .debug_info section).

But I certainly wouldn't mind if someone did some testing and changed
the above "sanity" check to allow to create a Dwarf *handle in more
cases.

> So, the functions 
>     dwarf_cfi_addrframe, 
>     dwarf_frame_info, 
>     dwarf_frame_cfa, and
>     dwarf_frame_register
> will get info from .debug_frame while dwarf_next_cfi can get info
> either from .debug_frame or .gcc_except_table, but without some
> abstractions?
> 
> Since
>     /* Opaque type representing a CFI section found in a DWARF or ELF
> file.  */
>     typedef struct Dwarf_CFI_s Dwarf_CFI;
> can we say Dwarf_CFI is only about .debug_frame? Even though
> dwarf_next_cfi uses Dwarf_CFI_Entry but not Dwarf_CFI?
> 
> I know .eh_frame has slightly different format from .debug_frame, and
> it's not defined by the DWARF specification but LSB, so is it the
> reason why this is kinda confusing?

Right. But note that dwarf_getcfi_elf () (unlike every other dwarf_...
function) takes an Elf *handle, not a Dwarf *handle.

So given an Elf *elf handle gotten with elf_begin () you can do:

Dwarf_CFI *cfi = dwarf_getcfi_elf (elf);

And then use that cfi with dwarf_cfi_addrframe () to get a Dwarf_Frame
*, which you can then use with dwarf_frame_register (), etc. They don't
care whether the CFI came from a Dwarf .debug_frame or Elf .eh_frame.

Cheers,

Mark
    

Re: dwarf_begin_elf() won't create handle without .debug_* sections

[Mark Wielaard]

On Wed, 2018-05-30 at 17:32 +0000, Sasha Da Rocha Pinheiro wrote:
> I just fixed something interesting in Dyninst. We were assuming that
> the FDEs were following the CIE in the eh_frame section, but this is
> not correct. I found them mixed in an ARM binary and this caused
> wrong parsing. 
> So we I did dwarf_next_cfi() in the loop to go through the FDE's, and
> I had to use it again in the loop to get the corresponding CIE. I
> don't think it's a problem, just kinda not intuitive, for who wants
> to understand after me.

dwarf_next_cfi () is a very low level interface. Other cfi related
interfaces that work with a Dwarf_CFI handle (dwarf_getcfi () and
dwarf_getcfi_elf ()) and don't make any assumptions about the order. 

But they do build up a cache of all entries. In return for some extra
memory usage you can use them without caring about the order in which
they appear with dwarf_cfi_addrframe () by just giving an address you
are interested in and using dwarf_frame_info (), dwarf_frame_cfa () and
 dwarf_frame_register () to extract the information (which might be
less/different than what you would get from the "raw" Dwarf_CFI_Entry).

Cheers,

Mark