From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86696 invoked by alias); 30 May 2018 17:32: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 86684 invoked by uid 89); 30 May 2018 17:32: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.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=HContent-type:iso-8859-1, HContent-type:charset, HContent-type:text, HContent-type:plain X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,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: smtpauth3.wiscmail.wisc.edu Received: from wmauth3.doit.wisc.edu (HELO smtpauth3.wiscmail.wisc.edu) (144.92.197.226) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 May 2018 17:32:31 +0000 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0184.outbound.protection.outlook.com [216.32.180.184]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPS id <0P9J00395Y24TR20@smtpauth3.wiscmail.wisc.edu> for elfutils-devel@sourceware.org; Wed, 30 May 2018 12:32:29 -0500 (CDT) X-Spam-Report: AuthenticatedSender=yes, SenderIP=[216.32.180.184] X-Wisc-Env-From-B64: ZGFyb2NoYXBpbmhlQHdpc2MuZWR1 X-Spam-PmxInfo: Server=avs-3, Version=6.4.3.2751440, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.5.30.172716, AntiVirus-Engine: 5.49.1, AntiVirus-Data: 2018.5.8.5491002, SenderIP=[216.32.180.184] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wzP3mzKC5qr/FBjGD7WZeiuTgE7lb1rWJMoeuFRmBBQ=; b=MHEcZ6stEShuK6v32WrcCyz6Bg/Fgg5AObgcsHdUy7A2EppASn+5g5l8Q3V+d4DVienLtktXK2M9RuksMfV07hz4Er9vX0uUo+BE6ayRntFxs/qYs5RbyJa/YqUPdWP2ec3up8Ls01PTbmaZ5BSJ9qTIEXIfQrqYQsHhZwJLZes= Received: from BN6PR06MB2932.namprd06.prod.outlook.com (10.175.128.22) by BN6PR06MB3459.namprd06.prod.outlook.com (10.175.131.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Wed, 30 May 2018 17:32:27 +0000 Received: from BN6PR06MB2932.namprd06.prod.outlook.com ([fe80::c09:d9bd:2506:fc5b]) by BN6PR06MB2932.namprd06.prod.outlook.com ([fe80::c09:d9bd:2506:fc5b%8]) with mapi id 15.20.0820.010; Wed, 30 May 2018 17:32:27 +0000 From: Sasha Da Rocha Pinheiro To: Mark Wielaard , "elfutils-devel@sourceware.org" Subject: Re: dwarf_begin_elf() won't create handle without .debug_* sections Thread-topic: dwarf_begin_elf() won't create handle without .debug_* sections Thread-index: AQHT8s4EPBU6/muQ6UmxPhj9qvf9p6Q/EuCAgAl73io= Date: Wed, 30 May 2018 17:32:00 -0000 Message-id: References: , <1527179307.2911.23.camel@klomp.org> In-reply-to: <1527179307.2911.23.camel@klomp.org> Accept-Language: en-US, pt-BR Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [128.105.14.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;BN6PR06MB3459;7:p+6xkCo0O9vGjj8HKS2KzxmpOmMi0iQNYbhqCoOT9RQT0zfGXPO/dq3g2MIy+XOkAJIaZocR0SLs8yuTnViFE2ynPasEue2jg5heUP6v92la/p+Qdak2uuSi+eM/gWuwIuQx2zQrRsF2fKi82SXcd/0IXA3gvAksxUjChxZzVIE6Z3GQtMbNXjhthO4HlA1sqFEjb+lPNhAZMRIRMUslOar6PYuu8kV4LqEJHN+UjfpZREabSNY1co5kktXH+J8B x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(8989080)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020);SRVR:BN6PR06MB3459; x-ms-traffictypediagnostic: BN6PR06MB3459: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016);SRVR:BN6PR06MB3459;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB3459; x-forefront-prvs: 0688BF9B46 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(346002)(376002)(366004)(39380400002)(396003)(39860400002)(53754006)(199004)(189003)(102836004)(11346002)(476003)(3280700002)(7696005)(9686003)(76176011)(53936002)(55016002)(786003)(446003)(66066001)(229853002)(26005)(316002)(6246003)(966005)(478600001)(75432002)(68736007)(99286004)(5250100002)(186003)(53546011)(25786009)(6436002)(6346003)(33656002)(6506007)(2501003)(110136005)(486006)(8676002)(81166006)(5660300001)(8936002)(81156014)(3846002)(305945005)(6116002)(7736002)(74316002)(105586002)(106356001)(2906002)(97736004)(86362001)(575784001)(88552002)(2900100001)(6306002)(14454004)(3660700001)(142923001)(21314002)(19627235001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR06MB3459;H:BN6PR06MB2932.namprd06.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; Received-SPF: None (protection.outlook.com: wisc.edu does not designate permitted sender hosts) Authentication-results: spf=none (sender IP is ) smtp.mailfrom=darochapinhe@wisc.edu; x-microsoft-antispam-message-info: kP+gy7K82Hfn7+7nzRPeOnWTehRQxukZl5Xsn8Bu6FTIu8D6zB0avLNyJ8aAAlKgJWagIPd9N81JWUTgjJfmpZecWXxs+NnSOR9NplaI9XWu+QZREaEBa88WNJ4U1PmuUQyeYV5dbkqsUP8TpuQB1ZNnGala8zrVtuEd7Lk/V05aQNiqiM8IKVF8DbdpuQfB spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable MIME-version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 456de8e2-fc90-4567-fadc-08d5c653502e X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 456de8e2-fc90-4567-fadc-08d5c653502e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2018 17:32:27.0672 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3459 X-SW-Source: 2018-q2/txt/msg00120.txt.bz2 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 FD= Es 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.=20 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 m= e. I thought you would like to know about this mixed FDEs possibility. Sasha =20 From: Mark Wielaard 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 =A0=20 On Wed, 2018-05-23 at 20:09 +0000, Sasha Da Rocha Pinheiro wrote: > Hi all,=A0 >=20 > I have some binaries that do not have .debug_* sections but have > .eh_frame and .gcc_except_table. > Looking at: > =A0=A0=A0=A0https://sourceware.org/git/?p=3Delfutils.git;a=3Dblob;f=3Dlib= dw/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: =A0 /* We looked at all the sections.=A0=A0Now determine whether all the =A0=A0=A0=A0=A0sections with debugging information we need are there. =A0=A0=A0=A0=A0XXX Which sections are absolutely necessary?=A0=A0Add tests = if =A0=A0=A0=A0=A0necessary.=A0=A0For now we require only .debug_info.=A0=A0Ho= pefully this =A0=A0=A0=A0=A0is correct.=A0=A0*/ =A0 if (likely (result !=3D NULL) =A0=A0=A0=A0=A0=A0&& unlikely (result->sectiondata[IDX_debug_info] =3D=3D N= ULL)) =A0=A0=A0=A0{ =A0=A0=A0=A0=A0=A0Dwarf_Sig8_Hash_free (&result->sig8_hash); =A0=A0=A0=A0=A0=A0__libdw_seterrno (DWARF_E_NO_DWARF); =A0=A0=A0=A0=A0=A0free (result); =A0=A0=A0=A0=A0=A0result =3D NULL; =A0=A0=A0=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=A0 > =A0=A0=A0=A0dwarf_cfi_addrframe,=A0 > =A0=A0=A0=A0dwarf_frame_info,=A0 > =A0=A0=A0=A0dwarf_frame_cfa, and > =A0=A0=A0=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 > =A0=A0=A0=A0/* Opaque type representing a CFI section found in a DWARF or= ELF > file.=A0=A0*/ > =A0=A0=A0=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 =20=20=20=20