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 D028B3858C55 for ; Thu, 14 Jul 2022 23:15:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D028B3858C55 Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26EL4FA0032705; Thu, 14 Jul 2022 23:15:47 GMT Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3h71r1e2a5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jul 2022 23:15:46 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 26ENEjIl011409; Thu, 14 Jul 2022 23:15:46 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3h70464q1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jul 2022 23:15:45 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JfEdWgEgahXTrC5iQ/llHmJm1SeB95U1zPlg1u04jaDdkqv3u9H9uvLwNEIPYWO8POL+u1FNzzva33LllbsB5Y63IqbQpBSicCPgH02trcNG8M4TN5hUy2KtX76F59Sf633d7gGpa8Og36TJkc6oFiVyhVs0sVUEVOS9QttiXrgGRPp4wFq7lCp1dYi7xogoVJsJdDpztojhnrE65badCVPZ6GeALMPLJqNEl7gTGwxWB9O62c0q1DXyN7JAxTuIJLr3tLT3pdpORF6fOGdzwL6lZmJHX0VwVce9P+oW8Dci0y7e1jg8yGW8Zcbkh7z6ahYkUZ3w+Qif63C4wAv77g== 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=QwvTQhPOFS2xcw4MgIRfMEvrxbRXKqnZYGgbsl4//BA=; b=CGomJZ7iS0HtGtohNTXeKC0FcWJvtiWy976b0DPsRH63bFKOrecRIASuuFa/KVeoDTS26VH5h8NZpanZ0UnL+bvFi+7zA4BWVbLPL56XgdA1hUAEMYek8/MJ/tKTy1NmYpyNzb9qOihzMk+ci0zJrMx6njFEieiDMNqVPsm4zojYWBBvdgnOxRI71ziXHXkkpwAAulV9xW9Goi9Yax/f+eTO4VI7gveIy2JEQ5z0bYCOPFmG77j5qPXexK4HaaDCADt9McOMK4a6uqIyPkWMmw+RpaFytQ34zkhBUeYA97Sf8wqRAvIBtYN0AKukAWhf1qezRgQKg1LTvy+e7NjTeQ== 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 SJ0PR10MB4462.namprd10.prod.outlook.com (2603:10b6:a03:2d7::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Thu, 14 Jul 2022 23:15:43 +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 23:15:43 +0000 Message-ID: <992b4e78-697d-89d2-5e3b-fbccfa464ed6@oracle.com> Date: Thu, 14 Jul 2022 18:13:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Use CTF as a fallback when no DWARFs debug info is present Content-Language: en-US To: Ben Woodard Cc: Ben Woodard via Libabigail References: <21824871.EfDdHjke4D@sali> <3494804.5fSG56mABF@sali> <2D2DA8C8-6793-4FA9-A923-A7D4C82748F4@redhat.com> <5203709.0VBMTVartN@sali> <4148AF95-8356-482C-A674-518A3AC0F488@redhat.com> From: Guillermo Martinez Organization: Oracle Corporation In-Reply-To: <4148AF95-8356-482C-A674-518A3AC0F488@redhat.com> X-ClientProxiedBy: BY5PR16CA0003.namprd16.prod.outlook.com (2603:10b6:a03:1a0::16) 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: 8409f283-4317-40dd-cb4f-08da65eec63b X-MS-TrafficTypeDiagnostic: SJ0PR10MB4462:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mK9g0gEmeBv+PjGKjnMZgzDeUwSdkzV2XERftJF8l3O/Fgp+MGMEPe/fhbBARoJ37Cku2ecVrSxFUdr6VLjOOdj2RMQ1G0NT+JjbRB75/nPmk3pFnDdLckp/XgVVjC2dloJ+Crm5NtdJFciWWE2aNy5JztVnizguXu1SNfdY4z3xF+tnyeUap1nskViPbKu9TrMWExiEhzsdQXHApWn7SWVG+ppHnAmEybK6zj/oYkTI9pMS7MkzSfSnVI6XgGzUIQdnNIRNK0rHYXNmgmFnQlBBEQb/2vwPcxoMKqTN2CjCQDOr+JpzF3ZfchzAu2eVJ25KgxcBiOehNEdKeWHNFv0Yk8qbxV/UCeThRDcI3Aqg7Ph1I5NNWenvV4QVT+GAi36zlNdwOGhnGkOq6fIuTllvxkcfAfYUXkTeUUlmVMgLoGLvfdro+VVPdK5pVl/4w54iNmxq9o9Ma19ftVMkqAB/nYw9WPPXGLoshR8dI2in4R8lqEHBKlkhkI/P8P9lbUkl0mcrPcN5GRBMgTXQBIhIldAYQs/cjh++88Qpw6dq+h6BrXtN5LZYwGiW1yIbQE/za1ZNUxdBD+KzIVGBB/Avjq9db8wskntp/w56jF1TEV+q8AVaUORwwQf6FtVkeAJfkrYKujpJaDlNo0kFIFViEUsn1mBlTjKVLLkgVs1XNzsJMW6k6KRce4AQHyV/Qu6Xh/tl9YsTeulZmrAbRAkdzfLyLoCBLQkBDlhPy9kUSWhsAwKXYMoqzhzZ3wZS0Po7EmRSXPn1NZroeUAFP3f0lvzYlmBaMywFs8wZWLHATMDX/pqaqUG8R1QqKUqZSOkdBctNihYfvG5jpC1KLEB3q7csPSvCbBpfHx4QRvvCzqdVMc8NDSxM4DlpzCsH2W1++nsvjA1d6yp0KkjYDw== 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)(346002)(39860400002)(396003)(366004)(136003)(376002)(478600001)(36916002)(6666004)(6512007)(53546011)(6506007)(41300700001)(33964004)(966005)(6486002)(8936002)(31696002)(86362001)(38100700002)(166002)(31686004)(36756003)(2906002)(30864003)(5660300002)(186003)(2616005)(66476007)(66946007)(66556008)(316002)(8676002)(4326008)(83380400001)(6916009)(43740500002)(45980500001)(559001)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MzM1eHJlMnA2N1dRWHFVUDRjYUY3N2RXRVNBeWlCZkNsT0xhV1RMUCtqeXhG?= =?utf-8?B?eEpuUzZUNG9zRVp4bGtiT1pUTitmYm8rZmV6WGpzYVBPMUlWek5QOTB6a1Iz?= =?utf-8?B?RzFkZnlBcDVVTlVldSt5azN6bFZUN0NJekVMYkxLMjVvSGZHZDl3OVp5MUIx?= =?utf-8?B?eXZVQ0U5U1hnYWlBSGVvRWx0ZjV2SVYvWitTTit1cDg3bUhCdDM4T2xsNTBZ?= =?utf-8?B?ZnF2VEVVU2NKYWJQclgzTC9lY1VIbHJUV0UvaTNaeUYyc0VFUEppQlB1NHpK?= =?utf-8?B?WmNyZFBkN1RGMUFMa0UwTXBEaytvSDNYazA4dlFoeHh4K0Y4YWVFMThVS2Vz?= =?utf-8?B?OUdoUFJwSCt4cXZLV1o3aVNsT2dNNmxoZm53NlZSMDhmSytqOGR0YjFGbWQ2?= =?utf-8?B?dlJ0RS9rcmpneHBEVXZXSkkvVnJJOVBlczNXNkhlNlRWdlFQTHd3a0doS3lM?= =?utf-8?B?VjNwVHo1am8yQThRMVdvVDVvNXpVS2I0QnhUbmZLYURtc1JXZlg5RDMzV1pP?= =?utf-8?B?M2xsUFZBSEVadGhUYW5IZW0xcDBsQmJDMXNTcFBobnpzN24wOWdjdnp2bjQw?= =?utf-8?B?aEpTSlNEYTBBa2FUQjA4Z1U4RjZieXVubVF3Zm5zZUZmUUNZMGIvSHRhSlY1?= =?utf-8?B?WmptWHFwT3llRTZxR04ycWYveGluTktKWVU2T1psbWlVWUo3S1FMc3ZKZzBo?= =?utf-8?B?eWhyL3pVbllyTVdpNjhpaTVWSjZUN2JFQVVrT1hjTG9CYUI2ZXhsK0tHRVNT?= =?utf-8?B?WGdyYncyT0FPR1lWU2FCV1cxdnR2Zldjd0JDM0x2ZDN4bnY2MC82K0o5SjNZ?= =?utf-8?B?YTBjSW5SY1RFZ2hpNUk3Uy8yOFVLVmJzTUs3SFFMdEYxK2FybG1Vc0RJMURm?= =?utf-8?B?ZHNpVlphdzdSd3p6THdSTHY3dWJYRUJ3NEFqcDNNeTFkQzV0ak9udUVaazZM?= =?utf-8?B?MmQzSmVGZUdjblVIWlN2NE5GblZhbHlKVFp0Z3ZsdGxUVHluQVNhRkZ3M0Iz?= =?utf-8?B?S2xKSHVpSnJlTVRjWFlEU1dUZXczTnBoUjJmSnBYeklLZUVtSW1icHljRlFZ?= =?utf-8?B?Z2dZeUVxSVkzQ3JGNEtNeVBJRDRIdU9FVUc1Z2tsbGFsdHFERHNlZE5NNGpq?= =?utf-8?B?aDhvMXBPd0JoYi9JalVIM3dpL0VyYm5yZFZVZlZRQnJCemVubHk2WG01bEJR?= =?utf-8?B?T1F4MFI5Rnhra2RKbXFFQmNZQVdGWHp3di9EMVRrU2hiSTh2cDBTUkw0RmJw?= =?utf-8?B?dnp2WUFZWllDRHZabW5sZTVld2g4akhMZlBldkQ5UElRU3RwV00wdS9wTWVU?= =?utf-8?B?b0Z3dXNhSGRtcFd0T2pGK1BrL1VVSkN1bHVFK2xGQ2Q2VElkb250b2pnRVk0?= =?utf-8?B?L090eWkvY2FWSTRCWWF3WmZSWDJocGZLTkVSSzUxS2FqU08wbkVSdk5ocnVQ?= =?utf-8?B?a3VxMk4vZGF2VFU5YXVJdG82MFhoVVhHQmhyeVlBa2hIVTlrUW5CWDdDL0Vt?= =?utf-8?B?UUVlY25XNWtXUS9MTVpUSThOcUNVMXBtN3VGSGd0UittOEJLcDhxUytsRzFH?= =?utf-8?B?THZpWXRPZEZpdHZJUEFoczVYam9UdTRQSU0wajBRQmtreEo4R0xzaVl3WmlC?= =?utf-8?B?aU1pU3JMKzRqcVFaZzNEQkJlMWlkN1hlenZvSFpsb1BtVDRXbzdRWHoyUlpw?= =?utf-8?B?UjcxV0xmWmU5MVhuTGdCalRXcmRvTGtXeERuQUtValpKU0hzc0VVZ3JyUGt6?= =?utf-8?B?dVEzc0pKUEFxSTJKMUFhN0pMSnBuc3YwOTdiY1Q1M1ZMQmJNWE9LQkFIZWVu?= =?utf-8?B?blpwTkRMWWJqbGYyVmNtUzN4SXU3S2xvUTAxMml3c0RtYlVzZDErWkhWYWFp?= =?utf-8?B?VGVPSEtZSk5EK1pqNU5HS2hpWS9jdGF0cFd5WmNETk5PU2daUmtELzkwaEwv?= =?utf-8?B?aTJ5VldNZXVDMjhMUW5TVklxSDBKQ3Z1azhXVmw3ZXpRZU9sQmd5Zkk5NytO?= =?utf-8?B?eHgvMGpBUS9pYSsvWmpRSGRaQTUza3M5bVBwdStVSzg2UnBuellDc3lRU0d2?= =?utf-8?B?T3dONC9Qa2xORTJxaFFWeDhIdzhxVTBjL3RhNTNuYjlyekxlcnNSWEtmWFNz?= =?utf-8?B?Q295NEJoN1dMRkpqSGtydXVMUEpFNENVRkhCSGpXVGUySXNycUVkcWRsdHpE?= =?utf-8?Q?EaGPzJFOa9vyqjqpFKSbGrA=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8409f283-4317-40dd-cb4f-08da65eec63b X-MS-Exchange-CrossTenant-AuthSource: MWHPR10MB1407.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2022 23:15:43.0806 (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: imRuEE0T52BJR/9Nxl/r/tp1VSo1JCnoKNEtCJypFe3795cdFVvLtW5N0KK53PFDGUvbZs7Ro7IN0z0wNs32nG+N4Rz0NVW9RdT4gNDEF2s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4462 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-14_19:2022-07-14, 2022-07-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 mlxscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207140103 X-Proofpoint-ORIG-GUID: Exa2MNQcMMO6MOX_BN5KBAc8chzLx6Fw X-Proofpoint-GUID: Exa2MNQcMMO6MOX_BN5KBAc8chzLx6Fw X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SCC_5_SHORT_WORD_LINES, 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; format=flowed Content-Transfer-Encoding: 8bit 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 23:15:52 -0000 On 7/14/22 13:09, Ben Woodard wrote: > > >> On Jul 14, 2022, at 10:35 AM, Guillermo E. Martinez >> wrote: >> >> On Thursday, July 14, 2022 11:01:41 AM CDT Ben Woodard wrote: >>> >>>> On Jul 14, 2022, at 8:06 AM, Guillermo E. Martinez >>>> wrote: >>>> >>>> On Wednesday, July 13, 2022 8:37:13 PM CDT Ben Woodard wrote: >>>> Hi Ben, >>>> >>>>> So let me begin by saying, I think we should push changes to the >>>>> API like this until after 2.1 is released. Dodji isn’t calling it >>>>> a beta or RC yet but we have been treating it that way. I’ve been >>>>> trying to get 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 useful and less closely tied to the tools. What you are >>>>> proposing below is a baby 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: >>>>>> >>>>>> Hello libabigail team, >>>>>> >>>>>> Talking with my colleges Jose E. Marchesi and Nick Alcock about >>>>>> of the user >>>>>> interface provided by abidw, abidiff and some other tools in >>>>>> libabigail, 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 used by >>>>>> GDB (looking for .ctf and .debug_* section, >>>>> >>>>> First of all, I think rather than having a: >>>>> >>>>> —enable-ctf compile time option >>>>> >>>>> Why don’t we simply make “WITH_CTF” an autoconf option that is >>>>> disabled if AC_CHECK_HEADER and AC_CHECK_LIB doesn’t 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 there by default. >>> >>> If the header is there and the library is there, then let’s build it >>> in without the config time option. I think we should do this but >>> after 2.1 releases though. I can’t see why it shouldn’t be there as >>> long as autotools disables it if the required headers and library >>> are not 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. > > I think at the time CTF seemed more experimental. Now that you added a > lot more testing, it feels better tested and thus more supportable. > However, we’ll probably hand all the CTF issues to you and Jose. Agree. > >> >>> My general philosophy is: Use it more, test it more — find more >>> bugs. I personally haven’t 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: >>> >>> foreach package >>> fedabipkgdiff —self-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 :-). > > Note that this relies on Koji if you guys don’t use that you can fall > back to abipkgdiff wit a bit more scripting. > >> >>> If you can do something equivalent with Oracle Linux 9 which I guess >>> is built with CTF, then I think that would be a really good test. I >>> found that flux-corehttps://github.com/flux-framework/flux-coreis a >>> really good scheduler 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-name={} --output={}.out fedabipkgdiff --self-compare -a --from >>> fc36 {} >>> >>> 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’ll >>> 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. >> >>>>> >>>>> >>>>> I don’t think that it should matter where we get the information >>>>> about the types from. >>>> Yes. >>>>> I would also be tempted to get rid the —use-ctf options except I >>>>> think that we should have the ability to do something like >>>>> abidw —abidiff —use-ctf somelib.so >>>>> And it would read the DWARF, then read the CTF and then compare >>>>> the corpus 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 >>>> properties e.g: filepath, line, >>>> column, etc. >>> >>> Heh in theory that should be the case, just like in theory >>> $ abidw —abidiff >>> 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 —self-compare ...' >> as you show above. > > Same errors just using fedabipkgdiff is a bigger hammer. > As I’m tracking down issues and try to boil them down to see if they > are duplicates the process that I tend to do is something like: > > 1. automated testing as I stated above with fedabipkgdiff > 2. reproduce the error with fedabipkgdiff manually > 3. try fedabipkgdiff —dry-run which prints out the underlying > abipkgdiff commands > 4. run the abipkgdiff commands manually > 5. then if I want a closer look then I use abidw —abidiff > 6. if that doesn’t tell me what I want then abidw > > /tmp/.abixml; abidiff —harmless /tmp/.abixml > > OK, thanks for algorithm. >> >>> I’m not enthusiastic about the syntax for the command line that I >>> suggested maybe we should nix the —with-ctf options too and just >>> have something like: >>> >>> $ abidw —abidiff-dwarf # does DWARF to DWARF comparison - >>> fails if no DWARF is found >>> $ abidw —abidiff-ctf # does CTF to CTF - fails if no CTF >>> is found >>> >>> Then the current syntax: >>> $ abidw —abidiff >>> # looks for DWARF and CTF if both are present then it compares DWARF >>> to CTF >>> # if only DWARF is present then it compares DWARF to DWARF >>> # if only CTF is present then it compares CTF to CTF >>> >>> What do other people think? Is there a better syntax to do this? >>> >>> 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 would still be battling problems with this literally >>> years later. It is simpler than what I was doing at the beginning >>> which was: >>> >>> abidw > /tmp/.abixml >>> abidiff /tmp/.abixml >>> >>> but as a coworker pointed out that is a non-intuitive way to >>> approach the problerm. I argued that doing A=A is counter-intuitive >>> test and yet discovering that A!=A is mind-spinning until you >>> realize that it represents a bug. She thought a better command line >>> syntax would be: >>> >>> abidiff —self-compare >>> >>>>> Or maybe it would be >>>>>> but in libabigail is done by the >>>>>> symtab class), so I did some minor changes in abidw and abidiff >>>>> >>>>> don’t 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. >>>>> >>>>> I think that we should do a deeper rework here and work the way >>>>> that GDB works. 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 >>>>> 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 functions which are specific to what format the >>>>> information is gathered from. >>>> Agree, because now days every reader implements the logic to get >>>> ELF info: >>>> `read_debug_info_into_corpus' and `slurp_elf_info'. >>>>>> corpus::origin origin = opts.use_ctf ? CTF_ORIGIN : DWARF_ORIGIN; >>>>>> ... >>>>>> if (origin == DWARF_ORIGIN) >>>>>> { >>>>>> // Build corpus with DWARF >>>>>> } >>>>>> if ((status & STATUS_DEBUG_INFO_NOT_FOUND) || >>>>>> origin == CTF_ORIGIN) >>>>>> { >>>>>> // Build corpus with CTF >>>>>> } >>>>>> >>>>>> if (status & STATUS_DEBUG_INFO_NOT_FOUND) >>>>>> { >>>>>> // lets to know the user that no debug info >>>>>> // was found in DWARF neither CTF >>>>>> } >>>>>> >>>>>> Doing in this way, seem to work, however there are functions to >>>>>> notifying 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, then we >>>>>> could split common functionality/interface for both readers in a >>>>>> base class: >>>>>> >>>>> >>>>> 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’t 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; >>>>>> >>>>>> void >>>>>> exported_decls_builder(corpus::exported_decls_builder* b); >>>>>> ... >>>>>> }; >>>>>> >>>>>> class dwarf_reader::read_context : public base_read_context >>>>>> { >>>>>> ... >>>>>> }; >>>>>> >>>>>> class ctf_reader::read_context : public base_read_context >>>>>> { >>>>>> ... >>>>>> }; >>>>>> >>>>>> >>>>>> // Now reusing refers_to_alt_debug_info for both readers >>>>>> bool >>>>>> refers_to_alt_debug_info(const read_context&ctxt, >>>>>> string& alt_di_path) >>>>>> { >>>>>> ... >>>>>> } >>>>>> >>>>>> Please let met know your feedback, I'll really appreciate! >>>>> >>>>> 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 after we release 2.1 >>>> Ok, of course I will do so following the advice of people that have >>>> more experience working in libabigail. >>>> Thanks for your comments! >>>>> https://github.com/woodard/libabigail >>>> >> >> Regards, >> guillermo >