From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54958 invoked by alias); 16 Jan 2020 09:02:06 -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 54947 invoked by uid 89); 16 Jan 2020 09:02:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:3165 X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jan 2020 09:01:55 +0000 Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2020 01:01:52 -0800 Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga005.fm.intel.com with ESMTP; 16 Jan 2020 01:01:52 -0800 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 16 Jan 2020 01:01:52 -0800 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 16 Jan 2020 01:01:51 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by orsmsx607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 16 Jan 2020 01:01:51 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.107) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 16 Jan 2020 01:01:51 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SARjLhj/+GwTATL3mhwJw0Bzl37Osos/das7S7jWegyE7KyFdThsKUApDlVRgvKmSxE5+Z0KR4q92XO+HL/m4y4/gtUpUMDT3odreGiwq6FE3R9fGHoz9zk3cM3ocoyeK7ExL3beyN0mjdknPtTzs/BHAkOM/vjZ4KYNR/3ntZ6o8Hiezu1p+s5u4JR5iM3Ug8K8Nr6TwM3QwpRSiAbhG1ACm/lG1pIukn3mJRBgn9knM/P7pZPDtYSdbs1CfZ1vbiSJo3KgZzJTwTbC6j8mwsGBuEngyAaSUS4IsSvKX0uQ9VTmXNsZSWzL5UrX1pPCDrCrTryi/beblFz/TVK4dw== 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-SenderADCheck; bh=Km7rkp8cpMG3uTFdx94QxWZifN143uFKc3mdHl/sVPA=; b=TiZ8yh9Ck60oiEZnYGH1PjBuz3/qvVEv8r7C8vkgGRD4gQIf4YdYdoTs2fINahBmK591gCgw3xg+FMNBuW7FpCKsW5xK1bZWq9PcYr+GrJz57fQ+x5ivnXsChs+Duf+wYIZPagnYmtJJSHNAuXtrWs7XAAQYMY1Rij8N7YIZkZSCCmbX/QPQLH8y4TTntn5cKCeO8nA8uUeRzmp/KYbHBSG+bcMZKqzIOSzaHXk76ByZVUO7xh/Wnz1IfCO6hvKKaUOWWfl4SFOsQYCeaWfLwLCsuX02MX1FbNM/6dNKC4awPqEeippSUyP5OGIVahEcZOBFLhFLtwU66Y+ZShf1wQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Km7rkp8cpMG3uTFdx94QxWZifN143uFKc3mdHl/sVPA=; b=FQs1m6pFiHOZZ+u2YjuFcSRxOWl66kdfiMeD/6CNiLC1bIIrlf0XF+Eahly5t1iwnc57FqSJ6MLDRu7ibBzypZ2vLSOO9EVy4YQo9HEhJMgpIuM1zYCodpvifj5o+gd+n6ioVe75lmKXKXoM47u+FXR5m08hJeKHgaeF73JPzPA= Received: from BYAPR11MB3030.namprd11.prod.outlook.com (20.177.225.91) by BYAPR11MB2774.namprd11.prod.outlook.com (52.135.224.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 16 Jan 2020 09:01:49 +0000 Received: from BYAPR11MB3030.namprd11.prod.outlook.com ([fe80::2c94:a4bd:2d9c:30b]) by BYAPR11MB3030.namprd11.prod.outlook.com ([fe80::2c94:a4bd:2d9c:30b%6]) with mapi id 15.20.2623.015; Thu, 16 Jan 2020 09:01:49 +0000 From: "Aktemur, Tankut Baris" To: Simon Marchi , "gdb-patches@sourceware.org" Subject: RE: [PATCH 2/4] gdb: remove use of iterate_over_inferiors in mi/mi-interp.c Date: Thu, 16 Jan 2020 11:29:00 -0000 Message-ID: References: <20200115191222.28208-1-simon.marchi@efficios.com> <20200115191222.28208-3-simon.marchi@efficios.com> In-Reply-To: <20200115191222.28208-3-simon.marchi@efficios.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=tankut.baris.aktemur@intel.com; x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9U2hHjL4Ydj85uPalpgh5HH7f/pj66WN0ju37NszPCsevOxAvBnd3MuBd9Sfcw106wBmgElh+UkV/rKxeG422iplnperIpVFv9MGkLUZETs= Return-Path: tankut.baris.aktemur@intel.com Content-Transfer-Encoding: base64 X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00445.txt.bz2 T24gV2VkbmVzZGF5LCBKYW51YXJ5IDE1LCAyMDIwIDg6MTIgUE0sIFNpbW9u IE1hcmNoaSB3cm90ZToNCj4gUmVwbGFjZSBpdCB3aXRoIGEgcmFuZ2UtYmFz ZWQgZm9yLiAgSSBmaWd1cmVkIHRoYXQgaW4gdGhlIGh5cG90aGV0aWNhbCBj YXNlDQo+IHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBpbmZlcmlvcnMsIHdl IG9ubHkgbmVlZCB0byBjb25maWd1cmUgdGhlIHRlcm1pbmFsIGFuZA0KPiBm bHVzaCB0aGUgb3V0cHV0IG9uY2UsIHNvIEkgaGF2ZSBtb3ZlZCB0aGVzZSBv dXQgb2YgdGhlIGxvb3AuDQo+IA0KPiBnZGIvQ2hhbmdlTG9nOg0KPiANCj4g CSogbWkvbWktaW50ZXJwLmMgKHJlcG9ydF9pbml0aWFsX2luZmVyaW9yKTog UmVtb3ZlLg0KPiAJKG1pX2ludGVycDo6aW5pdCk6IFVzZSByYW5nZS1iYXNl ZCBmb3IgdG8gaXRlcmF0ZSBvdmVyIGluZmVyaW9ycy4NCj4gLS0tDQo+ICBn ZGIvbWkvbWktaW50ZXJwLmMgfCA0MCArKysrKysrKysrKysrKysrLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAxIGZpbGUgY2hhbmdlZCwgMTYgaW5z ZXJ0aW9ucygrKSwgMjQgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0 IGEvZ2RiL21pL21pLWludGVycC5jIGIvZ2RiL21pL21pLWludGVycC5jDQo+ IGluZGV4IDJhYzRjMTE5OTYxYy4uNmY0ZjU2ODQ5NjExIDEwMDY0NA0KPiAt LS0gYS9nZGIvbWkvbWktaW50ZXJwLmMNCj4gKysrIGIvZ2RiL21pL21pLWlu dGVycC5jDQo+IEBAIC05MSw4ICs5MSw2IEBAIHN0YXRpYyB2b2lkIG1pX21l bW9yeV9jaGFuZ2VkIChzdHJ1Y3QgaW5mZXJpb3IgKmluZiwgQ09SRV9BRERS IG1lbWFkZHIsDQo+ICAJCQkgICAgICAgc3NpemVfdCBsZW4sIGNvbnN0IGJm ZF9ieXRlICpteWFkZHIpOw0KPiAgc3RhdGljIHZvaWQgbWlfb25fc3luY19l eGVjdXRpb25fZG9uZSAodm9pZCk7DQo+IA0KPiAtc3RhdGljIGludCByZXBv cnRfaW5pdGlhbF9pbmZlcmlvciAoc3RydWN0IGluZmVyaW9yICppbmYsIHZv aWQgKmNsb3N1cmUpOw0KPiAtDQo+ICAvKiBEaXNwbGF5IHRoZSBNSSBwcm9t cHQuICAqLw0KPiANCj4gIHN0YXRpYyB2b2lkDQo+IEBAIC0xNDAsOCArMTM4 LDIyIEBAIG1pX2ludGVycDo6aW5pdCAoYm9vbCB0b3BfbGV2ZWwpDQo+ICAg ICAgICAvKiBUaGUgaW5pdGlhbCBpbmZlcmlvciBpcyBjcmVhdGVkIGJlZm9y ZSB0aGlzIGZ1bmN0aW9uIGlzDQo+ICAJIGNhbGxlZCwgc28gd2UgbmVlZCB0 byByZXBvcnQgaXQgZXhwbGljaXRseS4gIFVzZSBpdGVyYXRpb24gaW4NCj4g IAkgY2FzZSBmdXR1cmUgdmVyc2lvbiBvZiBHREIgY3JlYXRlcyBtb3JlIHRo YW4gb25lIGluZmVyaW9yDQo+IC0JIHVwLWZyb250LiAgKi8NCj4gLSAgICAg IGl0ZXJhdGVfb3Zlcl9pbmZlcmlvcnMgKHJlcG9ydF9pbml0aWFsX2luZmVy aW9yLCBtaSk7DQo+ICsJIHVwLWZyb250Lg0KPiArDQo+ICsgICAgICAgICBU aGlzIGZ1bmN0aW9uIGlzIGNhbGxlZCBmcm9tIG1pX2ludGVycHJldGVyX2lu aXQsIGFuZCBzaW5jZQ0KDQpUaGVyZSBpcyBhbiA4LXNwYWNlcy90YWIgaXNz dWUgYWJvdmUuICBBbmQgYWxzbywgdGhlIGNvbW1lbnQgcGllY2UgIlRoaXMN CmZ1bmN0aW9uIGlzIGNhbGxlZCBmcm9tIG1pX2ludGVycHJldGVyX2luaXQs IGFuZCIgc2VlbXMgb2Jzb2xldGUgbm93Lg0KDQpUaGFua3MsDQotQmFyaXMN Cg0KPiArCSBtaV9pbmZlcmlvcl9hZGRlZCBhc3N1bWVzIHRoYXQgaW5mZXJp b3IgaXMgZnVsbHkgaW5pdGlhbGl6ZWQNCj4gKwkgYW5kIHRvcF9sZXZlbF9p bnRlcnByZXRlcl9kYXRhIGlzIHNldCwgd2UgY2Fubm90IGNhbGwNCj4gKwkg aXQgaGVyZS4gICovDQo+ICsNCj4gKyAgICAgIHRhcmdldF90ZXJtaW5hbDo6 c2NvcGVkX3Jlc3RvcmVfdGVybWluYWxfc3RhdGUgdGVybV9zdGF0ZTsNCj4g KyAgICAgIHRhcmdldF90ZXJtaW5hbDo6b3Vyc19mb3Jfb3V0cHV0ICgpOw0K PiArDQo+ICsgICAgICBmb3IgKGluZmVyaW9yICppbmYgOiBhbGxfaW5mZXJp b3JzICgpKQ0KPiArCWZwcmludGZfdW5maWx0ZXJlZCAobWktPmV2ZW50X2No YW5uZWwsDQo+ICsJCQkgICAgInRocmVhZC1ncm91cC1hZGRlZCxpZD1cImkl ZFwiIiwNCj4gKwkJCSAgICBpbmYtPm51bSk7DQo+ICsNCj4gKyAgICAgIGdk Yl9mbHVzaCAobWktPmV2ZW50X2NoYW5uZWwpOw0KPiAgICAgIH0NCj4gIH0N Cj4gDQo+IEBAIC0xMjUzLDI2ICsxMjY1LDYgQEAgbWlfdXNlcl9zZWxlY3Rl ZF9jb250ZXh0X2NoYW5nZWQgKHVzZXJfc2VsZWN0ZWRfd2hhdCBzZWxlY3Rp b24pDQo+ICAgICAgfQ0KPiAgfQ0KPiANCj4gLXN0YXRpYyBpbnQNCj4gLXJl cG9ydF9pbml0aWFsX2luZmVyaW9yIChzdHJ1Y3QgaW5mZXJpb3IgKmluZiwg dm9pZCAqY2xvc3VyZSkNCj4gLXsNCj4gLSAgLyogVGhpcyBmdW5jdGlvbiBp cyBjYWxsZWQgZnJvbSBtaV9pbnRlcnByZXRlcl9pbml0LCBhbmQgc2luY2UN Cj4gLSAgICAgbWlfaW5mZXJpb3JfYWRkZWQgYXNzdW1lcyB0aGF0IGluZmVy aW9yIGlzIGZ1bGx5IGluaXRpYWxpemVkDQo+IC0gICAgIGFuZCB0b3BfbGV2 ZWxfaW50ZXJwcmV0ZXJfZGF0YSBpcyBzZXQsIHdlIGNhbm5vdCBjYWxsDQo+ IC0gICAgIGl0IGhlcmUuICAqLw0KPiAtICBzdHJ1Y3QgbWlfaW50ZXJwICpt aSA9IChzdHJ1Y3QgbWlfaW50ZXJwICopIGNsb3N1cmU7DQo+IC0NCj4gLSAg dGFyZ2V0X3Rlcm1pbmFsOjpzY29wZWRfcmVzdG9yZV90ZXJtaW5hbF9zdGF0 ZSB0ZXJtX3N0YXRlOw0KPiAtICB0YXJnZXRfdGVybWluYWw6Om91cnNfZm9y X291dHB1dCAoKTsNCj4gLQ0KPiAtICBmcHJpbnRmX3VuZmlsdGVyZWQgKG1p LT5ldmVudF9jaGFubmVsLA0KPiAtCQkgICAgICAidGhyZWFkLWdyb3VwLWFk ZGVkLGlkPVwiaSVkXCIiLA0KPiAtCQkgICAgICBpbmYtPm51bSk7DQo+IC0g IGdkYl9mbHVzaCAobWktPmV2ZW50X2NoYW5uZWwpOw0KPiAtDQo+IC0gIHJl dHVybiAwOw0KPiAtfQ0KPiAtDQo+ICB1aV9vdXQgKg0KPiAgbWlfaW50ZXJw OjppbnRlcnBfdWlfb3V0ICgpDQo+ICB7DQo+IC0tDQo+IDIuMjUuMA0KDQpJ bnRlbCBEZXV0c2NobGFuZCBHbWJIClJlZ2lzdGVyZWQgQWRkcmVzczogQW0g Q2FtcGVvbiAxMC0xMiwgODU1NzkgTmV1YmliZXJnLCBHZXJtYW55ClRlbDog KzQ5IDg5IDk5IDg4NTMtMCwgd3d3LmludGVsLmRlCk1hbmFnaW5nIERpcmVj dG9yczogQ2hyaXN0aW4gRWlzZW5zY2htaWQsIEdhcnkgS2Vyc2hhdwpDaGFp cnBlcnNvbiBvZiB0aGUgU3VwZXJ2aXNvcnkgQm9hcmQ6IE5pY29sZSBMYXUK UmVnaXN0ZXJlZCBPZmZpY2U6IE11bmljaApDb21tZXJjaWFsIFJlZ2lzdGVy OiBBbXRzZ2VyaWNodCBNdWVuY2hlbiBIUkIgMTg2OTI4Cg== >From gdb-patches-return-163133-listarch-gdb-patches=sources.redhat.com@sourceware.org Thu Jan 16 11:29:59 2020 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 14640 invoked by alias); 16 Jan 2020 11:29:58 -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 14627 invoked by uid 89); 16 Jan 2020 11:29:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=officially, H*RU:sk:sonic31, H*r:sk:sonic31, HX-HELO:sk:sonic31 X-HELO: sonic313-20.consmr.mail.ir2.yahoo.com Received: from sonic313-20.consmr.mail.ir2.yahoo.com (HELO sonic313-20.consmr.mail.ir2.yahoo.com) (77.238.179.187) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jan 2020 11:29:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1579174185; bh=NZg6cd13bAuRee1VGXe7FWZlrKo/coKBdPEbgQQy56g=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=ZmEz71aAHhVhbZyTqPxi1id8X/pDe2lEahSGS8xDPi2Tf1z9wGS+neKc+Vi2f6CIhaRE+SpPl8riKKoeToWxEZ0nnLVLR+flNcoDSswBpQIUx9B9v1HDOmncYslyCsSCTz2tPJZF6Offd4rB6Frgmk7jJt4DRy60DVdTRbEKKrS7hMAdzR3hz6cKklhLn5SpP5epo+szerFCJritmhzdWxrZ7gjjGQw8XhZeFUbOLWsmZ6ktQg5hX9h4IhJWjpaw4igf4d//YCIQvvGTP5cgMB7GTluBvgq9mCUlVKL+8rhB4/KiTd0733jXThtdZFb/zSKgW04f+Pgj2Pd8R4rpnA== Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ir2.yahoo.com with HTTP; Thu, 16 Jan 2020 11:29:45 +0000 Date: Thu, 16 Jan 2020 14:15:00 -0000 From: "Hannes Domani via gdb-patches" Reply-To: Hannes Domani To: Gdb-patches Message-ID: <1420079655.20725083.1579174183583@mail.yahoo.com> In-Reply-To: References: <20191223161009.7633-1-ssbssa.ref@yahoo.de> <20191223161009.7633-1-ssbssa@yahoo.de> Subject: Re: [PATCH] Add type for $_tlb->process_environment_block->process_parameters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-length: 8062 X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00447.txt.bz2 Am Mittwoch, 15. Januar 2020, 22:27:40 MEZ hat Simon Marchi Folgendes geschrieben: > I was hoping that our Windows specialist would review this :), but I'll > give it a look. > > On 2019-12-23 11:10 a.m., Hannes Domani via gdb-patches wrote: > > The type then looks like this: > > > > (gdb) pt $_tlb->process_environment_block->process_parameters > > type =3D struct rtl_user_process_parameters { > >=C2=A0=C2=A0=C2=A0 DWORD32 maximum_length; > >=C2=A0=C2=A0=C2=A0 DWORD32 length; > >=C2=A0=C2=A0=C2=A0 DWORD32 flags; > >=C2=A0=C2=A0=C2=A0 DWORD32 debug_flags; > >=C2=A0=C2=A0=C2=A0 void *console_handle; > >=C2=A0=C2=A0=C2=A0 DWORD32 console_flags; > >=C2=A0=C2=A0=C2=A0 void *standard_input; > >=C2=A0=C2=A0=C2=A0 void *standard_output; > >=C2=A0=C2=A0=C2=A0 void *standard_error; > >=C2=A0=C2=A0=C2=A0 unicode_string current_directory; > >=C2=A0=C2=A0=C2=A0 void *current_directory_handle; > >=C2=A0=C2=A0=C2=A0 unicode_string dll_path; > >=C2=A0=C2=A0=C2=A0 unicode_string image_path_name; > >=C2=A0=C2=A0=C2=A0 unicode_string command_line; > >=C2=A0=C2=A0=C2=A0 void *environment; > >=C2=A0=C2=A0=C2=A0 DWORD32 starting_x; > >=C2=A0=C2=A0=C2=A0 DWORD32 starting_y; > >=C2=A0=C2=A0=C2=A0 DWORD32 count_x; > >=C2=A0=C2=A0=C2=A0 DWORD32 count_y; > >=C2=A0=C2=A0=C2=A0 DWORD32 count_chars_x; > >=C2=A0=C2=A0=C2=A0 DWORD32 count_chars_y; > >=C2=A0=C2=A0=C2=A0 DWORD32 fill_attribute; > >=C2=A0=C2=A0=C2=A0 DWORD32 window_flags; > >=C2=A0=C2=A0=C2=A0 DWORD32 show_window_flags; > >=C2=A0=C2=A0=C2=A0 unicode_string window_title; > >=C2=A0=C2=A0=C2=A0 unicode_string desktop_info; > >=C2=A0=C2=A0=C2=A0 unicode_string shell_info; > >=C2=A0=C2=A0=C2=A0 unicode_string runtime_data; > > } * > > > > It's mainly useful to get the current directory, or the full command li= ne: > > > > (gdb) p $_tlb->process_environment_block->process_parameters->current_d= irectory > > $1 =3D { > >=C2=A0 length =3D 26, > >=C2=A0 maximum_length =3D 520, > >=C2=A0 buffer =3D 0xe36c8 L"C:\\src\\tests\\" > > } > > (gdb) p $_tlb->process_environment_block->process_parameters->command_l= ine > > $2 =3D { > >=C2=A0 length =3D 94, > >=C2=A0 maximum_length =3D 96, > >=C2=A0 buffer =3D 0xe32aa L"\"C:\\gdb\\build64\\gdb-git\\gdb\\gdb.exe\" = access.exe" > > } > > Could you add links in the commit message to the relevant documentation t= hat describes these types? > > I am guessing this, for example: > > https://docs.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_unicod= e_string Yes, that's the one. But for rtl_user_process_parameters only very little is officially document= ed: https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-rtl= _user_process_parameters So I used this instead: https://www.nirsoft.net/kernel_struct/vista/RTL_USER_PROCESS_PARAMETERS.html Should I use that for the commit message? > > > > > gdb/ChangeLog: > > > > 2019-12-23=C2=A0 Hannes Domani=C2=A0 > > > >=C2=A0=C2=A0=C2=A0=C2=A0 * windows-tdep.c (windows_get_tlb_type): > >=C2=A0=C2=A0=C2=A0=C2=A0 Add rtl_user_process_parameters type. > > --- > >=C2=A0 gdb/windows-tdep.c | 65 +++++++++++++++++++++++++++++++++++++++++= ++++- > >=C2=A0 1 file changed, 64 insertions(+), 1 deletion(-) > > > > diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c > > index bb69a79996..83a80f2f80 100644 > > --- a/gdb/windows-tdep.c > > +++ b/gdb/windows-tdep.c > > @@ -114,6 +114,8 @@ windows_get_tlb_type (struct gdbarch *gdbarch) > >=C2=A0=C2=A0=C2=A0 struct type *peb_type, *peb_ptr_type, *list_type; > >=C2=A0=C2=A0=C2=A0 struct type *module_list_ptr_type; > >=C2=A0=C2=A0=C2=A0 struct type *tib_type, *seh_type, *tib_ptr_type, *seh= _ptr_type; > > +=C2=A0 struct type *word_type, *wchar_type, *wchar_ptr_type; > > +=C2=A0 struct type *uni_str_type, *rupp_type, *rupp_ptr_type; > > > >=C2=A0=C2=A0=C2=A0 /* Do not rebuild type if same gdbarch as last time.= =C2=A0 */ > >=C2=A0=C2=A0=C2=A0 if (last_tlb_type && last_gdbarch =3D=3D gdbarch) > > @@ -123,7 +125,15 @@ windows_get_tlb_type (struct gdbarch *gdbarch) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1, "DWORD_PTR"); > >=C2=A0=C2=A0=C2=A0 dword32_type =3D arch_integer_type (gdbarch, 32, > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1, "DWORD32"); > > +=C2=A0 word_type =3D arch_integer_type (gdbarch, 16, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 1, "WORD"); > > +=C2=A0 wchar_type =3D arch_integer_type (gdbarch, 16, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1, "wchar_t"); > >=C2=A0=C2=A0=C2=A0 void_ptr_type =3D lookup_pointer_type (builtin_type (= gdbarch)->builtin_void); > > +=C2=A0 wchar_ptr_type =3D arch_type (gdbarch, TYPE_CODE_PTR, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TYPE_LENGTH (void_ptr_type) * TARGET_CHAR= _BIT, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NULL); > > +=C2=A0 TYPE_TARGET_TYPE (wchar_ptr_type) =3D wchar_type; > > Could you use arch_pointer_type instead of setting the TYPE_TARGET_TYPE b= y hand? I will try that. > > This function (windows_get_tlb_type) appears to be called everytime the $= _tlb variable > is used.=C2=A0 The arch_*_type functions allocate new types every time.= =C2=A0 This would mean > that new types are allocate every time $_tlb is used.=C2=A0 Am I reading = this right? > > If so, it's a problem that predates your patch.=C2=A0 But I think the rig= ht way of doing this > would be to create the types when the gdbarch is created, store them in t= he > gdbarch_tdep structure, and use them here. Actually, this is at the top of windows_get_tlb_type: =C2=A0 /* Do not rebuild type if same gdbarch as last time.=C2=A0 */ =C2=A0 if (last_tlb_type && last_gdbarch =3D=3D gdbarch) =C2=A0=C2=A0=C2=A0 return last_tlb_type; > > > > >=C2=A0=C2=A0=C2=A0 /* list entry */ > > > > @@ -168,6 +178,59 @@ windows_get_tlb_type (struct gdbarch *gdbarch) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NULL); > >=C2=A0=C2=A0=C2=A0 TYPE_TARGET_TYPE (peb_ldr_ptr_type) =3D peb_ldr_type; > > > > +=C2=A0 /* struct UNICODE_STRING */ > > +=C2=A0 uni_str_type =3D arch_composite_type (gdbarch, NULL, TYPE_CODE_= STRUCT); > > +=C2=A0 TYPE_NAME (uni_str_type) =3D xstrdup ("unicode_string"); > > + > > +=C2=A0 append_composite_type_field (uni_str_type, "length", word_type); > > +=C2=A0 append_composite_type_field (uni_str_type, "maximum_length", wo= rd_type); > > +=C2=A0 append_composite_type_field_aligned (uni_str_type, "buffer", > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wchar_ptr_type, > > The actual name in the Windows API UNICODE_STRING (in capital letters), a= nd > the fields are in camel case, such as "MaximumLength".=C2=A0 Logically, I= would > expect GDB to name the types and fields the same way. > > However, I see that the existing types created by this function (that pre= date > your patch) don't do this.=C2=A0 Do you have any idea why it was done lik= e that? > > I suppose it's better to continue using the same format as the existing t= ypes > (as you did), but still I find this odd. I actually wondered about this myself, but I also just used the existing fo= rmat. > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TYPE_LENGTH (wcha= r_ptr_type)); > > + > > +=C2=A0 /* struct _RTL_USER_PROCESS_PARAMETERS */ > > +=C2=A0 rupp_type =3D arch_composite_type (gdbarch, NULL, TYPE_CODE_STR= UCT); > > +=C2=A0 TYPE_NAME (rupp_type) =3D xstrdup ("rtl_user_process_parameters= "); > > > Couldn't you pass the name directly to arch_composite_type? I will try that as well. Regards Hannes Domani