From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81908 invoked by alias); 2 Aug 2016 09:15:29 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 81896 invoked by uid 89); 2 Aug 2016 09:15:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_50,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=gdbsourcewareorg, sk:gdbsou, U*gdb, gdb@sourceware.org X-HELO: EUR02-VE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr20061.outbound.protection.outlook.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (40.107.2.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 02 Aug 2016 09:15:15 +0000 Received: from VI1PR0401MB2671.eurprd04.prod.outlook.com (10.168.66.19) by VI1PR0401MB2669.eurprd04.prod.outlook.com (10.168.66.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 2 Aug 2016 09:15:07 +0000 Received: from VI1PR0401MB2671.eurprd04.prod.outlook.com ([10.168.66.19]) by VI1PR0401MB2671.eurprd04.prod.outlook.com ([10.168.66.19]) with mapi id 15.01.0557.009; Tue, 2 Aug 2016 09:15:07 +0000 From: Alexandru-Adrian Oltean To: Yao Qi CC: "Breazeal, Don" , "gdb@sourceware.org" Subject: RE: hbreak reads memory Date: Tue, 02 Aug 2016 09:15:00 -0000 Message-ID: References: In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=adrian.oltean@nxp.com; x-ms-office365-filtering-correlation-id: 20b61dd7-4bca-4f13-53a7-08d3bab57f31 x-microsoft-exchange-diagnostics: 1;VI1PR0401MB2669;6:UTPGYUgSCaRl+24WLmKLIiBqseTmqVBZ8x1XMVCKI1HjPf/SQWT1EJWwSwqpcjyLDB20mMHHbrGWTtkfU0ZLf+xW3PVfEuU2IpXEPf/hH/jPTLQq2JX4PcmKA6X1G+e0w8gnxcNLhEhWs6NaGgMMXVEEPToO7sC5u5npC0CfB2TtFxmKZ7knGmd43qR0eynJRuSE0iF73Y/zaPyKQoUMXOsSbjwzhJhd5RtUdgkTWgiEMI1fdom4rhP7hKXXMRCC3/bfVGnVUaTA3z1ceZHJjKmqLnS+qCMkWckOZU2EFoLwq2smbv8N9+kvt8rPp6zavkO0cRL0o8Umi9uRjhdmVg==;5:pUYLMkZ2gkTOT0zy3Fv3BBh4cxNRIvz7Pkn8rjkB7A3lEc+V17uR32+sGGa67lSy7vnzSgfJ2dM/qSrgWQn4nRO6MdI4A1Mii4T5Et/Cg8iCUmgw826xDl4VBfBOLIldUPiQ2jKNkg/F441yQxh/2g==;24:ZipflMGcuBy+45aopXgbInMWDNuXHpAVkfl+m2Pz78sNtQG68q5g65ueIzEBJK4YuTcPr9iXK0bGvdGayXEQXWH7HJfRCdDMMdTUMdcydQ0=;7:ezj0OyMAS34uwYaYE+YdwKtRBnBOgwwKph1bBuhEQyg9YtCRUlaEi0x/CUOcnT7HK8t1dK1UeYvynSNwxMriAQGU/t8mzOUz3vodlD5Uo637Z97Sysdf6LoTxKdzDqDOAepitCCm/HKPd3DYS5c5A5EVWB1c1IRVMMLM2X5tG4E3ATggQV8ZhyLDXw/o6ofQGeC7gYZW7NbQvtWoSg5yUnTcILdnz9n1PCTedwfCUKcSYNTUWRRUp869jFeHfVQ9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2669; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:VI1PR0401MB2669;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2669; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(377454003)(199003)(189002)(13464003)(24454002)(2900100001)(10400500002)(110136002)(105586002)(2950100001)(77096005)(189998001)(66066001)(19580405001)(122556002)(76176999)(9686002)(1411001)(11100500001)(93886004)(106356001)(97736004)(92566002)(50986999)(54356999)(586003)(101416001)(87936001)(86362001)(5002640100001)(3660700001)(8936002)(68736007)(7736002)(33656002)(3480700004)(2906002)(4326007)(76576001)(3846002)(81156014)(102836003)(74316002)(7846002)(305945005)(7696003)(8676002)(81166006)(6116002)(19580395003)(3280700002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0401MB2669;H:VI1PR0401MB2671.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 09:15:07.3356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2669 X-SW-Source: 2016-08/txt/msg00003.txt.bz2 VGhhbmtzIFlhbyBmb3IgZXhwbGFpbmluZyB0aGUgb3JpZ2luIG9mIHRoYXQg bWVtb3J5IGFjY2Vzcy4gU28gcmVhZGluZyBtZW1vcnkgZm9yIGEgDQpoYnJl YWsgc2VlbXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yLiBNeSB1bmRlcnN0YW5k aW5nIHdhcyB0aGF0IHNldHRpbmcgYSBIVyBicmVhayANCndvdWxkIG5vdCBp bXBseSBhIG1lbSByZWFkIG9wZXJhdGlvbiBhbmQgSSdkIHNpbXBseSBoYXZl IHRvIGRlYWwgd2l0aCBzZXR0aW5nIHRoYXQNCkhXIGJyZWFrIGluc2lkZSBt eSBkZWJ1ZyBzdHViLiBCdXQgdGhlIGFjY2VzcyBjYW4ndCBiZSBhdm9pZGVk IGFzIGZhciBhcyBJIHVuZGVyc3RhbmQNCmZyb20geW91Lg0KDQpUaGFua3Ms DQpBZHJpYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFlhbyBRaSBbbWFpbHRvOnFpeWFvbHRjQGdtYWlsLmNvbV0gDQpTZW50OiBU dWVzZGF5LCBBdWd1c3QgMDIsIDIwMTYgMTE6NDQgQU0NClRvOiBBbGV4YW5k cnUtQWRyaWFuIE9sdGVhbiA8YWRyaWFuLm9sdGVhbkBueHAuY29tPg0KQ2M6 IEJyZWF6ZWFsLCBEb24gPERvbl9CcmVhemVhbEBtZW50b3IuY29tPjsgZ2Ri QHNvdXJjZXdhcmUub3JnDQpTdWJqZWN0OiBSZTogaGJyZWFrIHJlYWRzIG1l bW9yeQ0KDQpPbiBUaHUsIEp1bCAyOCwgMjAxNiBhdCA3OjI4IEFNLCBBbGV4 YW5kcnUtQWRyaWFuIE9sdGVhbiA8YWRyaWFuLm9sdGVhbkBueHAuY29tPiB3 cm90ZToNCj4gSGkgRG9uLA0KPg0KPiBJIGZvcmdvdCB0byBtZW50aW9uIG9u ZSBpbXBvcnRhbnQgdGhpbmcgaW4gbXkgcHJldmlvdXMgZW1haWwgLSBJJ20g c2V0dGluZyBicmVha3MgdXNpbmcgYWRkcmVzc2VzIG5vdCBzeW1ib2xzLg0K PiBTbyBldmVuIHdpdGggdGhpcyBhcHByb2FjaCBJJ20gc3RpbGwgc2VlaW5n IHRoYXQgbWVtb3J5IGlzIGJlaW5nIA0KPiBhY2Nlc3NlZC4gSSdtIGV4cGVj dGluZyBhIGhicmVhayBvbiBhIGdpdmVuIGFkZHJlc3MgdG8gc2tpcCB0aGF0 IGZ1bmN0aW9uIHByb2xvZ3VlIGFuYWx5c2lzLg0KPg0KPiBIZXJlJ3Mgd2hh dCBJIHNlZSB3aGVuIGFjdGl2YXRpbmcgZGVidWcgaW4gZ2RiOg0KPiBoYnJl YWsgKjB4ZmZmNTRkNjQNCj4gU2VuZGluZyBwYWNrZXQ6ICRtZmZmNTRkNjQs NCMzNi4uLkFjaw0KPiBQYWNrZXQgcmVjZWl2ZWQ6IEUwMQ0KPiBIYXJkd2Fy ZSBhc3Npc3RlZCBicmVha3BvaW50IDMgYXQgMHhmZmY1NGQ2NA0KPg0KDQpJ IGRvbid0IHRoaW5rIGl0IGlzIHdyb25nIGZvciBHREIgdG8gcmVhZCB0aGF0 IG1lbW9yeSBpbiAnaGJyZWFrJy4gICdoYnJlYWsnDQptZWFucyBoYXJkd2Fy ZSBicmVha3BvaW50IChyYXRoZXIgdGhhbiBzb2Z0d2FyZSBicmVha3BvaW50 KSwgc28gR0RCIHNob3VsZG4ndCB3cml0ZSBicmVha3BvaW50IGluc3RydWN0 aW9uIHRvIHRoZSBhZGRyZXNzLCBidXQgbWF5IG5lZWQgdG8gcmVhZCB0aGF0 IHBpZWNlIG9mIG1lbW9yeS4gIElmIHRoZSBtZW1vcnkgaXMgdW5yZWFkYWJs ZSwgeW91ciBkZWJ1ZyBzdHViIHJldHVybnMgZXJyb3IuDQoNClRoZSByZWFz b24gb2YgbWVtb3J5IGFjY2VzcyBvZiAnaGJyZWFrJyBpcyB0aGF0IEdEQiBj aGVja3Mgd2hldGhlciB0aGVyZSBoYXMgYmVlbiBhIHBlcm1hbmVudCBicmVh a3BvaW50IG9uIHRoYXQgYWRkcmVzcyBvciBub3QuDQoNCiM5ICAweDAwMDAw MDAwMDA4YzI0NTcgaW4gdGFyZ2V0X3JlYWRfbWVtb3J5IChtZW1hZGRyPTY3 MzM2LA0KbXlhZGRyPTB4N2ZmZjlhMmFiNWUwICJcMjY1XHYiLCBsZW49NCkg YXQNCi9ob21lL3lhby9Tb3VyY2VDb2RlL2dudS9nZGIvZ2l0L2dkYi90YXJn ZXQuYzoxNDU5DQojMTAgMHgwMDAwMDAwMDAwNmM1MzdkIGluIHByb2dyYW1f YnJlYWtwb2ludF9oZXJlX3AgKGdkYmFyY2g9MHg2MjEwMDAxMzlkMTAsIGFk ZHJlc3M9NjczMzYpIGF0DQovaG9tZS95YW8vU291cmNlQ29kZS9nbnUvZ2Ri L2dpdC9nZGIvYnJlYWtwb2ludC5jOjkxMzUNCiMxMSAweDAwMDAwMDAwMDA2 YzU2NzcgaW4gYnBfbG9jX2lzX3Blcm1hbmVudCAobG9jPTB4NjEzMDAwMDE4 YTAwKSBhdA0KL2hvbWUveWFvL1NvdXJjZUNvZGUvZ251L2dkYi9naXQvZ2Ri L2JyZWFrcG9pbnQuYzo5MTY1DQojMTIgMHgwMDAwMDAwMDAwNmM1MWM5IGlu IGFkZF9sb2NhdGlvbl90b19icmVha3BvaW50IChiPTB4NjExMDAwMjI5Mzgw LCBzYWw9MHg3ZmZmOWEyYWI3ZDApIGF0DQovaG9tZS95YW8vU291cmNlQ29k ZS9nbnUvZ2RiL2dpdC9nZGIvYnJlYWtwb2ludC5jOjkxMDINCiMxMyAweDAw MDAwMDAwMDA2YmU2YTkgaW4gaW5pdF9yYXdfYnJlYWtwb2ludCAoYj0weDYx MTAwMDIyOTM4MCwgZ2RiYXJjaD0weDYyMTAwMDE3ZDUxMCwgc2FsPS4uLiwg YnB0eXBlPWJwX2hhcmR3YXJlX2JyZWFrcG9pbnQsDQogICAgb3BzPTB4MTNk NjIwMCA8YmtwdF9icmVha3BvaW50X29wcz4pIGF0DQovaG9tZS95YW8vU291 cmNlQ29kZS9nbnUvZ2RiL2dpdC9nZGIvYnJlYWtwb2ludC5jOjc1OTUNCg0K LS0NCllhbyAo6b2Q5bCnKQ0K >From gdb-return-45209-listarch-gdb=sources.redhat.com@sourceware.org Mon Aug 08 14:56:26 2016 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 7139 invoked by alias); 8 Aug 2016 14:56:25 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 7129 invoked by uid 89); 8 Aug 2016 14:56:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,MSGID_MULTIPLE_AT autolearn=no version=3.3.2 spammy=Old, H*i:sk:announc, envoy, fonction X-HELO: mailhost.u-strasbg.fr Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.222.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Aug 2016 14:56:14 +0000 Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antispam (Postfix) with ESMTP id 3FDB9223360 for ; Mon, 8 Aug 2016 16:56:11 +0200 (CEST) Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id 2D79F222E6C for ; Mon, 8 Aug 2016 16:56:11 +0200 (CEST) Received: from local-mr.u-strasbg.fr (lmr1.u-strasbg.fr [172.30.21.1]) by mr1.u-strasbg.fr (Postfix) with ESMTP id 1EAA2223360 for ; Mon, 8 Aug 2016 16:56:10 +0200 (CEST) Received: from local-mr.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id EE51BAF for ; Mon, 8 Aug 2016 16:56:09 +0200 (CEST) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (Authenticated sender: mullerp) by lmr1.u-strasbg.fr (Postfix) with ESMTPSA id D3256A1 for ; Mon, 8 Aug 2016 16:56:08 +0200 (CEST) From: "Pierre Muller" To: References: In-Reply-To: Subject: mingw32 build failure [ANNOUNCEMENT] GDB 7.12 release branch created! Date: Mon, 08 Aug 2016 14:56:00 -0000 Message-ID: <000f01d1f184$fe9a7ed0$fbcf7c70$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-08/txt/msg00004.txt.bz2 Content-length: 4154 Hello, I would like to report a problem that I encounter when trying to generate a new GDB binary for i686-w64-mingw32 host. I am using cygwin to compile a GDB for this host with ../gdb-7.11.90/configure --host=3Di686-w64-mingw32 The configuration succeeds, but compilation fails a gdb binary linking with the following error: gdb-dlfcn.o: dans la fonction =AB Z10gdb_dlopenPKc =BB: /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-7.11.90/gdb/gdb- dlfcn.c:72: r=E9f=E9rence ind=E9finie vers =AB dlopen(char const*, int) =BB /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-7.11.90/gdb/gdb- dlfcn.c:80: r=E9f=E9rence ind=E9finie vers =AB dlerror() =BB gdb-dlfcn.o: dans la fonction =AB gdb_dlclose =BB: /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-7.11.90/gdb/gdb- dlfcn.c:113: r=E9f=E9rence ind=E9finie vers =AB dlclose(void*) =BB gdb-dlfcn.o: dans la fonction =AB Z9gdb_dlsymPvPKc =BB: /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-7.11.90/gdb/gdb- dlfcn.c:103: r=E9f=E9rence ind=E9finie vers =AB dlsym(void*, char const*) = =BB gdb-dlfcn.o: dans la fonction =AB Z11gdb_dlclosePv =BB: /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-7.11.90/gdb/gdb- dlfcn.c:113: r=E9f=E9rence ind=E9finie vers =AB dlclose(void*) =BB collect2: erreur=A0: ld a retourn=E9 1 code d'=E9tat d'ex=E9cution make[1]: *** [Makefile:1409: gdb.exe] Error 1 make[1]=A0: on quitte le r=E9pertoire =AB=A0/usr/local/src/gdb-releases/build-gdb-7.11.90/gdb=A0=BB make: *** [Makefile:9169: all-gdb] Error 2 This is due the switch to using C++ as default compiler combined with the fact that i686-w64-mingw32 does supply a dlfcn.h header, but this header does not contain the usual C++ macros: #ifdef __cplusplus extern "C" { #endif and final counterpart. Thus GNU C++ compiler mangles the dlopen, dlerror, dlclose and dlsym functions instead of using the C compiler generated assembler symbols, i.e. simply '_dlopen', '_dlerror' ... and final linking fails because of this. Is this only an error in the i686-w64-mingw32 distribution? The problem is that it does not seem possible to use the=20 'old' mingw32 substitute code by some configure option. Disabling the #define HAVE_DLFCN_H 1 inside the generated gdb/config.h does NOT work, because after manual change to config.h, calling make with regenerate gdb/config.h with the wrong #define HAVE_DLFCN_H 1 line. Is it also an error in the configure process? I would expect that if we use g++ as a compiler, we should test the different headers using this compiler, rather than using gcc. I also noticed that mingw32 still adds -D__USE_MINGW_ACCESS to CFLAGS but it doesn't do so for CXXFLAGS. According to /mingw/include/io.h, this might also influence generated executables: 349:#ifdef __USE_MINGW_ACCESS 350-/* Old versions of MSVCRT access() just ignored X_OK, while the version 351- shipped with Vista, returns an error code. This will restore the 352- old behaviour */ 353-static inline int __mingw_access (const char *__fname, int __mode) { 354- return _access (__fname, __mode & ~X_OK); 355-} 356- 357-#define access(__f,__m) __mingw_access (__f, __m) 358-#endif Apart from temporarily hiding include/dlfcn.h header, is there any=20 less ugly way to overcome this problem? Pierre Muller Pascal language maintainer > -----Message d'origine----- > De=A0: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la > part de Joel Brobecker > Envoy=E9=A0: lundi 1 ao=FBt 2016 17:28 > =C0=A0: gdb@sourceware.org > Objet=A0: [ANNOUNCEMENT] GDB 7.12 release branch created! >=20 > Hello, >=20 > A quick message to announce that the GDB 7.12 branch has just been > created. >=20 > The prerelease snapshots will be available at: >=20 > ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.xz > ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.gz >=20 > The sources are also accessible via GIT: >=20 > git clone --single-branch --branch=3Dgdb-7.12-branch > git://sourceware.org/git/binutils-gdb.git >=20 > This announcement has also been posted on the GDB web site at: >=20 > http://www.sourceware.org/gdb/