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 B8EED385842E for ; Thu, 25 Nov 2021 21:03:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B8EED385842E Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1APJhpHK028905; Thu, 25 Nov 2021 21:03:23 GMT Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by mx0b-00069f02.pphosted.com with ESMTP id 3chj7g8tp1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Nov 2021 21:03:23 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 1APL1RYG095828; Thu, 25 Nov 2021 21:03:22 GMT Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2169.outbound.protection.outlook.com [104.47.56.169]) by aserp3020.oracle.com with ESMTP id 3ceru9291m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Nov 2021 21:03:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cX0Q2oToqRHyDbRBzVHTS8iWQHdCim/NVI61SZnyLuuEIme3m3Zhb3TBq9N5TrbYSgJ6vWR6DedLDtRyu/4o7ehkW90AnA6xjmirpeL7VfhGPxLovJusBuyry1DVcpcvOaUErHncmCn4Gg1/60mVpKfHUVaQBm8DOz7c7A032Oihc1oqP57oBcT3adJQJYOZ5ctiYCDpaGlHGeVm711C+XEEznDn8r/OV6Lt5o30IagNukZSlGLhGbC0LaRq4/cUF7lnfJXE/57x4HnPE3uWSgnNaUM13o2OYVEFluzxgkD9LOwHF1+PNTcfAUUVxCH5pc6bZVBzn3qWhANefAWX6w== 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=7lDh+AAbHkEZzBnZ9O1f+gYY5CN3HA6M6csehUvCFVU=; b=Ad29cTnmE0n2SHLQBFPXvMOYga0NHqyhfUAtWJIZZHrKNXnp9LGfFQyJizYLh7GdRWM30EmO3Y+uPCN6yKyze7gCLYCDIj7BtH/FRiAIByxfYmuEO7EU6KORoefN81DEV42ulxKuQKdWY+i5iMbFRECOqc4Ty8his4tmfMG50rtt714dHuKOzNskbz8IHKM+5euoW4gLDxsnmerM3z6PZHmtIL1VM18rY6BOCGtZJ6LwDjLLdEHyeeb4vnB07fiubFhGW5S24smJmdz+ytPijSyuDIz+1xpiwLoB7XbPfr5TmroNXRCIXgbVqXSwdE07uJFZH8ud9c8Xg2+0te6fHQ== 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 BL0PR10MB2852.namprd10.prod.outlook.com (2603:10b6:208:76::22) by MN2PR10MB4096.namprd10.prod.outlook.com (2603:10b6:208:115::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.13; Thu, 25 Nov 2021 21:03:20 +0000 Received: from BL0PR10MB2852.namprd10.prod.outlook.com ([fe80::6927:5e6b:31ff:14bd]) by BL0PR10MB2852.namprd10.prod.outlook.com ([fe80::6927:5e6b:31ff:14bd%3]) with mapi id 15.20.4734.022; Thu, 25 Nov 2021 21:03:20 +0000 From: Guillermo Martinez To: Guillermo Martinez via Libabigail , Dodji Seketeli Subject: Re: [PATCH v2] Add regression tests for ctf reading Thread-Topic: [PATCH v2] Add regression tests for ctf reading Thread-Index: AQHX3+i0sxPxY2A1xE+yYqgUFCa9sqwRQ2O7gAAz3YCAApqyMoAArfoA Date: Thu, 25 Nov 2021 21:03:19 +0000 Message-ID: <4076345.HvgH2z2rxB@sali> References: <20211118041625.622972-1-guillermo.e.martinez@oracle.com> <1748826.RoRjW6BIRr@sali> <87a6hstt5u.fsf@seketeli.org> In-Reply-To: <87a6hstt5u.fsf@seketeli.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 67e6c46e-8906-41b2-7dc6-08d9b057029a x-ms-traffictypediagnostic: MN2PR10MB4096: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E+VKOLadvbQlKLZx6ztUkKE5ajP9JGoLEgZJpMDpqOctqx8hOVbAEqaIqsDHAsQW3Iyqub6d7kzo1vkofzSdm5tlLA3VnL06A8ZRcjj8os8t1rslIJNDIbTeZsFELCOeHFep+S3yIo9Lzk2OGPMMjNy0aKFcdfK0R6WNeNEYY87Zh2YY5sEOA7zAvxms0ODvoW0Pzh5uGxffrgB4sT/ibhmYuIMf+Vo4o73hXScMPjwwDgr6hxs6iDXdKCySIN3EnQXCLdfINZHQUWI4HIpondzwYp3MzsupOwJwEECJj1FBAMIJJe2b66twrkRRkiJO5J2/fy/b23SUN6CMzcm4w6bpRDPoO8zp9dwxxFGPRN1f8tR0u18mkbptloCe0uoGIjAKw61BaOVLbdiSmPjzFwQlM/et+B06wZogbVDsD3kEP0vaTThkt8XJFVHQFBExKKG45BOSK8XQsYUF0AYotPC632CSYR5UeJVUKUxZoRjwnOoWbZX9/PHC5GyuJmBbl3h9TdN7GEkCn00J3pnStfjBg1DrnNUg9SpekRTD/GYfiCxITnX0No+1bWkSOpBPCQFDjSlLkTP1RC3qVdo9Wdfaa2KnPIkMBSoqiUQA0DylzHp63a3ihocxj26dA2GtpGbB2NYRiIImVl2T+3lDjIE48crMGLosXxb7iAbsZPzQEL9CivZsfMKnTLehmkc88zflTdUXBGErwZkfr7mIh3oHE8T6+fX3fhiPai6/m+mf6aL9CbancVEaAshkE5NtsQz21w7WEu5D0Ljo7j3b3j4VUeVCwNvslZEhgXBGGWaqg+PVsau5oOqm0xI20NT8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR10MB2852.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(7916004)(366004)(38070700005)(4326008)(8936002)(83380400001)(2906002)(5660300002)(86362001)(8676002)(66556008)(110136005)(66446008)(53546011)(71200400001)(9686003)(316002)(966005)(26005)(6506007)(6512007)(107886003)(186003)(508600001)(33716001)(66946007)(76116006)(38100700002)(91956017)(66574015)(122000001)(66476007)(64756008)(6486002)(39026012); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?d3BKoO4Z91toq69BzhwAAzUpKr5KfN6h1X8boJ5lFHBerGYvzCIR71jFjS?= =?iso-8859-1?Q?7NiqXOxnJOdJSDSFXSiap3zbNO64mavav+7NWwHrKpVW3Kq68tFrOD7Hae?= =?iso-8859-1?Q?+JVDl5GagsuiPL6e604ICq5qiEpgTWQCEOO0FLm+fdo0Ncy4Ce4Hp4Wq+/?= =?iso-8859-1?Q?/Nhd6hPn+GM8eeyaWWGByzH3Qx4589V3pweqteUml6pqaBNonmVePkEu48?= =?iso-8859-1?Q?XGXFcMA2ZZyGOq4JKnHYj8DEx7ttEi51gUMPm7hkyXexgJn1hiUlSph0Hk?= =?iso-8859-1?Q?1dg+j8QevM6gxYFJFhXFQK0sdCAKVXHaTyUHS/HMERFxnzEshzTUI2HxLF?= =?iso-8859-1?Q?71HKMcziA+wVurOsZmR4N1S9vXHm72UUQegn6ZTOzbiyqrHcFKq+4zy6V5?= =?iso-8859-1?Q?kuyGt0s8oAGV9zPkA5CBnBFg81SbdP7BERhwkhMWc933EPupAS7meshLwH?= =?iso-8859-1?Q?aHgQDc9uMaff66b88/U7tlYtSYTq20sfPpeqwf/vJFIiSCx4NZTQlgEyqk?= =?iso-8859-1?Q?r1iVKzIHbcXtb1CgPTBPugB7t9LPx+OtywN947sjyLdwuAzFKKw2UanIoU?= =?iso-8859-1?Q?jVWbdwC1uweuXFUsrMQDym6h/UAzhLxba8lkozCdBJDSnPojS1kvB3fZiF?= =?iso-8859-1?Q?q/mpKdRAoBAuPVmPMLNRP0noay0k3IAEDp5xY2I3hqLLZiMtJ9m0xBdPUb?= =?iso-8859-1?Q?XXo3Kbtt9vQDgzMznVmxVacD2s6hLEPKbSrSkldQB5RLSuuX1rL5EK1Hcf?= =?iso-8859-1?Q?TAoHbm7CnE0yPrY1ObVW8MlJXSQyd6ixzXJxtS3aBRsrdlD5klWaxjdM3N?= =?iso-8859-1?Q?TAIo0f6Tp+cv8VxzriVs+Pep/Z7sPg4YdhX9uSTyvrvNJfZj70esJOEhdj?= =?iso-8859-1?Q?ObeRC/8u8NaHfuoQmKIh5HYNW8wKfYCTp5GIWI1jjj3ago0FCAK/VsuLmt?= =?iso-8859-1?Q?T62EJbQ5GG2CS/ipKqG3I2PR6FnItYgXRVoHquaIsYzlV4++dQ9CUEqL1w?= =?iso-8859-1?Q?llx/pzk3p8E0dTjjB5yxaY6V9InAOeFPLj34MaXZByVteHFGXraoCuU5Bk?= =?iso-8859-1?Q?lbg/4Q6c+JqEwAQpDBx1qZHW/IxVRuWQbtpRHsT8amrY9DlUMujMz0f2HH?= =?iso-8859-1?Q?KIYcgOF+ZIxPF5YkdXOtbXD0jdZ1IIf8VTtoO5FztqZFwl1Vcjdln8cWpI?= =?iso-8859-1?Q?bhxaZ9LSPqkM6drKlgB/ZaIEjCSLQPIufVn6q5plaMDOlmMYB/S7ezAdBq?= =?iso-8859-1?Q?0eWiCddjLb190SFurTbW0U4q1d8n3Ca7W5qz+GgT6BGZpykt81t2SKLgx2?= =?iso-8859-1?Q?P9J2jgg7Pcyp3pBBQgGGhChHiqtoOft4J1tY3CapDiWXJ7C+TKZdwCFTqq?= =?iso-8859-1?Q?0IjF9LLRVsIsh2xoLH7BJvAu4Am3djX3fyCNVMHQwPxbG15B6zHI+aWimN?= =?iso-8859-1?Q?zVPra5E/ZxqSUG0PM16u6OZmiG4Dqen3TDcKcmctQxA0WMsXaczQ8AIhZv?= =?iso-8859-1?Q?hKoNBbuzFcGw3GyDAmpuyZmHDcgN9RrTrfBB+RIXksRYpJCgeJToPRP/h9?= =?iso-8859-1?Q?9GOdR/xkxDKV+GWvyPuHxAQLPATCi+CvCH+4l4szFbd1QFspHUP9e7RToQ?= =?iso-8859-1?Q?e/HJCZgn6nPKusv7hQqsM8GP3RVx8pXYq+4nF3nXDllpZizwfVqnHyv/cj?= =?iso-8859-1?Q?d8oJAZ/cGR9HCv8JUx75iOQ4bspxgi4pBD+HgT7AadyftJTTgs5aB0b+bN?= =?iso-8859-1?Q?YAWBNrcdpQGLtGvQ+WDqPJCZA=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C74853861C8794192E7C76D2D0596C8@namprd10.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR10MB2852.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 67e6c46e-8906-41b2-7dc6-08d9b057029a X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2021 21:03:20.0998 (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: sIHxuAr9wbIML0i9yHwztIMVusRNlNApwaSx/OWLk+wk450EMljesFXta2g4ZD8lQTDaOQLAfMZllMtC1AYZCNnVrb8KTYkH1IXPeXKnyxk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB4096 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10179 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111250117 X-Proofpoint-ORIG-GUID: wDPjYJJikHtMUz7I1syffCHiYvtomhgY X-Proofpoint-GUID: wDPjYJJikHtMUz7I1syffCHiYvtomhgY 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_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 25 Nov 2021 21:03:30 -0000 On Thursday, November 25, 2021 4:40:29 AM CST Dodji Seketeli wrote:=0A= > Guillermo Martinez via Libabigail a =E9crit:= =0A= > =0A= > [...]=0A= > =0A= > > On Tuesday, November 23, 2021 9:48:35 AM CST Jose E. Marchesi wrote:=0A= > >=0A= > > Hello Jose/everybody=0A= > >=0A= > > Thanks for your comments!, answers below:=0A= > >=0A= > > The following items summarise steps currently implemented in=0A= > > the testsuite for DWARF and CTF readers:=0A= > >=0A= > > 1) Create corpus using the ELF input file, e.g:=0A= > > *src*/libabigail/tests/data/test-read-ctf/test0=0A= > > - In this step the SUTs are: *the front-end and readers*.=0A= > >=0A= > > 2) Serialize the corpus object to XML ABI description in output=0A= > > directory:=0A= > > *build*/libabigail_x86_64/tests/output/test-read-ctf/test0.abi=0A= > > - SUT: *writter* using write_corpus function=0A= > =0A= > Right.=0A= > =0A= > > (it doesn't use libxml (IMHO something to change if we want to use in= =0A= > > the future properties, name space, etc).=0A= > =0A= > I am not sure about this, but hey, the future will tell :-)=0A= > =0A= > >=0A= > > 3) Spawn *abidw* tool with ELF input file using --abidiff argument, e.g= :=0A= > > abidw --abidiff --ctf *src*/libabigail/tests/data/test-read-ctf/t= est0=0A= > >=0A= > > Internally abiw works as follow:=0A= > > =0A= > > 3.1) Create corpus from ELF input file, e.g:=0A= > > *src*/libabigail/tests/data/test-read-ctf/test0=0A= > > - In this step SUTs: *DWARF/CTF frond-end readers*=0A= > >=0A= > > 3.2) Serialize the (*first*) corpus object to XML ABI description in= =0A= > > *temp* directory:=0A= > > /tmp/libbigail-xyz=0A= > > - SUTs: ABI writter,=0A= > >=0A= > > 3.3) Build a (*second*) corpus from this temporary file (*same file!= *):=0A= > > - SUTs: *XML reader*.=0A= > >=0A= > > 3.4) Compute the corpus differences=0A= > > compute_diff(corp, corp2 ..)=0A= > > - SUTs: *comparison algorithm* (diff_context/corpus diff)=0A= > >=0A= > > if there are differences return 1 otherwise return 0.=0A= > >=0A= > =0A= > Right.=0A= > =0A= > > 4) The return value is read by test-read-ctf and if it's 1 test=0A= > > is marked as *FAILED*=0A= > >=0A= > > 5) Use a external *diff command* to compare the XML abi input file with= =0A= > > the file outputted in the step 2. The return code of the diff comma= nd=0A= > > is used to mark the test as SUCCESS or FAILED=0A= > >=0A= > > So, the abidw doesn't use the expected XML file used in the testsuite, = so=0A= > > if there are changes on the input ELF or in the libabigail subsystems (= readers,=0A= > > writer, corpus, etc) we could get false negatives, because it is workin= g with=0A= > > itself result as an incoming file, instead of use an expected file.=0A= > =0A= > Actually, this won't be a false negative. It's a true negative. because= =0A= > what we want to see with abidw --abidiff is that the abixml file that is= =0A= > emitted has the same *ABI* as the incoming ELF file. In other words, we= =0A= > want to see if the DWARF/CTF, the in-memory IR, and the abixml are all=0A= > coherent, so to speak. The exact output details of the XML itself=0A= > (things like spaces or order of type definitions etc) don't matter to us= =0A= > at that point. We want those insignificant details of the abixml format= =0A= > to be able to fluctuate without having the fundamentals of ABI=0A= > compatibility in general to be impacted.=0A= hmm, in order to probe my assumption of the use of abidw --abidiff in test-= read-*=0A= to protect against false negatives I've commented in src/abg-dwarf-reader.c= c=0A= the call to ctxt.load_elf_properties, simulating a broken feature(no elf-ne= eded node=0A= in abixml) in dwarf_reader::read_corpus_from_elf so the /tmp/abixml hasn't = =0A= elf-needed node:=0A= =0A= =0A= =0A= =0A= ....=0A= =0A= after that, as we already know this /tmp/abixml is used to built the second= corpus used=0A= by compute_diff function, and as you can guess: no differences will be foun= d. So regressions could=0A= not be detected, because we don't used the expected abixml file: test0.abi,= is there where the elf-needed=0A= node was written for example: in a previous version of libabigail.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= > However, regardless of abidw --abidiff (which cares about stability of=0A= > the ABI representation across DWARF/CTF, in-memory IR and abixml), the=0A= > test-read-dwarf.cc harness also wants to detect minutes changes to the=0A= > abixml that is emitted by abidw. =0A= hmm, /tmp/abixml is not used by test-read-dwarf.cc.=0A= > This is so that developers are forced=0A= > to inspect abixml changes that are due to source code modification of=0A= > libabigail before submitting their changes.=0A= Ok, agree.=0A= > This is why we use "diff" to compare the emitted abixml against the=0A= > expected/reference one If the emitted one is different because of a new= =0A= > source code change, but the ABI is stable, we'll just accept that new=0A= > change and promote the new abidw output as being the new=0A= > reference/expected output.=0A= Yes, but those differences found by "diff" could be there and it doesn't me= an=0A= changes in the libabigail source code nor differences between the abixml=0A= file generated from the ELF input object and the expected abixml file. =0A= I found weird behaviour running CTF testsuite (test-PR26568-1-ctf.o.abi):= =0A= =0A= https://sourceware.org/pipermail/libabigail/2021q4/003893.html=0A= =0A= > > I think that we should use the ABI XML reader from the expected file (e= .g:=0A= > > tests/data/test-read-ctf/test0.abi) to build the corpus to be compared= =0A= > > with the corpus built with ELF input file (e.g: tests/data/test-read-ct= f/test0)=0A= > > and in this way replace the external abidw and diff command calls,=0A= > =0A= > Heh. This is exactly what abidw --abidiff does. And we want to use=0A= > abidw too to, so that the *tool* is tested too.=0A= > this also=0A= > =0A= > But as I have explained above, we also want to use 'diff' for a=0A= > different level of testing.=0A= > =0A= > [...]=0A= > =0A= > > helps to avoid false positives when XML ABIs files has the same nodes b= ut not=0A= > > in the same order.=0A= > =0A= > =0A= > [...]=0A= > =0A= > =0A= > On Tuesday, November 23, 2021 9:48:35 AM CST Jose E. Marchesi wrote=0A= > =0A= > >> 2) I am surprised by the fact the CTF reader seems to be working as go= od=0A= > >> as the DWARF reader re. the testsuite.=0A= > =0A= > Well, we don't know that ;-)=0A= > =0A= > To know that, it's needed to *inspect* the result of abidw --ctf on the= =0A= > binaries and compare it to what we see in the source code of the binary.= =0A= This is exactly what I did :-) and also I execute abidw using same source= =0A= code but compiled with -g option and comparing common information=0A= in the nodes: elf-symbol, *-decl, function-type, data-member, etc. and=0A= common nodes properties: name, path, size*, id, etc. in ~19 test sent in=0A= patch v2 they looks good! (those files now are the expected result for=0A= CTF testsuite). =0A= =0A= The pending work (in which I'm doing progress) is translate the valid CTF= =0A= testcases from tests/data/test-read-dwarf/*cc files to c files and add to= =0A= testusite, also I'm planning to extract other test from the CTF specs:=0A= http://www.esperi.org.uk/~oranix/ctf/ctf-spec.pdf=0A= =0A= > We can also introduce new ctf binaries for abidiff-based tests and=0A= > compare their output to their DWARF counter part.=0A= Ok,=0A= > There are going to be differences, I am quite sure of that. But at=0A= > least we'll see what they are. I am not afraid, though. I think the=0A= > CTF support is super cleanly done. If there are issues, we'll tackle=0A= > them.=0A= > =0A= > This testing work is a critical part of that work. Many thanks to=0A= > Guillermo for handling it!=0A= No, thanks to you Dodji for your comments, they are very useful to follow t= he=0A= right direction in the CTF test harness! :-). =0A= > [...]=0A= > =0A= > Cheers,=0A= =0A= Guillermo =0A=