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 11B1A3858D28 for ; Wed, 7 Sep 2022 18:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 11B1A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com 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 287IScAN003012; Wed, 7 Sep 2022 18:40:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : to : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=9G5kCFqCkKOT8zY4vusJTsdLE/vrc+FcfFvMwLJP6Vs=; b=DxY5QMZ+sUiGisgniF+Qbk90bdK4rYgryH+B15sS5mNv//eezozwN1NmxtkPmySIY8oM BrSWb0kiSFzTNZ6piAOBsmZtqVAWphr4g+Dx2G4ANJmowO6oPTg0hKG9PEYr7lhm5faa 2+o7maxRJVelWXuh8WF54wwIOrHPGWTUHEGeFRCdEGTw6hYDPL9wQinlDrgjnoZxAT2p en/R1mA9idtjP7xDctFfrbi1a7yZQlM3sk9TM6fMGL/4Hlu4xdyWoOXO14nXRswFEDbe mZCO7DTVxwSZZdvSnk+RHsEywXUUxjgtcCrFxQO1RzcKc2G+ZkqugDfSGJV4Xf1pJKQ7 MQ== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3jbxhssrmp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Sep 2022 18:40:40 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 287GWsxE030973; Wed, 7 Sep 2022 18:40:39 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2109.outbound.protection.outlook.com [104.47.70.109]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3jbwcaqu70-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 07 Sep 2022 18:40:39 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aWvbPNyQoL+Aftom8dfY6nTjvdRQK4WnVrk97OHC19glqf/uFJwF5HqJ2TuIzk2lXScLR5CUtwCJttgfs52zaVRyiuw9QcK0O4h7Wq4KdTRIsaziX3okRfUsCs5BA6f2MF0OXhjBcxOh8hdzHyZ4We/mEwYLFef3VizeKpjhD0PyJghwO6GZu7+GiygSZCbgVRoPXP6gmN1O0hjraP7xSe8nqrR0u1Tju/VTV9GFHeYY/0HncYxPvkNoHSZ3DiW6ah0TSdWGiHilCZLOPjNOo6xEVBw9adZ7zTrWRlhC+iNyjEwKkKqQYYcFu0/3NkSWQVKWYotbjdtqPrPhmJlhnQ== 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=9G5kCFqCkKOT8zY4vusJTsdLE/vrc+FcfFvMwLJP6Vs=; b=hd7zqphOQjJ/oxe7g6VDB7/xLHA69GkdA88dSedPmBIjeodqC35bdHE1Y/y/XsdVB5ZNxQR9fuPTlUvbUg4+L9AtY+2JV5JdDfUuXMRujyiwhlYbVH61gD9JF3mzfeCSkpa78ILQPfEc9QsscweNa8d1Y1WY61Lf56GUs8gBqqpX/l7+W/q15dlaAi8EkZBCKoCagwJIBDLwNL0OWDTiUtnDQPdeVbXZB34l4TImTWaQAV3nrIBPS6nBvS0CaKLZFTrPlwWFqB0/KyLt7klUpv1L9dmb/pOd1j1PCd9rv0bpdAm9UorMeyJ9lShExOGz3/NzKLGG23A07UuiRLo1xA== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9G5kCFqCkKOT8zY4vusJTsdLE/vrc+FcfFvMwLJP6Vs=; b=sigwfPUYCVlnwc22Z+Tp7FV5vFuQohc+g8QWtb/1hT0qCVjtgnEoZkZdVL6IXHfvkl+OtWmv+NqK9E/98s/1pqzGYNUQSGNH8bdBzpS6mYnMahFgqMTnBcbfZ09KLF6bEoSozs/wyt7M+zJ3+RhwystlTmog6Zp1hP+6qsI9qEc= Received: from MWHPR10MB1407.namprd10.prod.outlook.com (2603:10b6:300:23::20) by CY8PR10MB6706.namprd10.prod.outlook.com (2603:10b6:930:92::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.14; Wed, 7 Sep 2022 18:40:37 +0000 Received: from MWHPR10MB1407.namprd10.prod.outlook.com ([fe80::18e8:e5f2:59a9:1ff5]) by MWHPR10MB1407.namprd10.prod.outlook.com ([fe80::18e8:e5f2:59a9:1ff5%2]) with mapi id 15.20.5612.014; Wed, 7 Sep 2022 18:40:37 +0000 Message-ID: Date: Wed, 7 Sep 2022 13:40:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH] ctf-reader: Lookup debug info for symbols in a non default archive member Content-Language: en-US To: Dodji Seketeli , "Guillermo E. Martinez via Libabigail" References: <20220831151603.915945-1-guillermo.e.martinez@oracle.com> <87k06gis6h.fsf@seketeli.org> From: "Guillermo E. Martinez" Organization: Oracle Corporation In-Reply-To: <87k06gis6h.fsf@seketeli.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SN6PR05CA0012.namprd05.prod.outlook.com (2603:10b6:805:de::25) To MWHPR10MB1407.namprd10.prod.outlook.com (2603:10b6:300:23::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWHPR10MB1407:EE_|CY8PR10MB6706:EE_ X-MS-Office365-Filtering-Correlation-Id: 2b80879f-3506-4b62-dfe0-08da910074e6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nqqXiwaYeAGCIl2FDjgwIEl2igcf9miQBDcHyrRxGLu9FAF98M+0xjpsEG6Wtbxw3VGJ+E3XhTfE3lrhnh0kZA79c9EcArqhjYxTbAOqzqRw4nL0OcZrJNWq7HaWE27qDuGFbWZElfe2DyLtOWMmQ90K6jSin/5t572Hg4bE0gqXPyqeijZa6u5LeOwGIRbVd5z6yzw4Ox1PWl/0c510y1fFI4EpzIqWi89S7rQ86jBgpWt6p38F7X8NhFGTtneBrOzYjqyI536li5wykQy9Z7gD3Mngwm+N9lgFqL/882o3pkiOQxgIrwU3EMOtaq0mQZbKetaXaiU0hKMn+xEB8Vy5BTIWRolgBVsI6CQiW/47ANOLElMHcK6YmtjttKVDHvZ/MYY4/RL7bIyDCMcNOdOX6kOwESAmWOynIanwNiiEXwd4OtB2c8R6YHTK41NT6n+FaqzwbpyvmQZ0X/QCvWb9fql6aXkSOjl1QjkxIWmDS1YAuvsdwmVN+6TICWWlFVryLF/KgdVnvM3MhJZQhcs4c5uAVmsEUE6Y7N+uXe9TdPpVk2NBhZ8HEVjjWSW+DVI4ciSoIzbzCRzeuyQmH2RLpe7QYivcKWeEnMK0YNdIWVp+XDPnWtc5qgEz6Kg0z3FoxAPbg+XTXVuAx8QMR81WJoDx+E8I+savbNGEXriGwmHo4MOCjtVfT+dHEHOa3uirpqDrK2D8LQeYTSEoYqc/F4rcUnyAecCuvhM4vGUGJbsZa9n/QbMRApUxLkyWN5WdhjNQnhxI19B4f8QYjzmxbhaAT9FyqrJHlaa+zgrrZGRaKCQSN/NcQ7JnXTxe 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)(39860400002)(366004)(396003)(376002)(136003)(346002)(8936002)(31696002)(966005)(86362001)(110136005)(6486002)(316002)(478600001)(41300700001)(66946007)(66556008)(66476007)(83380400001)(53546011)(8676002)(36916002)(6506007)(2906002)(2616005)(186003)(6512007)(6666004)(5660300002)(38100700002)(36756003)(31686004)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZytOc2Q2S2xSdVZYaUtBSHBveksrUnU4eTRYeHc5NzJhY1Y0VzJqdmpHYnEx?= =?utf-8?B?Q2RWaFpDd0grWEJLbWhoUWwzWUU1UUJDWWVaenlteFFUQ3FaanpRRnVjR1VU?= =?utf-8?B?OUtxWDh0OVhGUkNqVXI4Ung2ME5aVURHQ3hDNVd5QTVYaGtKMU9xcGZKN0ph?= =?utf-8?B?UTVaQ3FHSkF1elhMTy90dzRBRjJTbjdmSXF1SS9ZcHR0K2lpZFAwN3l1Q2Ur?= =?utf-8?B?Tk9PZkJkZTBhMTlsdkZORVRyUE9rM1IxUUs5TGQ5WU42OUZqNVg3bW9GcGVZ?= =?utf-8?B?alB5YjlTN0Q3alVlc1pud3VoTzhjSUJxaTI4SmdKMTN3clRqYWNpRDhmMkMr?= =?utf-8?B?bHF6QlV6Tm8xUjdFRmdDRkpNVG5iTnFIcUtpZlU3a2FKSUtDMW9qMEdpY0do?= =?utf-8?B?bzdlTzJZcTJFS2xycVhrRDVmR2xxVkoxSTFEeDRRaTA0WmNtcWRmaHNSRit2?= =?utf-8?B?QWxIM0hpbmRrMmNVdDVRTUhsS2dVMlpwNmdFVGwvbEg2RmthdkZUQm1Ec0xS?= =?utf-8?B?di9CVGFLKzFYM0hvWEQvTmJYckVQelFxdnRxMlBWc2dhU1BqQ21TSWpLKzRy?= =?utf-8?B?U005UEFjMEFJRmVHdENiRlJXK1A5ZTBTWEljbG83bXBnNWhzTldGUUIybHpk?= =?utf-8?B?ejVpUzIvUlE0cnRjQjNUSmVZQU0wbldHWEk0ekdMRXRVL0pyT3VESUhWd242?= =?utf-8?B?UnIwY0xhanBmY3pQdDF6NzJRbmhvV0JtVzB3TmlnaEE3YUdQVE9QYVpEaDg5?= =?utf-8?B?Wnk5bUdBQUxKelNwZXJNUktLMUxFbk82UFZmckRJZnV2c2JOZHpOYVpjWHA5?= =?utf-8?B?NFRnTmpZWFZueFFCa09WdFNmZEk0Ym5GNWlTN1lFWDhvZHBNVDh4c0hRRUx3?= =?utf-8?B?YjJmTlVqV1pYVmh4Z2dVaGlnVjFyRzh3eUtzRHlJSDRjbFk4c3AvREltNGJi?= =?utf-8?B?cVB4WEl2d3lBZnEyc3RjckxaV1BtS1hGbFkwcUFCbWhueUhrL3haRGg2S0Nr?= =?utf-8?B?dlE3MDhDRkZaQ0haank1RGpockxBUURydlR5eEZqaXlGUXNRTUV2V1kwdWUz?= =?utf-8?B?Y1dtQStHOHd6YmovQ3YxZGxqOGRiNnRmZHBlTDBDa2xSVkJhbE5MWlJSYzlI?= =?utf-8?B?SFNML0NLY3lVeGFvOFJpNGRmUUExdnVkQUgyVUdPN0daSUp0UGhvK21WcUU2?= =?utf-8?B?aU1yMGdxdDVPTmV1RTBFeHpLemdmNkRHdy8vNmUyQWtWRmFzVC9OeXIxM1Mx?= =?utf-8?B?ZjJyVldaUDFnNXIrNzg4R1oyY1F4anlOZmNxNlJ3dEpVSkpjQklsSFBDTWpx?= =?utf-8?B?bDlWMldOT1RUOHlQUXlhcVdkUGJtUHFISWlxOHM3czc4UWZaY2JKdTFMM2JE?= =?utf-8?B?eFFvMko3TmhvelpFaGZpZWVKWjdEaHpvRzhQclBFYTQ4U3dadlFjV0lzODMx?= =?utf-8?B?T1Ewajc0OFVGWTgxUFpWZWt1UWpFa1c0a29zdGhEWlFTWHFkVUhVbEp0aXo4?= =?utf-8?B?Si83VldjZXhPNmgxd2prRmtieWZOUmREbEVqTkZqelRPNWlyMGE1OWF1RVQz?= =?utf-8?B?d24xTnBNa0FndFQ1OUoyTkk2c2RnR09PM3RSVTdKUjI2YVgzTmtIbEd6YnQz?= =?utf-8?B?UG9DMmNBM1EyZ2djMnI1aWhvL2RnWWNqckFVb3ZpU2oxUG1oRTJQblh2Y1kv?= =?utf-8?B?VldxdjdNS2xWaFF4bHRhdXlkSjdGU1dhTVBCclVuLzVBcE1rdmtSdGcxKzdL?= =?utf-8?B?NEdtOTE3Skp3SlpjM1JENHhTQTBJNVZqY1lFTVBCV3M1S1Y4azJ3Y3FKUUwx?= =?utf-8?B?d3NtV1FuRFhFWVRVNUNJTWpVTlJyMnVzVnZxSUtMRHpXdTRCcjFCdUZwdzlK?= =?utf-8?B?N0tTZGVGYXV0LzEycDdPZFR1c095Sk9SVWJPRk1HeDQ0UW9WS28vc055NHNH?= =?utf-8?B?cVk4UE40NUZSRUg0QzR5ZjArbU5hZkd6M0tPbzdvZytyQTJ2a01KVXhtSStl?= =?utf-8?B?UmVrUUtsM2FlQUJ5QWpsQk5iQ3Ura3g0cnpGR2xTRHZXZlZWamFDZVN6WjRs?= =?utf-8?B?QWV0VTZRb3hMeXNtb1VYNWwxR2pJcTRTcnJOczNVTk43QUZXVVgwY0VoZUFa?= =?utf-8?B?WWdZb0IzMm9PSGo3M2FnV3doK2twTUV5WXN5WWZOR1JvZ1hOVGlvQy9vRHdR?= =?utf-8?Q?VX9TcU/ytOC/Wsb31qecLNL2a8EQM9WG4QDIJlqWMhd6?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b80879f-3506-4b62-dfe0-08da910074e6 X-MS-Exchange-CrossTenant-AuthSource: MWHPR10MB1407.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2022 18:40:37.6161 (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: F8Lt0eFVKhl/cm7trhJbVoSQk8NZMxSLJKtQaMLpvwg4fcxV0ciUjSDvsRbWWj1Pepo7qQtnRzVlCALFG3k4/mcHi6mojqSRJw6s4Lzml2g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB6706 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-07_10,2022-09-07_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 adultscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2209070070 X-Proofpoint-GUID: AQcacARCTXiscOjVpBcxAjiLz2L6zflD X-Proofpoint-ORIG-GUID: AQcacARCTXiscOjVpBcxAjiLz2L6zflD X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 List-Id: On 9/6/22 07:49, Dodji Seketeli wrote: > Hello Guillermo, Hello Dodji, > Thanks for the patch. I have tested and it seems to pass regression > testing on my system. However, there are some things that I don't > understand so I have some questions below. The questions are just for > my own understanding. I don't have anything major against the patch, > obviously. > > [...] > > "Guillermo E. Martinez via Libabigail" a > écrit: > > > [...] > >> +/// Given a symbol name, lookup the corresponding CTF information in >> +/// the default dictionary (CTF archive member provided by the caller) >> +/// If the search is not success, the looks for the symbol name >> +/// in _all_ archive members. >> +/// >> +/// @param ctfa the CTF archive. >> +/// @param dict the default dictionary to looks for. >> +/// @param sym_name the symbol name. >> +/// @param corp the IR corpus. >> +/// >> +/// Note that if @ref sym_name is found in other than default dictionary >> +/// @ref ctf_dict will be updated and it must be explicate closed by its >> +/// caller. >> +/// >> +/// @return a valid CTF type id, if @ref sym_name was found, -1 otherwise. >> + >> +static ctf_id_t >> +lookup_symbol_in_ctf_archive(ctf_archive_t *ctfa, ctf_dict_t **ctf_dict, >> + const char *sym_name, corpus_sptr corp) >> +{ >> + int ctf_err; >> + ctf_dict_t *dict = *ctf_dict; >> + ctf_id_t ctf_type = ctf_lookup_variable(dict, sym_name); > > So, here, we begin by looking for a variable (using ctf_lookup_variable) > which ELF symbol is sym_name, is that correct? That's correct, `sym_name' is the symbol name. >> + >> + /* lookup CTF type for a given symbol in its default >> + dictionary */ >> + if (ctf_type == (ctf_id_t) -1 > > So, I guess the variable lookup failed, right? Correct, libctf `ctf_lookup_*' functions return CTF_ERR when fails, so I'm goinf to changed it for clarity. >> + && !(corp->get_origin() & corpus::LINUX_KERNEL_BINARY_ORIGIN)) > > Why this condition? Why only considering cases where we are not looking > at a Linux Kernel binary? I would think that we would want to consider > the case where the variable lookup failed, even in the case of a Linux > Kernel binary, wouldn't we? If not why? Maybe we should add a comment > to explain this. OK. The linker (ld) in the Kenel build mechanism uses: `--ctf-variables', then it emits the symbols type definitions using just the CTF Variable ection: $ objdump --ctf foo ... Labels: Data objects: Function objects: Variables: main -> 0x2: (kind 5) int (*) () (aligned at 0x8) main_func -> 0x4: (kind 5) void (*) () (aligned at 0x8) okkk -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4) Otherwise, it must be splitted across CTF Data, Function and Variable sections: $ objdump --ctf foo.o Data objects: okkk -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4) Function objects: main -> 0x2: (kind 5) int (*) () (aligned at 0x8) main_func -> 0x4: (kind 5) void (*) () (aligned at 0x8) Variables: okkk -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4) Since, vmlinux + *.ko, is *big* binary, I arranged the order of CTF lookup functions invoking at first: 'ctf_lookup_variable` and then, if it fails `ctf_lookup_by_symbol_name' by performance reasons. But I'm agree to remove `!(corp->get_origin() & corpus::LINUX_KERNEL_BINARY_ORIGIN))' changing the invocation order for those functions, the penalty performance was less than 10s building the ABI representation for the kernel, I consider it as acceptable. >> + ctf_type = ctf_lookup_by_symbol_name(dict, sym_name); > > So I am guessing that ctf_lookup_by_symbol_name looks up both variable > and function symbols from the same dictionary, is that correct? True. > Also, I don't understand why we don't just use ctf_lookup_by_symbol_name > rather than starting with ctf_lookup_variable first. Is it a > performance things? Exactly. Performance when we are processing a Linux tree directory. > Incidentally, I haven't found documentation for the lookup functions > other than by looking at the code, in say: > https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=libctf/ctf-lookup.c;hb=refs/heads/master. I'm afraid that the documentation is just in the source code. > If there is documentation for it somewhere else, maybe we can link that > place in the code here in a comment somewhere, or we can just point to > that link above. Both would be fine by me. > >> + >> + /* Not lucky, then, search in whole archive */ >> + if (ctf_type == (ctf_id_t) -1) >> + { >> + ctf_dict_t *fp; >> + ctf_next_t *i = NULL; >> + const char *arcname; >> + >> + while ((fp = ctf_archive_next(ctfa, &i, &arcname, 1, &ctf_err)) != NULL) >> + { >> + ctf_type = ctf_lookup_variable (fp, sym_name); >> + if (ctf_type == (ctf_id_t) -1 >> + && !(corp->get_origin() & corpus::LINUX_KERNEL_BINARY_ORIGIN)) > > The same questions as above. > >> + ctf_type = ctf_lookup_by_symbol_name(fp, sym_name); >> + >> + if (ctf_type != (ctf_id_t) -1) >> + { >> + *ctf_dict = fp; >> + break; >> + } >> + ctf_dict_close(fp); >> + } >> + } >> + >> + return ctf_type; >> +} >> + > > Cheers, > > [...] > > Really thanks for your comments!, I will prepare the v2 Kind regards, guillermo