From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24439 invoked by alias); 14 Jun 2017 13:54:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24172 invoked by uid 89); 14 Jun 2017 13:54:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-3.5 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=couldn=e2, couldn, Hauthentication-results:gmail.com?= X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-ve1eur01on0040.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (104.47.1.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Jun 2017 13:54:30 +0000 Received: from DB3PR08MB0106.eurprd08.prod.outlook.com (10.161.56.20) by DB3PR08MB0106.eurprd08.prod.outlook.com (10.161.56.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Wed, 14 Jun 2017 13:54:32 +0000 Received: from DB3PR08MB0106.eurprd08.prod.outlook.com ([fe80::b409:2748:dd27:79e6]) by DB3PR08MB0106.eurprd08.prod.outlook.com ([fe80::b409:2748:dd27:79e6%14]) with mapi id 15.01.1157.017; Wed, 14 Jun 2017 13:54:32 +0000 From: Alan Hayward To: Yao Qi CC: "gdb-patches@sourceware.org" , nd Subject: Re: [RFC] LONGEST and ULONGEST function template instantiation Date: Wed, 14 Jun 2017 13:54:00 -0000 Message-ID: <4128F440-F798-4BA5-BEFC-4008D3F65BE0@arm.com> References: <1497353362-14441-1-git-send-email-yao.qi@linaro.org> In-Reply-To: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DB3PR08MB0106;7:pOPKzJZZlWMB5tGbRDXmLYxWrVpC9yhBVMqsPNx7NETJ8o7ifboM1MxyZnBidCWXYGtCd4m2sf1L85Zhdub22qRQYjeT1CiNCd1eWFb4DT8U2xPo4xCWoeOTHJYgKIZ42CTSBHCKR7D3zIZ1LddLa7EKjk0OcCK9I4saycJ+dYjF7RxTzTnm+3QfinH7GR7PA5yYvZHulDLSyHgqKnGsNcriCuZOKzFJaC4jdQltSyUxSTjh7O0HSJeUt3ZqJo9+nwXxEcU6dbLOSPaXxb1Rt/QCqicPckwcnrjuly1RrMDJWqoVsjLyrjGeiX7KSsXx4J8QEKk1aF5bB2YjXwghyw== x-ms-traffictypediagnostic: DB3PR08MB0106: x-ms-office365-filtering-correlation-id: ae3f6329-706b-450e-4a7f-08d4b32ce24d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:DB3PR08MB0106; nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DB3PR08MB0106;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DB3PR08MB0106; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(979002)(6009001)(39400400002)(39450400003)(39850400002)(39410400002)(39840400002)(24454002)(377454003)(4326008)(38730400002)(110136004)(229853002)(3280700002)(83716003)(99286003)(2900100001)(189998001)(25786009)(2950100002)(6916009)(6506006)(54906002)(6436002)(3846002)(6116002)(82746002)(3660700001)(36756003)(33656002)(50986999)(6486002)(8676002)(8936002)(2906002)(86362001)(6512007)(305945005)(53936002)(102836003)(14454004)(6306002)(81166006)(54356999)(478600001)(5250100002)(53546009)(1411001)(39060400002)(966005)(66066001)(72206003)(6246003)(76176999)(5660300001)(7736002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR08MB0106;H:DB3PR08MB0106.eurprd08.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1D461FDFE1A2544E916F8F347E9D5A4F@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2017 13:54:31.9919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB0106 X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00421.txt.bz2 DQo+IE9uIDEzIEp1biAyMDE3LCBhdCAxMjozMywgWWFvIFFpIDxxaXlhb2x0 Y0BnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gVHVlLCBKdW4gMTMsIDIw MTcgYXQgMTI6MjkgUE0sIFlhbyBRaSA8cWl5YW9sdGNAZ21haWwuY29tPiB3 cm90ZToNCj4gDQo+PiANCj4+IFRoaXMgcGF0Y2ggd2FzIHBvc3RlZCBoZXJl DQo+PiBodHRwczovL3NvdXJjZXdhcmUub3JnL21sL2dkYi1wYXRjaGVzLzIw MTctMDUvbXNnMDA0OTIuaHRtbCBidXQgdGhlDQo+PiBwcm9ibGVtIHdhcyBm aXhlZCBpbiBhIGRpZmZlcmVudCB3YXkuICBIb3dldmVyLCBJIHRoaW5rIHRo ZSBwYXRjaCBpcyBzdGlsbA0KPj4gdXNlZnVsIHRvIHNob3J0ZW4gdGhlIGNv ZGUuDQo+IA0KPiBBZGQgQWxhbiB0byBDQy4NCj4gDQoNCj4gSXQgaXMgYW4g UkZDLCBiZWNhdXNlIEkgYW0gbm90IHN1cmUgcGVvcGxlIGxpa2UgaXQgb3Ig aGF0ZSBpdCA6KQ0KDQpNeSBvbmx5IG9iamVjdGlvbiB0byB0aGlzIHdvdWxk IGJlIHRoYXQg4oCcZW5hYmxlX2lm4oCdIGlzIGZhaXJseSBjb25mdXNpbmcu DQpIb3dldmVyLCBoYXZpbmcgc2FpZCB0aGF0LCBJIHRoaW5rIHRoZSBlbmQg cmVzdWx0IGlzIHF1aXRlIG5pY2UsIGFuZA0KY2FsbGluZyB0aGUgZnVuY3Rp b25zIGlzIHZlcnkgc2ltcGxlLCBzbyBJIHdpdGhkcmF3IG15IG9iamVjdGlv bi4NCg0KSXQgd291bGQgYmUgbmljZSBpZiB0aGUgaGVhZGVyIGZpbGVzIGNv dWxkIHVzZSDigJxMb25nVHlwZeKAnSBpbnN0ZWFkIG9mDQp0aGUgbG9uZ2Vy IOKAnGVuYWJsZV9pZuKAnSBibG9jaywgaG93ZXZlciBJIHJlbWVtYmVyIHdo ZW4gSSB0cmllZCB0aGlzDQpteXNlbGYgYW5kIGNvdWxkbuKAmXQgZmluZCBh IHdheSBhcm91bmQgaXQuDQoNCg0KQWxhbi4NCg0K >From gdb-patches-return-139803-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Jun 14 14:02:43 2017 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 81512 invoked by alias); 14 Jun 2017 14:02:43 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 77870 invoked by uid 89); 14 Jun 2017 14:02:40 -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_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:4274, noticeable, our X-HELO: smtprelay.synopsys.com Received: from smtprelay4.synopsys.com (HELO smtprelay.synopsys.com) (198.182.47.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Jun 2017 14:02:33 +0000 Received: from mailhost.synopsys.com (mailhost1.synopsys.com [10.12.238.239]) by smtprelay.synopsys.com (Postfix) with ESMTP id 25DC424E164F; Wed, 14 Jun 2017 07:02:37 -0700 (PDT) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id 0F673B92; Wed, 14 Jun 2017 07:02:37 -0700 (PDT) Received: from US01WEHTC2.internal.synopsys.com (us01wehtc2-vip.internal.synopsys.com [10.12.239.238]) by mailhost.synopsys.com (Postfix) with ESMTP id 07094B91; Wed, 14 Jun 2017 07:02:36 -0700 (PDT) Received: from DE02WEHTCB.internal.synopsys.com (10.225.19.94) by US01WEHTC2.internal.synopsys.com (10.12.239.237) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 14 Jun 2017 07:02:36 -0700 Received: from DE02WEMBXB.internal.synopsys.com ([fe80::95ce:118a:8321:a099]) by DE02WEHTCB.internal.synopsys.com ([::1]) with mapi id 14.03.0266.001; Wed, 14 Jun 2017 16:02:35 +0200 From: Anton Kolesov To: Simon Marchi CC: "gdb-patches@sourceware.org" , Francois Bedard Subject: RE: [PATCH v2] arc: Select CPU model properly before disassembling Date: Wed, 14 Jun 2017 14:02:00 -0000 Message-ID: <39A54937CC95F24AA2F794E2D2B66B1358756E48@DE02WEMBXB.internal.synopsys.com> References: <39A54937CC95F24AA2F794E2D2B66B135874F238@DE02WEMBXB.internal.synopsys.com> <20170613134951.29359-1-Anton.Kolesov@synopsys.com> <887411aaab641fb92f809eadce4d9011@polymtl.ca> In-Reply-To: <887411aaab641fb92f809eadce4d9011@polymtl.ca> x-dg-ref: =?us-ascii?Q?PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcYWtvbGVzb3Yu?= =?us-ascii?Q?c3lub3BzeXNcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04?= =?us-ascii?Q?NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy0xYmVlZjMyNS01MTBhLTExZTct?= =?us-ascii?Q?YTgwYS00ODUxYjc3ZTlhOTVcYW1lLXRlc3RcMWJlZWYzMjYtNTEwYS0xMWU3?= =?us-ascii?Q?LWE4MGEtNDg1MWI3N2U5YTk1Ym9keS50eHQiIHN6PSI0NDIwIiB0PSIxMzE0?= =?us-ascii?Q?MTkyMjU1MzAzNzk0MDQiIGg9IldVcTdPaTV1YWUxUEYwMUVpcVZBNERVSXRX?= =?us-ascii?Q?MD0iIGlkPSIiIGJsPSIwIiBibz0iMSIgY2k9ImNBQUFBRVJIVTFSU1JVRk5D?= =?us-ascii?Q?Z1VBQUJRSkFBQ01MR1hlRnVYU0FlMkE4N2x0OGNNUjdZRHp1VzN4d3hFT0FB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFIQUFBQUNrQ0FBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFFQUFRQUJBQUFBdStNMzN3QUFBQUFBQUFBQUFBQUFBSjRB?= =?us-ascii?Q?QUFCbUFHa0FiZ0JoQUc0QVl3QmxBRjhBY0FCc0FHRUFiZ0J1QUdrQWJnQm5B?= =?us-ascii?Q?RjhBZHdCaEFIUUFaUUJ5QUcwQVlRQnlBR3NBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUVBQUFBQUFBQUFBZ0FBQUFBQW5nQUFBR1lBYndCMUFHNEFa?= =?us-ascii?Q?QUJ5QUhrQVh3QndBR0VBY2dCMEFHNEFaUUJ5QUhNQVh3Qm5BR1lBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFRQUFB?= =?us-ascii?Q?QUFBQUFBQ0FBQUFBQUNlQUFBQVpnQnZBSFVBYmdCa0FISUFlUUJmQUhBQVlR?= =?us-ascii?Q?QnlBSFFBYmdCbEFISUFjd0JmQUhNQVlRQnRBSE1BZFFCdUFHY0FYd0JqQUc4?= =?us-ascii?Q?QWJnQm1BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCQUFBQUFBQUFBQUlBQUFBQUFK?= =?us-ascii?Q?NEFBQUJtQUc4QWRRQnVBR1FBY2dCNUFGOEFjQUJoQUhJQWRBQnVBR1VBY2dC?= =?us-ascii?Q?ekFGOEFjd0JoQUcwQWN3QjFBRzRBWndCZkFISUFaUUJ6QUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBRUFBQUFBQUFBQUFnQUFBQUFBbmdBQUFHWUFid0IxQUc0?= =?us-ascii?Q?QVpBQnlBSGtBWHdCd0FHRUFjZ0IwQUc0QVpRQnlBSE1BWHdCekFHMEFhUUJq?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVFB?= =?us-ascii?Q?QUFBQUFBQUFDQUFBQUFBQ2VBQUFBWmdCdkFIVUFiZ0JrQUhJQWVRQmZBSEFB?= =?us-ascii?Q?WVFCeUFIUUFiZ0JsQUhJQWN3QmZBSE1BZEFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFB?= =?us-ascii?Q?QUo0QUFBQm1BRzhBZFFCdUFHUUFjZ0I1QUY4QWNBQmhBSElBZEFCdUFHVUFj?= =?us-ascii?Q?Z0J6QUY4QWRBQnpBRzBBWXdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFFQUFBQUFBQUFBQWdBQUFBQUFuZ0FBQUdZQWJ3QjFB?= =?us-ascii?Q?RzRBWkFCeUFIa0FYd0J3QUdFQWNnQjBBRzRBWlFCeUFITUFYd0IxQUcwQVl3?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?UUFBQUFBQUFBQUNBQUFBQUFDZUFBQUFad0IwQUhNQVh3QndBSElBYndCa0FI?= =?us-ascii?Q?VUFZd0IwQUY4QWRBQnlBR0VBYVFCdUFHa0FiZ0JuQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFBQUFBQUFBQUFJQUFB?= =?us-ascii?Q?QUFBSjRBQUFCekFHRUFiQUJsQUhNQVh3QmhBR01BWXdCdkFIVUFiZ0IwQUY4?= =?us-ascii?Q?QWNBQnNBR0VBYmdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUVBQUFBQUFBQUFBZ0FBQUFBQW5nQUFBSE1BWVFC?= =?us-ascii?Q?c0FHVUFjd0JmQUhFQWRRQnZBSFFBWlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFRQUFBQUFBQUFBQ0FBQUFBQUNlQUFBQWN3QnVBSEFBY3dCZkFHd0FhUUJq?= =?us-ascii?Q?QUdVQWJnQnpBR1VBWHdCaEFIVUFkQUJvQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFCQUFBQUFBQUFBQUlB?= =?us-ascii?Q?QUFBQUFKNEFBQUJ6QUc0QWNBQnpBRjhBYkFCcEFHTUFaUUJ1QUhNQVpRQmZB?= =?us-ascii?Q?SE1BZEFCaEFISUFkQUJmQUdRQVlRQjBBR1VBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBRUFBQUFBQUFBQUFnQUFBQUFBbmdBQUFITUFi?= =?us-ascii?Q?Z0J3QUhNQVh3QnNBR2tBWXdCbEFHNEFjd0JsQUY4QWRBQmxBSElBYlFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQVFBQUFBQUFBQUFDQUFBQUFBQT0iLz48L21ldGE+?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2017-06/txt/msg00423.txt.bz2 Content-length: 4299 Hi Simon, > > + if (info->disassembler_options =3D=3D NULL) > > + { > > + struct obj_section * s =3D find_pc_section (addr); >=20 > Extra space after the *. This was copied from mep-tdep.c. Should I make a separate patch that fixes = it there too? >=20 > > + if (s !=3D NULL) > > + info->section =3D s->the_bfd_section; > > + } >=20 > When printing multiple instructions in a row, is this function called mul= tiple > times with the same disassemble_info? If so, are we going to make a > find_pc_section call for each instruction? Is this needed, given that the > options won't change for a given ELF (on ARC at least)? I think it might not work if there is a multi-arch target and disassembler invocation tries to dump instructions across multiple sections which come f= rom different ELF files (not sure if shared libraries would count as a separate= ELF files). But usually disassembler works per-function and practically I don't think that there would be a case of function that crosses section boundary. I've put this optimization to my v3 patch. >=20 > I was a bit concerned with the fact that multiple gdbarch objects (that > represent different architectures) can end up sharing the same pointer to > arc_disassembler_options, so necessarily some of them will have the wrong > value at a certain point. But that doesn't look like an immediate proble= m, > since you don't seem to recycle previously created gdbarch objects, like > some other architectures do (does that mean that the gdbarch list keeps > growing indefinitely if you connect multiple times, load new exec files?)= . The > gdbarch in use should always be the last that was created, so > arc_disassembler_options should contain the good value for that gdbarch. = I > was thinking that a situation like this could be problematic, if you were= re- > using gdbarch objects: >=20 > 1. You connect to a gdbserver that reports arch A. A gdbarch is created = and > arc_disassembler_options is set for arch A. > 2. You disconnect, and connect to a gdbserver that reports arch B. A gdb= arch > is created and arc_disassembler_options is set for arch B. > 3. You disconnect, and connect again to the first gdbserver. This time, = you > would return the existing gdbarch for arch A, so the current gdbarch (arc= h A) > would still use the disassembler options of arch B. >=20 > But like I said, that doesn't seem to be the case right now. >=20 > That makes me wonder why we pass a char ** and not simply an allocated > char *, of which the gdbarch would take ownership, which would avoid this > problem entirely. This is the same thing as in {arm,rs6000,s390-linux}-tdep.c - they all use global static variable, which would be shared across multiple gdbarch instances. So when options are changed that would change that for any gdbar= ch of that architecture. RS6000 and S390 don't even assign this variable any v= alue - it completely managed by the disasm.c. Although in ARC case there is a me= mory leak, because arc_disassembler_options is only assigned by arc-tdep.c and never freed - that's because I didn't properly understood what other arches do - they don't free options as well, but they also don't allocate them in each gdbarch_init, because there usecase is somewhat different. I'm not sure how big of a problem this leak is, because outside of a GDB test suite I do= n't think there are a lot of practical cases where same GDB instance is reused = to connect/disconnect, so leak wouldn't be noticeable. I think, I can make things better for ARC, by moving arc_disassembler_options into the gdbarch_tdep, then each gdbarch for ARC will have its own options, but that would mean behavior different from other arches which support disassembler_options - there options are shared across gdbarches of architecture. Should I do that in V3? TBH, that would be a moot for ARC right now, because today our disassembler has a global state and it doesn't support simultaneous disassembly of different ARC architectures anyway, but it might make sense to try to make sure that GDB part handles this correctly, if in the future disassembler would be upgraded to avoid global state. The reuse of gdbarch instances seems like a good idea, will try to add that in the future for ARC. Anton >=20 > Simon