From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119285 invoked by alias); 24 May 2018 16:28:34 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 119270 invoked by uid 89); 24 May 2018 16:28:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=kinda X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 May 2018 16:28:32 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 4AF84302BB3D; Thu, 24 May 2018 18:28:28 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 0B37B400105A; Thu, 24 May 2018 18:28:28 +0200 (CEST) Message-ID: <1527179307.2911.23.camel@klomp.org> Subject: Re: dwarf_begin_elf() won't create handle without .debug_* sections From: Mark Wielaard To: Sasha Da Rocha Pinheiro , "elfutils-devel@sourceware.org" Date: Thu, 24 May 2018 16:28:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-14.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00082.txt.bz2 On Wed, 2018-05-23 at 20:09 +0000, Sasha Da Rocha Pinheiro wrote: > Hi all,=C2=A0 >=20 > I have some binaries that do not have .debug_* sections but have > .eh_frame and .gcc_except_table. > Looking at: > =C2=A0=C2=A0=C2=A0=C2=A0https://sourceware.org/git/?p=3Delfutils.git;a=3D= blob;f=3Dlibdw/dwarf_b > egin_elf.c;hb=3D144b73c49acf3ed894e4635aedb9b0d1208ade2e#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: =C2=A0 /* We looked at all the sections.=C2=A0=C2=A0Now determine whether a= ll the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0sections with debugging information we need a= re there. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0XXX Which sections are absolutely necessary?= =C2=A0=C2=A0Add tests if =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0necessary.=C2=A0=C2=A0For now we require only= .debug_info.=C2=A0=C2=A0Hopefully this =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is correct.=C2=A0=C2=A0*/ =C2=A0 if (likely (result !=3D NULL) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&& unlikely (result->sectiondata[IDX_de= bug_info] =3D=3D NULL)) =C2=A0=C2=A0=C2=A0=C2=A0{ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Dwarf_Sig8_Hash_free (&result->sig8_has= h); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__libdw_seterrno (DWARF_E_NO_DWARF); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0free (result); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0result =3D NULL; =C2=A0=C2=A0=C2=A0=C2=A0} 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=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0dwarf_cfi_addrframe,=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0dwarf_frame_info,=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0dwarf_frame_cfa, and > =C2=A0=C2=A0=C2=A0=C2=A0dwarf_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? >=20 > Since > =C2=A0=C2=A0=C2=A0=C2=A0/* Opaque type representing a CFI section found i= n a DWARF or ELF > file.=C2=A0=C2=A0*/ > =C2=A0=C2=A0=C2=A0=C2=A0typedef 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? >=20 > 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 =3D 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