From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by sourceware.org (Postfix) with ESMTPS id BCFF73858D33 for ; Thu, 16 Feb 2023 10:15:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BCFF73858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676542559; x=1708078559; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=EHgFRCREFmhoP8Q9ECaNjJv3YazYlikpPXi+JWe8jWA=; b=eUZlV7bHVfWvm6rEiDv2EthBcDIYsO5XNGKWMjWNCrcEM3PKn3s84Pzs tslAeHrCY91S2dU0xkVzM3Ns0dIMzkI5iM+7M23im6iS7ITrcOAgOpLmd 6S0n/Eg3J7NsrwV9OCLUoJOcPVBtYRKmUlfvQkrsN6O8UMdnRMmo3i3h7 PGj1yotgcWrzNrMe2Csc2Ar+bJrgw/sAzbBXtmywaMPVP1i3Ma3AyX2NT 5wD4QKmtL56rHW8xwyDGZhjVsAH8D5sUBCH8+Uoh8yb65yfgJe1o4wxIo bZRb1eS+6br9d9rcs8EBlvwe4is0zF0HXzHnUW7xGdIAu/8CXAoBarzVI A==; X-IronPort-AV: E=McAfee;i="6500,9779,10622"; a="333006005" X-IronPort-AV: E=Sophos;i="5.97,302,1669104000"; d="scan'208";a="333006005" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2023 02:15:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10622"; a="758876117" X-IronPort-AV: E=Sophos;i="5.97,302,1669104000"; d="scan'208";a="758876117" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by FMSMGA003.fm.intel.com with ESMTP; 16 Feb 2023 02:15:58 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Thu, 16 Feb 2023 02:15:57 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Thu, 16 Feb 2023 02:15:57 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.175) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Thu, 16 Feb 2023 02:15:57 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RB45tEZEFRb6Iv5kgGJfLNN22+UOtgM64ZZ40cZ8Y6e8BH5XtapX1rYIBxIeqiywKNnhd04Qp9Uf3ChrYuwP0hM4Oy44bx28OPcsq6FFXxLrWrGbLPRY+XZ9SpGsql8ra/1S+CYXteSFN3yDqnEpwmMrTh3D8OCUbpfXi2RkeNfbs2Eaek89tKW0XrexcsA9yhoz2cKm/Zkx16lEEMr6EUgKzF3sPtnnv1ylRLJQKpsDGzE7c1STfoni62Ms/hcLU7oPWMJEr17O3pz5W6aNTDkAroSXyCOZcOXtOkgQgqB1FoEzvX0zOOfFvxA0o24+NfM2JFj9mG08VrEIhjBjNg== 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=hOiF0Z2e7AtqvdFgTkVOXwX/RrcWZoOSCypH8WuI2vY=; b=BaHjHeclTb5ZXkpBdrDRB8qR+kQU+Y9yeVFQfEJqV6OOtxXly5C8/ynLXDC4OPAHboRxdwZUMzxTCUw3HvevaXepWLvm7b+r1rTfFPbXo7G8a5LxfkpDc6w4hIigQ32vB+PKWFv9s+zAahxGAx0gfnpY8bzG57qxFft6+ykMc41hHb/DKg+uS0NaaGokEKGqzkge9km44PYlTUFYAnCvRBqiS2X55Rm4AptDqFohSYtA8YxTCEwRIui1VEBPF7AKvcGm2edEkvRxPX3qiNrzLzhc0gtD0Wt9iv9I1JSBZuA8P2q9t2uONxLL5CxfTJNGnaVtKoUFZZ6u5PfmY6wDiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM4PR11MB7303.namprd11.prod.outlook.com (2603:10b6:8:108::21) by CY5PR11MB6089.namprd11.prod.outlook.com (2603:10b6:930:2f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.26; Thu, 16 Feb 2023 10:15:56 +0000 Received: from DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::dec6:d57d:f767:c5f2]) by DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::dec6:d57d:f767:c5f2%4]) with mapi id 15.20.6111.013; Thu, 16 Feb 2023 10:15:55 +0000 From: "Aktemur, Tankut Baris" To: Andrew Burgess , "gdb-patches@sourceware.org" Subject: RE: [PATCHv3 03/13] gdb: include breakpoint number in testing condition error message Thread-Topic: [PATCHv3 03/13] gdb: include breakpoint number in testing condition error message Thread-Index: AQHZNZzIjQV9zn0IxUiPUmWTYxQCT67RcyzQ Date: Thu, 16 Feb 2023 10:15:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR11MB7303:EE_|CY5PR11MB6089:EE_ x-ms-office365-filtering-correlation-id: 06bd5acd-755d-4625-232c-08db1006ca5c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +iJg7iFeqmH2k+X1JWH6fnmixfHlWokhwAeEDQoQiORsRMPj8Tq+665dKi0zh2SmIL3ALbnJLXOcBI5YadIn/M1/8jLvLO3jwOcxSUtabL3Ow4P0XAC8N0T8l17ItHjc0dJGBGoC3oQ9rGexPQtCtQH9lGir+3VTlIr8AYeJtFYLTxIJH59/ZVBBUKO2zLih17rmdej3DGJ5MQsYz5Rt5G3TW+4GT80w5POz79hOfcxRcnHQGfJJsMLbCOGVJOZAKlcclbjf/4yYNRT08q/G8ZFKvbONdBNsT1FJVb4vqz85RUbg+hQ6uZuB5Pjw4QzoNgVaC/y4EK38INFp6RZb/mDbDawNgbSni4AiP9uW7mP1oMqbIfinfhBQhRaj4rXuOuEQap9kRA8jQ6b0NkPhNplkmompwUHZ8EExc11Uwn75Ie45QmwHuVY7y1Digf6EgznH2PJXuv/iBUc/uETk5LtuuIJYL3TB3QpL3gRV+hQKiTFDB+kdKWpkpdR4IUb+zB5p+je+Ssmr7hEmNGEJDOxQmtFlRxbzU8Eb/fk231ASE5l3bfAvfzfYn0YMleGkbJoTQ8+MBf0wsKAE0FCKvildRH065lQCahy0d16Yse70UAq2jyIrJtt7/4rmwwTi0+hFCjLhSdwFpdJGVN2yviVlTm15owoUlrgliJIOTc//NLg2mfcw9g7OpGB1sZSVoPjJyjf37yRkWzIeRXpSNQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB7303.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(346002)(39860400002)(366004)(376002)(136003)(396003)(451199018)(2906002)(82960400001)(122000001)(38100700002)(38070700005)(316002)(66446008)(8676002)(52536014)(41300700001)(64756008)(8936002)(15650500001)(76116006)(66556008)(5660300002)(66946007)(478600001)(66476007)(86362001)(53546011)(26005)(9686003)(110136005)(83380400001)(7696005)(71200400001)(55016003)(33656002)(6506007)(186003)(2004002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?8uXinYn/jqIerQdI3PFO/iBaG+OZsMJbI0mWFCRGwU1UxdEReLQscoXdCeiU?= =?us-ascii?Q?QqJvOE/evYITmKgGsQfq8y0+HsWdmER2zR+I1K+tsUgVmFlITus3LEINKBCL?= =?us-ascii?Q?aQaX1IVpnpU7kx1+sH1q/T9PY44t6M3AyXryJ0uo4D+hlwGE/o6Kwn/Xl+Z3?= =?us-ascii?Q?Fj5/HOhJnVELLjsq9pfUh+zCSnuqHsb8TFWo9QqlqeUUWZT2vLW1amEVtR+Y?= =?us-ascii?Q?C0VigKAYLA6TzyLSTIaptkC918K8woinui9pdYMizG6GVKx1V+aZX56PTNhs?= =?us-ascii?Q?Uwk3LNaV2RmnghV0QB4jZNgIhHCOoUTJYrS9mdus/SAGAll6D96JOICjkhqy?= =?us-ascii?Q?Xu2Oel3NLpjwmleOO3CXgvdKVnZNf+nRbBv3Y0b0lrgQHtlVsXC2C0koYJco?= =?us-ascii?Q?3MeXYsxV0dCBIovQ+xsY9tWkcT1SalDzNwHSlWP9+K6hqxMJ62LiLmGalpBC?= =?us-ascii?Q?iJ0DGeLIC7BOHZjmGbyqVIWY2ytGaPdHyAoUrBLW226ZmNlZqxammLXycC2V?= =?us-ascii?Q?tQ+wBm4ma2K2x4ma/x7RCEOtWUxreZt+Q9z7C6MKUZbFTbrEeWU6xfV3JJCq?= =?us-ascii?Q?EV2JHexsfzC+nFtHdudb75rsf1XXk5FGY0NQxFsCNZS3tyC80paMWV61dPcm?= =?us-ascii?Q?01l8AUu8Y26VxqqcTKMbjYtmzVVZkvHes3zXU1fFi5iTuejc4rbpisL9vkFK?= =?us-ascii?Q?jY1tLagEPMyTxrH2HdstlUo2u5iz1hR/T2QcFn4N4SGw/+YePOjiDNn/ZcYu?= =?us-ascii?Q?RpSANbxvmb3VWFq0KvlllOfOYVo0Ye5pZPtIWq8ThihOYJD5Sx27JoyXpvZ8?= =?us-ascii?Q?N1kJsx+jfr1JhpIO4gIMjKa3HuTSZA7JRGGXDq+T1LDb/iF1fsnCvDzNurDb?= =?us-ascii?Q?u1Bi4EzslXD5jb7YkB9wJN1BcEvgkPTS2vgFbD4BmDWVVBDjlQOK3THCHKsh?= =?us-ascii?Q?T/Iz9Z2OAUm+KQwqVqCIaeAfbMgndyypY+6F1gjRX8vx8QqN1Bvtf/5yHHX5?= =?us-ascii?Q?B85hZYYTpHL+l4dIT5D6w8CPeDETiEoUeGj/VdvMhbEoszuUbsTCQOZN4v31?= =?us-ascii?Q?S339RNwQQX4ibkbrbucbJjN/Vycp1gR4p3UsECmVKUQpjE9NmOtwqu0AmnYk?= =?us-ascii?Q?lgfdQOi5SBdGCSkQdSLFT9gjYuuW7dLWZE687bolTnoXDCjdexE4E2Gb40o2?= =?us-ascii?Q?1XQUXmWHYPkPz+00UgsP5wlyt3nJl7rBNHv58rOFl/6Tw2xBbU+0rwWW7ChJ?= =?us-ascii?Q?k7OhFRzFc6qcPZbn7H3V9AuO/nuANY6ARMSF91knuO5uX8bgkRV1INnVIC4j?= =?us-ascii?Q?5g++bVQIh8MM2RNTt57bTSPeRNPVVMd6dCbxLPlEdhpQsb8qS7kIUqMSOYm6?= =?us-ascii?Q?XYLdbQx52/Pn6wMTfRKgDP6vSjhllFPSIsj3h0PVpK/AuEb6b78yhnFvpdQE?= =?us-ascii?Q?Mh04iSD3whI6129BD4O3BwJy5wsYr/xVVSzfvrTOjeuo5pArCAOo3OrTRQEC?= =?us-ascii?Q?d/nequLLvf9pOWpmyQIL+Bz69nVE/oJMmm6wUoQk4ik41KjuVPQ6R/oRubG4?= =?us-ascii?Q?gIioYGINITzg5T2Iqg65G2DGjzsASckM7WKzJu6FuNAY41egQOwOxwbvRlBY?= =?us-ascii?Q?Hw=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB7303.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06bd5acd-755d-4625-232c-08db1006ca5c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2023 10:15:55.3472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4O3m1hGLPN9OPaiJvU1k+2SFTJE9sDSuY9KP4DqsyQWiQyBs1EiXXBcPu4z+jPt6FUONXiQ3IBnPVwsrpdbueWMcD/77Y3T43cfgXKmdx5w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6089 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP 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 Tuesday, January 31, 2023 6:27 PM, Andrew Burgess wrote: > When GDB fails to test the condition of a conditional breakpoint, for > whatever reason, the error message looks like this: > = > (gdb) break foo if (*(int *) 0) =3D=3D 1 > Breakpoint 1 at 0x40111e: file bpcond.c, line 11. > (gdb) r > Starting program: /tmp/bpcond > Error in testing breakpoint condition: > Cannot access memory at address 0x0 > = > Breakpoint 1, foo () at bpcond.c:11 > 11 int a =3D 32; > (gdb) > = > The line I'm interested in for this commit is this one: > = > Error in testing breakpoint condition: > = > In the case above we can figure out that the problematic breakpoint > was #1 because in the final line of the message GDB reports the stop a > breakpoint #1. > = > However, in the next few patches I plan to change this. In some cases > I don't think it makes sense for GDB to report the stop as being at > breakpoint #1, consider this case: > = > (gdb) list some_func > 1 int > 2 some_func () > 3 { > 4 int *p =3D 0; > 5 return *p; > 6 } > 7 > 8 void > 9 foo () > 10 { > (gdb) break foo if (some_func ()) > Breakpoint 1 at 0x40111e: file bpcond.c, line 11. > (gdb) r > Starting program: /tmp/bpcond > = > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000401116 in some_func () at bpcond.c:5 > 5 return *p; > Error in testing breakpoint condition: > The program being debugged was signaled while in a function called from= GDB. > GDB remains in the frame where the signal was received. > To change this behavior use "set unwindonsignal on". > Evaluation of the expression containing the function > (some_func) will be abandoned. > When the function is done executing, GDB will silently stop. > = > Program received signal SIGSEGV, Segmentation fault. > = > Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 > 5 return *p; > (gdb) > = > Notice that, the final lines of output report the stop as being at > breakpoint #1, even though we are actually located within some_func. > = > I find this behaviour confusing, and propose that this should be > changed. However, if I make that change then every reference to > breakpoint #1 will be lost from the error message. > = > So, in this commit, in preparation for the later commits, I propose to > change the 'Error in testing breakpoint condition:' line to this: > = > Error in testing condition for breakpoint NUMBER: > = > where NUMBER will be filled in as appropriate. Here's the first > example with the updated error: > = > (gdb) break foo if (*(int *) 0) =3D=3D 0 > Breakpoint 1 at 0x40111e: file bpcond.c, line 11. > (gdb) r > Starting program: /tmp/bpcond > Error in testing condition for breakpoint 1: > Cannot access memory at address 0x0 > = > Breakpoint 1, foo () at bpcond.c:11 > 11 int a =3D 32; > (gdb) > = > The breakpoint number does now appear twice in the output, but I don't > see that as a negative. > = > This commit just changes the one line of the error, and updates the > few tests that either included the old error in comments, or actually > checked for the error in the expected output. > = > As the only test that checked the line I modified is a Python test, > I've added a new test that doesn't rely on Python that checks the > error message in detail. > = > While working on the new test, I spotted that it would fail when run > with native-gdbserver and native-extended-gdbserver target boards. > This turns out to be due to a gdbserver bug. To avoid cluttering this > commit I've added a work around to the new test script so that the > test passes for the remote boards, in the next few commits I will fix > gdbserver, and update the test script to remove the work around. > --- > gdb/breakpoint.c | 3 +- > gdb/testsuite/gdb.base/bp-cond-failure.c | 30 +++++ > gdb/testsuite/gdb.base/bp-cond-failure.exp | 114 ++++++++++++++++++ > .../gdb.base/catch-signal-siginfo-cond.exp | 2 +- > gdb/testsuite/gdb.base/gnu-ifunc.exp | 2 +- > .../gdb.python/py-finish-breakpoint.exp | 2 +- > 6 files changed, 149 insertions(+), 4 deletions(-) > create mode 100644 gdb/testsuite/gdb.base/bp-cond-failure.c > create mode 100644 gdb/testsuite/gdb.base/bp-cond-failure.exp > = > diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c > index 00cc2ab401c..eecaeefed3e 100644 > --- a/gdb/breakpoint.c > +++ b/gdb/breakpoint.c > @@ -5542,7 +5542,8 @@ bpstat_check_breakpoint_conditions (bpstat *bs, thr= ead_info *thread) > catch (const gdb_exception &ex) > { > exception_fprintf (gdb_stderr, ex, > - "Error in testing breakpoint condition:\n"); > + "Error in testing condition for breakpoint %d:\n", > + b->number); > } > } > else > diff --git a/gdb/testsuite/gdb.base/bp-cond-failure.c b/gdb/testsuite/gdb= .base/bp-cond- > failure.c > new file mode 100644 > index 00000000000..2a9974b47ce > --- /dev/null > +++ b/gdb/testsuite/gdb.base/bp-cond-failure.c > @@ -0,0 +1,30 @@ > +/* Copyright 2022-2023 Free Software Foundation, Inc. > + > + This file is part of GDB. > + > + This program is free software; you can redistribute it and/or modify > + it under the terms of the GNU General Public License as published by > + the Free Software Foundation; either version 3 of the License, or > + (at your option) any later version. > + > + This program is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + GNU General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program. If not, see .= */ > + > +int > +foo () > +{ > + return 0; /* Breakpoint here. */ > +} > + > +int > +main () > +{ > + int res =3D foo (); > + > + return res; > +} > diff --git a/gdb/testsuite/gdb.base/bp-cond-failure.exp b/gdb/testsuite/g= db.base/bp-cond- > failure.exp > new file mode 100644 > index 00000000000..9388b8cf582 > --- /dev/null > +++ b/gdb/testsuite/gdb.base/bp-cond-failure.exp > @@ -0,0 +1,114 @@ > +# Copyright 2022-2023 Free Software Foundation, Inc. > + > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see . > + > +# Check the format of the error message given when a breakpoint > +# condition fails. > +# > +# In this case the breakpoint condition does not make use of inferior > +# function calls, instead, the expression used for the breakpoint > +# condition will throw an error when evaluated. > +# > +# We check that the correct breakpoint number appears in the error > +# message, and that the error is reported at the correct source > +# location. > + > +standard_testfile > + > +if { [prepare_for_testing "failed to prepare" ${binfile} "${srcfile}" \ > + {debug}] =3D=3D -1 } { > + return > +} > + > +# Run to main so that we connect to the target if using 'target > +# remote'. This means that the is_address_zero_readable, and the > +# 'show breakpoint condition-evaluation' checks below will be > +# performed with the remote connection in place. > +if { ![runto_main] } { > + fail "run to main" This fail can be removed. > + return -1 > +} > + > +# This test relies on reading address zero triggering a SIGSEGV. > +if { [is_address_zero_readable] } { > + return > +} > + > +# Where the breakpoint will be placed. > +set bp_line [gdb_get_line_number "Breakpoint here"] > + > +proc run_test { cond_eval } { > + clean_restart ${::binfile} > + > + if { ![runto_main] } { > + fail "run to main" This one, too. Thanks -Baris Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928