From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1AFEB3858D1E for ; Thu, 14 Jul 2022 01:37:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1AFEB3858D1E Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-450-kpe147hvMgeuI8HgR8xg3A-1; Wed, 13 Jul 2022 21:37:18 -0400 X-MC-Unique: kpe147hvMgeuI8HgR8xg3A-1 Received: by mail-ot1-f70.google.com with SMTP id cy24-20020a056830699800b0061c76d644e3so114820otb.21 for ; Wed, 13 Jul 2022 18:37:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FlGHzigqRUmUqDZ0XAG35F4pmYm1YQ2+Op7CWVwm99s=; b=meIQDHYYIsL2vIrt58MbJgVrZrs5vWhOHV42yQxXVT59m+TzSfAhcwZsVEmfo8Dy9k w6t7NP47ehAolV5ASI82UtnN4ndxe2kUT+WkiS/xBTU+Jdv/Egj4DNiT2mo7Q16gH0UA uMG/l8sqTLTKDX+qtuoW0+QA1tc6TIy1EKBbqD4fvm+rfjotQbql4c0Tf4bgU92hiEUa EAHjlRoMLYO+HGshrJZCYlwe6RMUnTAxMr3JcUJ/XvxVnpTAYBlqgaeQIrl56sVosEf4 kv7YxAkja++hnqSssg7P1JTxQzSSw0+VHu/J1vFAqp99JVP7bRSAjX6H8E+oqYmptF3w phVA== X-Gm-Message-State: AJIora8UxsOsMyawCLAxsUAsZg4UZdaLS7YhA5JqNhAbCrL+BvGp8FkF gsr0a8R15nyLGTybPJzsZrzQ44GrFK6u+m6jmb8yD/gIjSXoKWqlOnQOo3elHqHSkbwqu4rSCRq +iz6gwH4V9JYgvJ1o0Kb6 X-Received: by 2002:aca:da85:0:b0:32e:b063:2451 with SMTP id r127-20020acada85000000b0032eb0632451mr6700673oig.159.1657762637097; Wed, 13 Jul 2022 18:37:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tjT5kzl6DAsqMBPB9UYpiwKATvwr9uAeOSvX31vhPXV+GLN4HPgZKq0coOAqvDJBxCTsErAQ== X-Received: by 2002:aca:da85:0:b0:32e:b063:2451 with SMTP id r127-20020acada85000000b0032eb0632451mr6700661oig.159.1657762636525; Wed, 13 Jul 2022 18:37:16 -0700 (PDT) Received: from smtpclient.apple ([47.208.199.57]) by smtp.gmail.com with ESMTPSA id c21-20020a4ac315000000b0043548e83486sm74354ooq.35.2022.07.13.18.37.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2022 18:37:16 -0700 (PDT) From: Ben Woodard Message-Id: <952C9B5A-C267-4BC2-9DF1-4045C73C704C@redhat.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Use CTF as a fallback when no DWARFs debug info is present Date: Wed, 13 Jul 2022 18:37:13 -0700 In-Reply-To: <21824871.EfDdHjke4D@sali> Cc: libabigail@sourceware.org To: "Guillermo E. Martinez" References: <21824871.EfDdHjke4D@sali> X-Mailer: Apple Mail (2.3696.100.31) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2022 01:37:22 -0000 So let me begin by saying, I think we should push changes to the API like t= his until after 2.1 is released. Dodji isn=E2=80=99t calling it a beta or R= C yet but we have been treating it that way. I=E2=80=99ve been trying to ge= t all my testing done and he has been trying to get those same bugs fixed. After that, I want to really revisit the API and make it more generally use= ful and less closely tied to the tools. What you are proposing below is a b= aby step along the lines of what I I had in mind. > On Jul 13, 2022, at 4:25 PM, Guillermo E. Martinez via Libabigail wrote: >=20 > Hello libabigail team, >=20 > Talking with my colleges Jose E. Marchesi and Nick Alcock about of th= e user > interface provided by abidw, abidiff and some other tools in libabiga= il, we > think such tools should be looks for DWARF debug information, and if it = is not > present fall back for CTF even without --ctf option, this behaviour is u= sed by > GDB (looking for .ctf and .debug_* section, First of all, I think rather than having a: =E2=80=94enable-ctf compile time option Why don=E2=80=99t we simply make =E2=80=9CWITH_CTF=E2=80=9D an autoconf opt= ion that is disabled if AC_CHECK_HEADER and AC_CHECK_LIB doesn=E2=80=99t fi= nd the things that you need. I don=E2=80=99t think that it should matter where we get the information ab= out the types from. I would also be tempted to get rid the =E2=80=94use-ctf options except I th= ink that we should have the ability to do something like abidw =E2=80=94abidiff =E2=80=94use-ctf somelib.so=20 And it would read the DWARF, then read the CTF and then compare the corpus = that we get from them. Or maybe it would be=20 > but in libabigail is done by the > symtab class), so I did some minor changes in abidw and abidiff =20 don=E2=80=99t forget abicompat > setting the > corpus origin depending of `opts.use_ctf', trying to build the copus with= DWARF > debug information, but if it is not possible (`STATUS_DEBUG_INFO_NOT_= FOUND') > looks for CTF info. I think that we should do a deeper rework here and work the way that GDB wo= rks. In essence doing: In essence: read ELF if( elf-file has DWARF) then use that else if (look for .gnu_reflinks DWARF) then use that else if( look for DWARF5 split DWARF) then use that else if( look for CTF) then use that else if (fail-on-no-debug-info) then exit=20 else warn on limited functionality. I think that all this logic should be encapsulated in an exported function = read_corpus and then all the programs use that interface rather than the f= unctions which are specific to what format the information is gathered from= . > corpus::origin origin =3D opts.use_ctf ? CTF_ORIGIN : DWARF_ORIGIN; > ... > if (origin =3D=3D DWARF_ORIGIN) > { > // Build corpus with DWARF > } > if ((status & STATUS_DEBUG_INFO_NOT_FOUND) || > origin =3D=3D CTF_ORIGIN) > { > // Build corpus with CTF > } >=20 > if (status & STATUS_DEBUG_INFO_NOT_FOUND) > { > // lets to know the user that no debug info > // was found in DWARF neither CTF > } >=20 > Doing in this way, seem to work, however there are functions to notifyi= ng the > user about of missing debug information (e.g `handle_error') that = use an > specific DWARF `read_context' reference, so if we want to reuse it, t= hen we > could split common functionality/interface for both readers in a base = class: >=20 Dodji can weigh in here but this whole contex thing as an API is one of the= things that I wanted get rid of in the general purpose API, IMHO it is too= tightly tied into how the tools work. I kind of know what he was trying to= do, he didn=E2=80=99t want 50 parameters for the functions and so he made = this class to pass them all at once. I think we need to think about making a good general purpose API and I thin= k we can do better than sticking a data structure with parsed command line = options in it. > class base_read_context > { > ... > virtual const string& > alt_debug_info_path() const; >=20 > void > exported_decls_builder(corpus::exported_decls_builder* b); > ... > }; >=20 > class dwarf_reader::read_context : public base_read_context > { > ... > }; >=20 > class ctf_reader::read_context : public base_read_context > { > ... > }; >=20 >=20 > // Now reusing refers_to_alt_debug_info for both readers > bool > refers_to_alt_debug_info(const read_context&=09ctxt, > string& alt_di_path) > { > ... > } >=20 > Please let met know your feedback, I'll really appreciate!=20 If you want to collaborate on this, send me a PR and we can iterate on it o= n my develop branch on github and then I will push it to Dodji right after = we release 2.1 https://github.com/woodard/libabigail -ben >=20 > Regards, > guillermo >=20 >=20