From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26123 invoked by alias); 1 Jul 2013 15:32:07 -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 26112 invoked by uid 89); 1 Jul 2013 15:32:06 -0000 X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MIME_BASE64_BLANKS,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 01 Jul 2013 15:32:05 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 01 Jul 2013 08:31:42 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by azsmga001.ch.intel.com with ESMTP; 01 Jul 2013 08:26:15 -0700 Received: from irsmsx153.ger.corp.intel.com (163.33.192.75) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Jul 2013 16:24:59 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.52]) by IRSMSX153.ger.corp.intel.com ([169.254.9.147]) with mapi id 14.03.0123.003; Mon, 1 Jul 2013 16:24:59 +0100 From: "Agovic, Sanimir" To: Chris January CC: "gdb@sourceware.org" , "Boell, Keven" Subject: RE: Variable Length Arrays (VLA) proposal Date: Mon, 01 Jul 2013 15:32:00 -0000 Message-ID: <0377C58828D86C4588AEEC42FC3B85A717629428@IRSMSX105.ger.corp.intel.com> References: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> <1372434039.2950.12.camel@gumtree> In-Reply-To: <1372434039.2950.12.camel@gumtree> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 X-SW-Source: 2013-07/txt/msg00002.txt.bz2 SGVsbG8gQ2hyaXMsDQoNCj4gSnVzdCB0byBhZGQgYW5vdGhlciBwb3NzaWJp bGl0eSwgd2UgaW1wbGVtZW50ZWQgVkxBIGZvciBGb3J0cmFuIGJ5DQo+IHdy YXBwaW5nIHJlYWRfdmFyX3ZhbHVlIGFuZCB0aGVuIGFkZGluZyBhIGNhbGwg dG8gZl9maXh1cF92YWx1ZSB3aGljaA0KPiAnZml4ZWQgdXAnIHRoZSB0eXBl IG9mIHRoZSB2YXJpYWJsZSAoZmlsbGVkIGluIHRoZSBhcnJheSBib3VuZHMs IGV0Yy4pDQo+IGJ5IG1vZGlmeWluZyB0aGUgb3JpZ2luYWwgdHlwZS4gKEl0 IGFsc28gYXV0by1kZXJlZmVyZW5jZXMgcG9pbnRlcnMpLg0KPiANCkludGVy ZXN0aW5nIGFwcHJvYWNoICYgdGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLg0K DQpXZSBhcmUgZ29pbmcgdG8gYWRkIHlvdXIgcHJvcG9zYWwgdG8gaHR0cDov L3NvdXJjZXdhcmUub3JnL2dkYi93aWtpL0ZvcnRyYW5WTEEuIA0KVGhpcyBh bGxvd3MgdXMgdG8gdHJhY2sgdGhlIHZhcmlvdXMgYXBwcm9hY2hlcyBpbiBh IGJldHRlciB3YXkuDQpNYXliZSB3ZSBzaG91bGQgZHJvcCB0aGUgRm9ydHJh biBwcmVmaXggYXMgd2UgYXJlIGFpbWluZyBmb3IgZ2VuZXJpYyB2bGENCnN1 cHBvcnQgaW4gRlNGIEdEQi4NCg0KIC1TYW5pbWlyDQoNCkludGVsIEdtYkgK RG9ybmFjaGVyIFN0cmFzc2UgMQo4NTYyMiBGZWxka2lyY2hlbi9NdWVuY2hl biwgRGV1dHNjaGxhbmQKU2l0eiBkZXIgR2VzZWxsc2NoYWZ0OiBGZWxka2ly Y2hlbiBiZWkgTXVlbmNoZW4KR2VzY2hhZWZ0c2Z1ZWhyZXI6IENocmlzdGlh biBMYW1wcmVjaHRlciwgSGFubmVzIFNjaHdhZGVyZXIsIERvdWdsYXMgTHVz awpSZWdpc3RlcmdlcmljaHQ6IE11ZW5jaGVuIEhSQiA0NzQ1NgpVc3QuLUlk TnIuL1ZBVCBSZWdpc3RyYXRpb24gTm8uOiBERTEyOTM4NTg5NQpDaXRpYmFu ayBGcmFua2Z1cnQgYS5NLiAoQkxaIDUwMiAxMDkgMDApIDYwMDExOTA1Mgo= >From gdb-return-42303-listarch-gdb=sources.redhat.com@sourceware.org Mon Jul 01 15:32:08 2013 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 26163 invoked by alias); 1 Jul 2013 15:32:07 -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 26129 invoked by uid 89); 1 Jul 2013 15:32:07 -0000 X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MIME_BASE64_BLANKS,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 01 Jul 2013 15:32:07 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 01 Jul 2013 08:31:42 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by azsmga001.ch.intel.com with ESMTP; 01 Jul 2013 08:29:19 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.52]) by IRSMSX104.ger.corp.intel.com ([169.254.5.127]) with mapi id 14.03.0123.003; Mon, 1 Jul 2013 16:29:19 +0100 From: "Agovic, Sanimir" To: Chris January , Joel Brobecker CC: "gdb@sourceware.org" , "Boell, Keven" Subject: RE: Variable Length Arrays (VLA) proposal Date: Mon, 01 Jul 2013 15:32:00 -0000 Message-ID: <0377C58828D86C4588AEEC42FC3B85A71762943C@IRSMSX105.ger.corp.intel.com> References: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> <1372434039.2950.12.camel@gumtree> <20130701015453.GB10319@adacore.com> <1372665705.3234.3.camel@gumtree> In-Reply-To: <1372665705.3234.3.camel@gumtree> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 X-SW-Source: 2013-07/txt/msg00003.txt.bz2 Content-length: 1212 SGVsbG8gQ2hyaXMsDQoNCj4gRG8geW91IG1lYW4gaW4gdGhpcyBzY2VuYXJp byAoZXhjdXNlIHRoZSBtaXhlZCBGb3J0cmFuIC8gR0RCIGNvbW1hbmRzKT8N Cj4gDQo+IEFMTE9DQVRFKGFycmF5KDEwLCAxMCkpDQo+IChnZGIpIHByaW50 IGFycmF5DQo+ICQxID0gKC4uLikNCj4gREVBTExPQ0FURShhcnJheSkNCj4g QUxMT0NBVEUoYXJyYXkoMjAsMjApKQ0KPiAoZ2RiKSBwcmludCAkMQ0KPiAN Cj4gVGhlbiBubywgbW9kaWZ5aW5nIHRoZSBvcmlnaW5hbCB0eXBlIGRvZXMg bm90IHdvcmsgaW4gdGhhdCBjYXNlIChpdA0KPiBicmVha3MgJDEgYXMgeW91 IHNheSkuDQoNCkFmYWlrIHRoZSBoaXN0b3J5ICgkbikgaXMgc2ltcGx5IGEg c25hcHNob3Qgb2YgdGhlIHByaW50ZWQgdmFsdWUuIFRodXMgDQptb2RpZnlp bmcgdGhlIHR5cGUgaW4gcGxhY2UgY2hhbmdlcyB0aGUgc2VtYW50aWMgb2Yg dGhlIGhpc3RvcnkuDQpOb3Qgc3VyZSB3aGF0IGhhcHBlbnMgaWYgdGhlIGlu ZmVyaW9yIGNoYW5nZXMgb3Igb25lIHVubG9hZHMgZGVidWcgDQppbmZvcm1h dGlvbiB0aG91Z2guDQoNCiAtU2FuaW1pcg0KSW50ZWwgR21iSApEb3JuYWNo ZXIgU3RyYXNzZSAxCjg1NjIyIEZlbGRraXJjaGVuL011ZW5jaGVuLCBEZXV0 c2NobGFuZApTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IEZlbGRraXJjaGVuIGJl aSBNdWVuY2hlbgpHZXNjaGFlZnRzZnVlaHJlcjogQ2hyaXN0aWFuIExhbXBy ZWNodGVyLCBIYW5uZXMgU2Nod2FkZXJlciwgRG91Z2xhcyBMdXNrClJlZ2lz dGVyZ2VyaWNodDogTXVlbmNoZW4gSFJCIDQ3NDU2ClVzdC4tSWROci4vVkFU IFJlZ2lzdHJhdGlvbiBOby46IERFMTI5Mzg1ODk1CkNpdGliYW5rIEZyYW5r ZnVydCBhLk0uIChCTFogNTAyIDEwOSAwMCkgNjAwMTE5MDUyCg== >From gdb-return-42304-listarch-gdb=sources.redhat.com@sourceware.org Tue Jul 02 08:44:35 2013 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 16091 invoked by alias); 2 Jul 2013 08:44:35 -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 16071 invoked by uid 89); 2 Jul 2013 08:44:31 -0000 X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,LOTS_OF_MONEY,RP_MATCHES_RCVD autolearn=no version=3.3.1 Received: from vigilia.groessler.org (HELO vigilia.groessler.org) (178.63.177.85) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 02 Jul 2013 08:44:31 +0000 Received: from [10.23.1.38] (gaga.groessler.org [212.168.189.235]) by vigilia.groessler.org (8.14.6/8.14.6) with ESMTP id r628kt3O027884 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Tue, 2 Jul 2013 10:46:56 +0200 (CEST) Message-ID: <51D292E7.9040900@groessler.org> Date: Tue, 02 Jul 2013 08:44:00 -0000 From: Christian Groessler User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130701 Icedove/17.0.7 MIME-Version: 1.0 To: gdb@sourceware.org Subject: remote packet size for memory read References: <51D29213.2050801@groessler.org> In-Reply-To: <51D29213.2050801@groessler.org> X-Forwarded-Message-Id: <51D29213.2050801@groessler.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-07/txt/msg00004.txt.bz2 Content-length: 2428 Hi, our remote stub reports a maximum transfer size of 0x1ff: Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack Packet received: PacketSize=1ff I have the following definitions in my program: char mystring253[253] = "253 byte string"; char mystring254[254] = "254 byte string"; Now when I try to print them, I get (gdb) p mystring253 Sending packet: $m201574c,fd#f9...Ack Packet received: 323533206279746520737472696e6700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 $1 = "253 byte string", '\000' (gdb) p mystring254 Sending packet: $m2015849,fe#d1...Ack Packet received: E01 Cannot access memory at address 0x2015849 (gdb) For mystring254 gdb requested 254 data bytes, which, together with the frame bytes, would exceed the 0x1ff maximum packet size. The documentation for "PacketSize" says ‘PacketSize=bytes’ The remote stub can accept packets up to at least bytes in length. gdb will send packets up to this size for bulk transfers, and will never send larger packets. This is a limit on the data characters in the packet, including the frame and checksum. There is no trailing NUL byte in a remote protocol packet; if the stub stores packets in a NUL-terminated format, it should allow an extra byte in its buffer for the NUL. If this stub feature is not supported, gdb guesses based on the size of the ‘g’ packet response. I looked at remote.c and for read packets the frame bytes aren't accounted for. It looks like gdb will request (PacketSize/2) bytes from the stub, and the stub should send as much as it can (since we have a 0x1ff bytes transfer buffer, this would be ((PacketSize - 4)/2). Correct? And I think there is a potential problem when parsing the returned data. remote_read_bytes(remote.c) depends on hex2bin returning the received length if it encounters a 0 byte. But as far as I could follow, the receive buffer was only xmalloc'ed and not zero initialized. regards, chris