From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 9751C3858D37 for ; Thu, 14 Jul 2022 17:35:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9751C3858D37 Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26EFvsxd000871; Thu, 14 Jul 2022 17:35:38 GMT Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3h71xrnvtq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jul 2022 17:35:38 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 26EHZR5Y009368; Thu, 14 Jul 2022 17:35:37 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2168.outbound.protection.outlook.com [104.47.55.168]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3h7046hj7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jul 2022 17:35:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TrDBehFSmbCSDHHA13h0FNOigSkpGB9kG6DCwtKE2REarlu7yMph4OAuc4WpwPOSndHBOgPgP+qmkyWZJ+PgUFHnfJ++JWTSuaTyOE2G1JR0E6meAEJg2Gu6Ck00pQupyiZG1qrar7G+7kmCQu7u1hGY0Jxz0v1YK8C7T5lScUhf5PrtcOZE55bl3R3v124b6uciqTpYIU7iS6sCVj6VxJGKTZ3gt/cD6tZN4tohEuNKeLoo9y6lVaOTZZTbxTJP9w5Df4PeBkTrALESeedVaM0jUfZoZjGoKm2dV7UjZJcDf+E57LbkHcPtaaS1x/GKIBFqiuVKlO7OWDIsOeo0CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ltr5IJOBPcl76zLM56Tl4+gXt1uae9QKoTda+0VoDbU=; b=QIIonYCPzZtvm6aTgqBVShWkRg2OfKZwHt4/1pzFyv//oSmFPaKC8lv/DW8Myp2gqkWo0WmUcQNGwD98br2caDA83Xju0eG0LbPHB7yrHQ2AwsqrtMVE3U9d5uDsCr/opIqHQbaDwyh3T2xZAWtu6KQuY2qC/aGTjv1T6TkEwnf4z80DctgpOPngAlvpSRNCCLC1sZbn7lAqUaVF08ESH6e848Bn3zaVmzuC4/YNmMah7gD3YxFKFAa+JpbUBiaUQc2LEzWKp6wHWi53WEWJ2sTJD5Dw8JI5IzPXCnKD78oaLotU2fz+VJ8XK25PvBFl5uVlAaB4mVwaURE2ZO/QYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from MWHPR10MB1407.namprd10.prod.outlook.com (2603:10b6:300:23::20) by SA2PR10MB4764.namprd10.prod.outlook.com (2603:10b6:806:115::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.21; Thu, 14 Jul 2022 17:35:35 +0000 Received: from MWHPR10MB1407.namprd10.prod.outlook.com ([fe80::40f0:f59d:aca7:92ea]) by MWHPR10MB1407.namprd10.prod.outlook.com ([fe80::40f0:f59d:aca7:92ea%3]) with mapi id 15.20.5438.014; Thu, 14 Jul 2022 17:35:35 +0000 From: "Guillermo E. Martinez" To: Ben Woodard Cc: Ben Woodard via Libabigail Subject: Re: Use CTF as a fallback when no DWARFs debug info is present Date: Thu, 14 Jul 2022 12:35:31 -0500 Message-ID: <5203709.0VBMTVartN@sali> Organization: Oracle Corp In-Reply-To: <2D2DA8C8-6793-4FA9-A923-A7D4C82748F4@redhat.com> References: <21824871.EfDdHjke4D@sali> <3494804.5fSG56mABF@sali> <2D2DA8C8-6793-4FA9-A923-A7D4C82748F4@redhat.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-ClientProxiedBy: BY5PR04CA0017.namprd04.prod.outlook.com (2603:10b6:a03:1d0::27) To MWHPR10MB1407.namprd10.prod.outlook.com (2603:10b6:300:23::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 93f93431-5cf8-4c13-1639-08da65bf4248 X-MS-TrafficTypeDiagnostic: SA2PR10MB4764:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2TM0Uec86Jk5oNzMsMLalZNNj9ddPumiBsfz16N7GFMEoF3TewWx444o/nvS+ZqSM9LjXipEQK//plj7+p6C95TdeECHWsrwFncfT5tkTFSEhizCkTIrpatBTpWvIago6YylNOlbNsxCYX4eW2k9+v1zcn+4ExF/PlT24ZyL94jDc1iRqQ87yot/l3Z8CJNxDQkg2s7XdTnq3OZHyUjL9PkPtuDyF4pGMG/yUDp6KUHgwBXg+dnebUimzJMqotjtg7OOFfxtaCrvn0+IDpb4VrIviLldVi/GjVpo3zzztTKH9NW44CyT/qVXe7/lzdbuYxWpR6JrDwem7UD7bQifS9sjE6iBRKiqOPYCLKSuBl9te+4J3kwoxF6VYorAhfjceJV9hXXMTQUfq4k+EiNpJsIKgLVXDMEFdPAZVP/jYA15qgwRoLX6AZ37zuK5LQAGY2mGb/OpEhnkCFSSKwGpa08DhDfLxl2TQWqaa6vXeMA6579Cm4ZBca2ZHoZfJU5mPe87tRbRhLzNyhyjLPEFFI5S3CEqGLch5igGSlMu4cPRgm5HRdNVB6zFgWG3HN0QAiAATFIckcVK9Kco36XUdrjfQWKWFyM8V21QEJQJngAIr5nuzQHAxNjjbDr4zUThjfyHPVGBqG7asAJbMWb1NL8/Kag0On2qsehBeQDp7IHCP8qifQTw0G5B9F4ZZkPe6t1rJ3z0bNh93TISGzSx5Vmt+9ukePyd/g/Rsm7bk1k33EJLWk7ai3GEQzL8rapXgeYiWq6Vfai27RkRojrvHdDNiLI03UGtLg2YLHCDlLZysGec45JFuCwUMzZi7K3U/4ieddHfHIyFHkRxywkcSyVKHKOPZ/pLoGiRZEsU+dqCI0mSDosl+O7vj7k7VQ/J X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR10MB1407.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(7916004)(346002)(376002)(39860400002)(366004)(136003)(396003)(52116002)(6916009)(5660300002)(6512007)(53546011)(9686003)(66476007)(8936002)(38100700002)(478600001)(2906002)(316002)(966005)(6666004)(83380400001)(6486002)(186003)(36916002)(66556008)(6506007)(41300700001)(33716001)(8676002)(4326008)(86362001)(66946007)(39026012); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bWRFN3o5NG5PNFRHSnU5eFdDK2xMSDV0cHYvUVloaGNsQ1lKSkxZMDhLc2t4?= =?utf-8?B?K2E1em5kZitFNDUyaDliSm1CSmdlaUQreEthQy9PV0tVcDE2WXpIWU9KSXJ2?= =?utf-8?B?cjducDIvUzBLUXNmNTdVT1ZqdFhsRUt0Ykp6K2p2VWJQTTZrWWpCYWlTeUZv?= =?utf-8?B?K3JVd0c5NDM3WEd3UlU0QXpWeFhIT1FLS2tKYjFYUFdYQjUwR3hHQ1BoT25Z?= =?utf-8?B?REhXK05semprQ2p4SmVpVHdodVlHVXc2Ui84S0NTL3VyVDF3cmIwd3BTMjFs?= =?utf-8?B?aWc4VHZmc2pENmFvVWJScFZPZjNlR3ZKMnFaSXkrc1BiOG1DTklhbU1GQkcw?= =?utf-8?B?c3R4djRnQXBqZHBhRnpCWW9jRXk2a09rTnp6VU10blJvaStLOTc5bUpPWlR1?= =?utf-8?B?RXI3MCtKQTNYYUd6VXErWTdxWElFaStNRjViT2ZBdmhZZTJyVWpmUEQ3NU9v?= =?utf-8?B?VG9TeEJqYUhoZU8yTmtrQWo5VEx6cS9XVGVTL3VpRWlMZ2FKU09udDNyc3FR?= =?utf-8?B?K1Q2cm0yKzZlbG9HbEtjUWFKRnNYVlZ0TGxBREtBMTVEVjEyNmRaN1N3TTQ4?= =?utf-8?B?TmJwTHY2VkxlL2EzWmhxSUo3QVZxM3dYVjZqcFIzSGlqZlZHdUlwNTdLeFVV?= =?utf-8?B?VHV6OEwwaWl4djVnTWNSRzJWUzVxdFJBN25RaC9jNUFXTnFGUzNyZnpLTUgx?= =?utf-8?B?NXFaempiZWxlVjFpVy90eFJFK0pvcG40bWEyNVhBVDgvMzhsSlNFSmU1bWoy?= =?utf-8?B?cFZwL2o0UFlUNXlXbnRMc0pXVzZzcGFUVmJOVnBmYkhuTkxyQXZ1Yzh2VmN3?= =?utf-8?B?dTlaNXBHRnhvMEF4aWdEcmZ6Ty9lT3hnaFVwV1c5OUZaZnFjdCtTMEFpL0VY?= =?utf-8?B?WUlXYkYxdUpNeGFaU3NOMko2QUxnL1FaVmNQSktLSXJoS3dZM0NLU1ZoS0VM?= =?utf-8?B?QVBkN1pEOU5CUFgxbjJ4N3UxbmpGVTRVR1FJM1VnbUVYYk1uaHk1ZlpNYmdj?= =?utf-8?B?NXYyVTg5RVY2c3BWazlQdkVEYVBZSXU3a2UvbGdSejN2NzhvSUZZM2RzT0Nx?= =?utf-8?B?bkdUa1N1ejZPQWNmTHk2cG1PSWpyRXBHbnRPMW14M3NyTk13cTZScXNYc0Vq?= =?utf-8?B?MWEveXFrS0h4S1RObkdacGRYMExVV1orbWlHNEFuVDZzeFVTaDhxdlRXTkMx?= =?utf-8?B?TGJMY3M5NlNXNzZPdWd6Q2NsMDBIUno2akJWMFVxME52cVlSU25VTVN4MHlu?= =?utf-8?B?Z2tQWU1mZ25GcE1NNGR1SmxJb1VNS3dIYUw4ZDRWZ0pEWFE5c0hxSUVybVR2?= =?utf-8?B?WlVpWXo0aEN0Q2x0NzhtSUpDWGp4d1BUSG5sbTg1REQwRFFJUG9xMHl2ZGxY?= =?utf-8?B?Q2xKOWsyR1hjNi9vcXJkcmJ6MTJZS0ZvWXd4aVpwaDQ1ak04UjVMN1RjcFk2?= =?utf-8?B?NmJ3amFLcVJNdngrSFlwdEdGcnNBaENTWU1ab1ZjNCtnVmxhNkxVeUN5K2Qz?= =?utf-8?B?aE1td3RkVjNEY3ROVk9ZTVl4M0MyQS9DV2ZxaGpCVUtvTCsxSXNJSk92OWgr?= =?utf-8?B?K1lBN1U4cnFEZVRqRVV5ZE5QMFZiZE4vaTVPblZNZlpJd21NdG1uVExoWERF?= =?utf-8?B?R0o3NG9HMk0rbm5FK0diODdwYzNtclNPQzB6a1FSZllhenBqTDl1dVZhVkoy?= =?utf-8?B?T3E1ZkVYbGk4aGFkWjJNMkQ0WWVTWGlnWlAxL1hWVFU1WElRWkxtOVhQT3pr?= =?utf-8?B?VFFmT1gzczJEVnNKbDk1akxJaHE3Tm5oeVhQVVVxRWpUY25QbDZKVTFZVmY4?= =?utf-8?B?L2NZSVF6UlZuUW50TnZ0VElHWjdkU0xqeTBXZDlNVGUvVTAyNzZEUk1VSHc2?= =?utf-8?B?KzNaZUhyblF5d3doSGZuVEh2NDg0M3MyZ0VYeitkZTVLZ1R6UHhNa21YWWht?= =?utf-8?B?SXU0eEF4UVFrSHcrWk52cFBEN3BlUitONGVYek1Ub080cWkvbytKcnQ0UjZi?= =?utf-8?B?MnZyZ2hjejhkWkc5akhOeU45eTJ4bytyQk42N3o4eGhGVmo3UGV4ZTRrZzg0?= =?utf-8?B?K2p4Q1pmTU0zbmtrenBBZjArM3pTUFpSdU4zbHh6aDkzTWhvQXgvY1MvYmZs?= =?utf-8?B?NHdZS0cybEc3RTR2ZjhQSDNmVEcrUjl6dXN6SGJVTkFGa1NndTZtNy9MVTND?= =?utf-8?Q?xmZZH5AOFKUarvLneAhC3g4=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 93f93431-5cf8-4c13-1639-08da65bf4248 X-MS-Exchange-CrossTenant-AuthSource: MWHPR10MB1407.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2022 17:35:35.3400 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 775LuoIHDB0srZn5gtYBGI/K+hisSIOwcKsv59H4dWoJOYhsRcKdWQmJ+ifQ3V4AFuWWGegMJXBbe/E/WAemiIv71AOJkll8KcBkXMqbXw4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4764 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-14_15:2022-07-14, 2022-07-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0 mlxscore=0 suspectscore=0 adultscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207140076 X-Proofpoint-GUID: hXqGJpRPQcHuL-XmEZMCTnbBGw_g-8nS X-Proofpoint-ORIG-GUID: hXqGJpRPQcHuL-XmEZMCTnbBGw_g-8nS X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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 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 17:35:49 -0000 On Thursday, July 14, 2022 11:01:41 AM CDT Ben Woodard wrote: >=20 > > On Jul 14, 2022, at 8:06 AM, Guillermo E. Martinez wrote: > >=20 > > On Wednesday, July 13, 2022 8:37:13 PM CDT Ben Woodard wrote: > > Hi Ben, > >=20 > >> So let me begin by saying, I think we should push changes to the API l= ike this until after 2.1 is released. Dodji isn=E2=80=99t calling it a beta= or RC yet but we have been treating it that way. I=E2=80=99ve been trying = to get all my testing done and he has been trying to get those same bugs fi= xed. > >>=20 > >> After that, I want to really revisit the API and make it more generall= y useful and less closely tied to the tools. What you are proposing below i= s a baby step along the lines of what I I had in mind. > >>=20 > >>> 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 i= s used by > >>> GDB (looking for .ctf and .debug_* section, > >>=20 > >> First of all, I think rather than having a: > >>=20 > >> =E2=80=94enable-ctf compile time option > >>=20 > >> Why don=E2=80=99t we simply make =E2=80=9CWITH_CTF=E2=80=9D an autocon= f option that is disabled if AC_CHECK_HEADER and AC_CHECK_LIB doesn=E2=80= =99t find the things that you need. > > Ok, in that case we need to decide whether CTF support always will ship= in libabigail, > > i.e, if the only dependency: libctf is meet, then CTF support will be t= here by default. >=20 > If the header is there and the library is there, then let=E2=80=99s build= it in without the config time option. I think we should do this but after = 2.1 releases though. I can=E2=80=99t see why it shouldn=E2=80=99t be there = as long as autotools disables it if the required headers and library are no= t there at config time. Yeah, although configure statements and conditional compiling make me = think that was a reason to not incorporate CTF support in libabigail by default = like to ENABLE_RPM in abipkgdiff. But for sure, these motivations could = have changed, just we need to agreed. > My general philosophy is: Use it more, test it more =E2=80=94 find more b= ugs. I personally haven=E2=80=99t been building or testing CTF. It might be= worth it for you to do what I just did with Fedora 36 which was in essence= : >=20 > foreach package > fedabipkgdiff =E2=80=94self-compare -a --from fc36 Actually I did the same experiment just with *some* packages in OL8, using abiddw and abidiff instead, so I will follow your advice :-). > If you can do something equivalent with Oracle Linux 9 which I guess is b= uilt with CTF, then I think that would be a really good test. I found that = flux-core https://github.com/flux-framework/flux-core is a really good sche= duler for this kind of thing. I basically spin up flux and then do: It seems good!, will do the same in Oracle Linux. > $ cat list-of-packages | flux mini bulksubmit --wait --progress --job-nam= e=3D{} --output=3D{}.out fedabipkgdiff --self-compare -a --from fc36 {} >=20 > You can either send me the PR and I will merge it into my develop branch = on github (right now practically empty) to be passed on to the list after 2= .1 releases or you can send it to the list and we=E2=80=99ll just sit on it= until 2.1 releases. The problem with the latter approach is you might have= to send an updated patch if it falls out of sync with the master. Ok. agreed. =20 > >>=20 > >>=20 > >> I don=E2=80=99t think that it should matter where we get the informati= on about the types from. > > Yes. > >> I would also be tempted to get rid the =E2=80=94use-ctf options except= I think 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 co= rpus that we get from them. > > Ok, IMHO, it just be needed in the testing harness, because at the end = of the day both corpus > > with the same input, will be generated no differences, just in some pro= perties e.g: filepath, line, > > column, etc. >=20 > Heh in theory that should be the case, just like in theory=20 > $ abidw =E2=80=94abidiff =20 > should always return no changes. However, I have found literally hundreds= of bugs doing that. I expect that if we were to take a substantial portion= of a distribution built with CTF we would find plenty of problems. Oh, I see, I presume such of errors will be raised running `fedabipkgdiff = =E2=80=94self-compare ...' as you show above. > I=E2=80=99m not enthusiastic about the syntax for the command line that I= suggested maybe we should nix the =E2=80=94with-ctf options too and just h= ave something like: >=20 > $ abidw =E2=80=94abidiff-dwarf # does DWARF to DWARF comparison= - fails if no DWARF is found > $ abidw =E2=80=94abidiff-ctf # does CTF to CTF - fails if no CT= F is found >=20 > Then the current syntax: > $ abidw =E2=80=94abidiff =20 > # looks for DWARF and CTF if both are present then it compares DWARF to C= TF > # if only DWARF is present then it compares DWARF to DWARF > # if only CTF is present then it compares CTF to CTF >=20 > What do other people think? Is there a better syntax to do this?=20 >=20 > I think that both Dodji and I kind of thought that wedging it into abidw = was a short term expedient and optimization and we never thought that we wo= uld still be battling problems with this literally years later. It is simpl= er than what I was doing at the beginning which was: >=20 > abidw > /tmp/.abixml > abidiff /tmp/.abixml >=20 > but as a coworker pointed out that is a non-intuitive way to approach the= problerm. I argued that doing A=3DA is counter-intuitive test and yet disc= overing that A!=3DA is mind-spinning until you realize that it represents a= bug. She thought a better command line syntax would be: >=20 > abidiff =E2=80=94self-compare >=20 > >> 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 > >>=20 > >> don=E2=80=99t forget abicompat > > Ok. > >>> 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. > >>=20 > >> I think that we should do a deeper rework here and work the way that G= DB works. In essence doing: > >>=20 > >> 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. > >>=20 > >> I think that all this logic should be encapsulated in an exported func= tion read_corpus and then all the programs use that interface rather than t= he functions which are specific to what format the information is gathered = from. > > Agree, because now days every reader implements the logic to get ELF in= fo: > > `read_debug_info_into_corpus' and `slurp_elf_info'. > >>> 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 notif= ying 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 > >>=20 > >> Dodji can weigh in here but this whole contex thing as an API is one o= f the things that I wanted get rid of in the general purpose API, IMHO it i= s too tightly tied into how the tools work. I kind of know what he was tryi= ng 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= think 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& ctxt, > >>> string& alt_di_path) > >>> { > >>> ... > >>> } > >>>=20 > >>> Please let met know your feedback, I'll really appreciate!=20 > >>=20 > >> If you want to collaborate on this, send me a PR and we can iterate on= it on my develop branch on github and then I will push it to Dodji right a= fter we release 2.1 > > Ok, of course I will do so following the advice of people that have mor= e experience working in libabigail.=20 > > Thanks for your comments! > >> https://github.com/woodard/libabigail > >=20 Regards, guillermo