From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id CF106385627C for ; Thu, 14 Jul 2022 15:07:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF106385627C Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26EDcpik016423; Thu, 14 Jul 2022 15:06:53 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 3h727snw6j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jul 2022 15:06:52 +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 26EF5RLE018401; Thu, 14 Jul 2022 15:06:51 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2109.outbound.protection.outlook.com [104.47.58.109]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3h7046bq4b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jul 2022 15:06:51 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRR+3ZmgCV7vr17wriDELk4OQg1m42gHH8sRDbeEBnoDt0cbwm97GmKb3sHLU/QcCAtdXo3ClKKgK25Tma/Pa/cWJ/5JdXGlQkiM/OUSNuzva7Y4a2z+3E26nBmQwsO+PyXUpgAKYxcXJLtbhSWaNdcvVZKqXoLZE/P/CBIjZIS11cOh9FBOxsHpEpEePGHtQJlATWwJ6H9dT5ZRjm04avoTth5wum/ymcTLRlFA7Ggv+HT6OXV3MI4jmeZ8IBbbuPt5xxeUURyUBsFUYYGIkavd7z3EmPzRFKTM1S9SiO2rJhIDvG06VrZZNIxSZcg1cUcBV+rUkxHTA8s1/xoAcA== 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=xPDCY3/aLCjim8eI42S7m5hayQvnfZ+B8KznsHCbx/Y=; b=VEixvrV5CvYERgq33mkhjE/msCMiIwkEIBoFPIdM+L5WkBmzOebyHtU0TftZFSQ95tn1K7JYyzyIPre0VHRvdOErvAn3ZS+6MgCGjX/nB+ifdpOUUSFokW6fRwpGUbTuNPaiZbOkyPwrkGW7FvkGSxuBVEJoKr8yVJlLFzTEUVP5t1QMMp3ixFkukcQQdxYCpCtbiGznuXeQnGPgB9VvD2P1/AuXydBClppb/FROP49/rj0t32xKR0LC4XMLzQq/YnbwXlB+4JVOJkXDL3wPir0GiSR6ifBIoRjMwqa0Z6Om2SRNrtwkVnVeFplU1kU0xF6mCvq5Ep+Jwvl9gXuxcA== 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 PH0PR10MB6435.namprd10.prod.outlook.com (2603:10b6:510:21c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.22; Thu, 14 Jul 2022 15:06:48 +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 15:06:48 +0000 From: "Guillermo E. Martinez" To: Ben Woodard Cc: libabigail@sourceware.org Subject: Re: Use CTF as a fallback when no DWARFs debug info is present Date: Thu, 14 Jul 2022 10:06:43 -0500 Message-ID: <3494804.5fSG56mABF@sali> Organization: Oracle Corp In-Reply-To: <952C9B5A-C267-4BC2-9DF1-4045C73C704C@redhat.com> References: <21824871.EfDdHjke4D@sali> <952C9B5A-C267-4BC2-9DF1-4045C73C704C@redhat.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-ClientProxiedBy: SA9PR13CA0109.namprd13.prod.outlook.com (2603:10b6:806:24::24) 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: ce21bfdb-37ea-4a10-5a3c-08da65aa798f X-MS-TrafficTypeDiagnostic: PH0PR10MB6435:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QF6XP1GS61gXC00eVLI8Fpl/5GVQgZV4QaEL1yhp3V6H2hn5Y574t9V0xPfbfEYwOXReeSPATle4xO1nBscWKF46vlLgBc67CzDenfLqeRWWVdVs4YZpquJ231NCA5M2BUaPKdnrBIsGgOg4c3kX7qrvdAZaPnrLIzdJId5uGaQAJ4WVTz2ymMZl7cW3NfOZhtMxTrehcWogZntxLAGKicDCsq26FNfdkVnt3tepvNE8F3Sph6sWSpYKUL/1TTLPUyltAd5Zv/DeD9HCSzCmswOnWHO1STHOdm/tJbQs+sa4VZPy9/wrl78WHCl8ZITujjI5k096G6pF4xd8ru5+WrbepzbtmQiCCN2SP8kQRaCaWcwCROueRtz6/Q2j9jT4hHmEYuMAY1AJxAu/oSzd4C3WVI1BqmHK6l1pzkzMCjDe/XJAz/AQ7NiDpYRJxGFg8W4SixW3tjjuGeUm83PEamJag7uAaDLOcQoXB0+nXxiK5Lc6u9yi3tBj5S36VcP0LKh/I4mNcZxL4QaYg0IBPikJO+scruFrLB48blHjeWR+NYzHqE4v87HeRjiMArZJmg7+Aii6GXglIedZpXUol9PYsggDQguDy1kf0XSZoI0MQa5h3DJpLzPrPrOSXrGmTQEVazoUhENoG8xd3mF7IVpiYZ7LVRRrd50zgW6JWf0ukdwNPX8h9fHXuZipI5bpTgSxMMIcP543yhOFhJFJuGN9iWiNYXg0i9bw/1+YarxNUPP78wRaSflPP0dr6H1MXdh4x25Fow5Lk1qETqlG5KfZvONWBFDCwOHroz0DP7FZIcmypZYfMfCglsI+DsU2usiYxRQfj2F3fmo5frlNbA== 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)(396003)(366004)(346002)(376002)(39860400002)(136003)(6506007)(66476007)(86362001)(4326008)(66556008)(53546011)(83380400001)(8936002)(186003)(316002)(66946007)(8676002)(9686003)(5660300002)(52116002)(966005)(36916002)(41300700001)(6512007)(6916009)(38100700002)(2906002)(33716001)(6666004)(478600001)(6486002)(39026012); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VHJLaVV1cTBWSDI3VzFhUDRjSHJzQVVHZm9kVi9iTm9Tckp6NlAzWGEzME04?= =?utf-8?B?UEphYzcyMjhNZEFibktGYThXeklvUmhWc2U0bUxSR0xRUHIvN1JzUlg4dE9z?= =?utf-8?B?YWhNZ00vSVFTelFvRkZOZ2R4OExWUmZPK0taaEhNdG53QXphTmhxelVNc0RM?= =?utf-8?B?RVFIelpIRXJQZW1DSzR1dFdYZndRM3Q2QXJ0aVpieVpVQmhHdjFDZGppbUxo?= =?utf-8?B?cmlOczRUSFNNblVCWHlyOGlhcDYyRSt3SlJLaDN6UGhJSUJJSnZGazBxSHZF?= =?utf-8?B?TkZBdXAyQ3JwZTZCbHV1cG5uSmNXNjd1TERoT1hmSHVpTEN0N1RXeDFQUklG?= =?utf-8?B?emR1ZzdsOGt1ZmFpNEV5dW9PaytnTlJNc0ZueDQrZ1h5NEp2VXdsY3l6WWdI?= =?utf-8?B?QnVyMkNxNTU3bjE5dDFPTmZaK3dFSEo3aklXcVBiQXBwYXlmMGxMcmJBTGcr?= =?utf-8?B?VG9LdHdlRzJyTTZLRUgrK0xGeHpJeUlKU2dJdFdvWngxdFNxQk5ua3pDZW9k?= =?utf-8?B?SVhnZFovK1VIeWVXUG1EQ2EzY2RvVVBtakhlN1cxTENnb3REZ1ZHWERpeTVD?= =?utf-8?B?Z1ViK2VISHFBVWJSeU1EZnhYV204aDdUeFp1eW1jMko2Vmp4SHRBVm1lZThW?= =?utf-8?B?L1dqUHFiMTI0YzcyRFRvN3lxMGRXdk5MdVdZaE9oMUdBT3dVT2c4dEx2amVy?= =?utf-8?B?SG1rQW1jMUM3QTFDTVBDbWdHNFNIaFpXaU0vY1dvRzJaK2RwUVN6Yk45L2JU?= =?utf-8?B?WW1zcjBhQ2dxZ0lSaXYxMHFSWGRUREVGS3IwU0lSQjhLdnFpR2JmK2NhSkJz?= =?utf-8?B?NXdIUFp4aFR4U0lvMjRPZ0NmNWJNMzdZZEVLSHB3TnNUc2pFS1NmTzcvc0Zz?= =?utf-8?B?RWpoRWt5MW16WitYYnFhTzVHbkdIMm5Nb3hPVzlxU2ptcFI5aHBKVXFZYS9J?= =?utf-8?B?NDhRN09tWCtiVk90VjZjck1zY2xLYXdrOWdwVkNvWjZIUEZmcHV3VGJ4MXRB?= =?utf-8?B?b3J4MkhhU1ZFanhVQUFISWsrS3dsWFBUbnN6c0lBYnBuZVhJQU95dG9aQTRI?= =?utf-8?B?amJQZ3JyRzZzYnVsVDBLWmNrOXNPY2I4eEFGQzYvTHMyT0pUS3dTZmx3bDYr?= =?utf-8?B?M0Y4V2dmeklMNVVpamhiUkhVd0dKVW5xZDRvR21ndVV3NncrOS93aVU4TnVY?= =?utf-8?B?cjFjZ3hPNUVacVBlOTV1dVJxMnRaV3RjOTFQZjhhRURwMEZlZXFiSHV2dzlD?= =?utf-8?B?T2hSMTJrbFVSWmZHQTJMdGdyMm9OOHR5N0pMcEppUHRnOUxSTlBLUFJVYUtK?= =?utf-8?B?U293MVVTb0R5eitucG92a2tpV0orRkZnUFNHSTUwTkxsdGdyQkw1eTNQdm96?= =?utf-8?B?N1RkdXZMb1R0UnNWZ1dPVGRYeFhXK1VhSjlvUmVwQ1B3d3dVbUpxbHRhR1Uw?= =?utf-8?B?Q3FZOGMzbkphY2Z2cWI1V2w4aDQ4Q2d5K2NIOFJDQmUvbm1nM0xXdkV0Z1VO?= =?utf-8?B?MnR2c3BFSk5JVkhNS24wTWN0MFhLclFseDQ5NnpZQjZocEdMNWxaeFBmZlhv?= =?utf-8?B?L2U1NUhjemN1cFhnU2VzUG15dTlXUE5jTUllL0JHTnFoRXJjbGprMU02Rmt0?= =?utf-8?B?ZkFOZk92dVNZWkdsclZsNk04eHhZNk9IaVE4aXNrOS8zQmpRd0w2bWViYkVP?= =?utf-8?B?RUxrTkdzbzZiSmI0b21MZEY3eldBR0YrSGc0Y1hRa2pZcU9uZUJiZDVPVml6?= =?utf-8?B?WTRhNTVvTjhrT05SaGNLcmhBL1Z6bm1WYUppS0pSa1NuYlJkTnEvcm9hT05n?= =?utf-8?B?UG9FSU1LV0ZhN1pTaERRZGJwVllVYUlQWGErZTFyUytSUXMyQm9CWVdDbHBu?= =?utf-8?B?L2tJSS9uaFFJMXV6TThCQ2N4elZsTzJEOHZxT2RITThrcTNoUW4xTUF3WGth?= =?utf-8?B?Z3h4aGc5dWJCYVgyb1NLZlowTXZ2dk1oV2Exdi9qbmJ6WGE1a1BibUtlVnhZ?= =?utf-8?B?SkovVGE2SFFlQXNyU0lUY1pCMDhUU1V1Tko4Wm9ETjJwalpvWHlMbFVOa2R3?= =?utf-8?B?ZXhSa09BNzZoZ0VVQjdnb0FrNTZ4KzkvMlU2NjJKeTVOUHAxZlAvazltUk5N?= =?utf-8?B?cXFXa1RnYkppT0hBNDR0WWZHS1k4aFIzUGt2NEJJMFFrUENCWHU0UU8rcjRY?= =?utf-8?Q?9qdNeRqrjLzyVt2yt8H8fFk=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce21bfdb-37ea-4a10-5a3c-08da65aa798f X-MS-Exchange-CrossTenant-AuthSource: MWHPR10MB1407.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2022 15:06:48.6348 (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: wxUO+IUX3xUaykzbkiNlzdHJ1kUTIzgjkAOBd+zb0sFNirprbW9hz/3PEqcHCcyC5QO2ImFzm8z3cnhrQRz8NihY2C7p3dRqBwmGe/Gkb24= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB6435 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-14_11: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-2207140065 X-Proofpoint-ORIG-GUID: XcrHTFN3qU6EdD4AvaJedlOcz4LyeKLH X-Proofpoint-GUID: XcrHTFN3qU6EdD4AvaJedlOcz4LyeKLH 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 15:07:04 -0000 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=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 fixed= . >=20 > After that, I want to really revisit the API and make it more generally u= seful 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. >=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 = the user > > interface provided by abidw, abidiff and some other tools in libabi= gail, 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, >=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 autoconf o= ption 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 there= by default. >=20 >=20 > I don=E2=80=99t think that it should matter where we get the information = 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 corpu= s that we get from them. Ok, IMHO, it just be needed in the testing harness, because at the end of t= he day both corpus with the same input, will be generated no differences, just in some propert= ies e.g: filepath, line, column, etc. > 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 wi= th DWARF > > debug information, but if it is not possible (`STATUS_DEBUG_INFO_NO= T_FOUND') > > looks for CTF info. >=20 > I think that we should do a deeper rework here and work the way that GDB = 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 functio= n read_corpus and then all the programs use that interface rather than the= functions which are specific to what format the information is gathered fr= om. 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 =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, = then we > > could split common functionality/interface for both readers in a bas= e class: > >=20 >=20 > Dodji can weigh in here but this whole contex thing as an API is one of t= he things that I wanted get rid of in the general purpose API, IMHO it is t= oo 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 mad= e this class to pass them all at once. > I think we need to think about making a good general purpose API and I th= ink we can do better than sticking a data structure with parsed command lin= e 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 afte= r we release 2.1 Ok, of course I will do so following the advice of people that have more ex= perience working in libabigail.=20 Thanks for your comments! > https://github.com/woodard/libabigail Regards, guillermo