From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106646 invoked by alias); 26 Jun 2018 18:49: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 106605 invoked by uid 89); 26 Jun 2018 18:49:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=U*palves, sk:palves, sk:palves@, palvesredhatcom X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 18:49:03 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5QImkiq142521 for ; Tue, 26 Jun 2018 14:49:01 -0400 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by mx0b-001b2d01.pphosted.com with ESMTP id 2juts1gps8-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 26 Jun 2018 14:49:01 -0400 Received: from localhost by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Jun 2018 12:49:00 -0600 Received: from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 26 Jun 2018 12:48:58 -0600 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w5QImthl10223954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 26 Jun 2018 11:48:55 -0700 Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B25BEBE053; Tue, 26 Jun 2018 12:48:55 -0600 (MDT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7E03DBE04F; Tue, 26 Jun 2018 12:48:55 -0600 (MDT) Received: from pedro.localdomain (unknown [9.18.235.82]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 26 Jun 2018 12:48:55 -0600 (MDT) Received: by pedro.localdomain (Postfix, from userid 1000) id EFC003C03A8; Tue, 26 Jun 2018 15:48:52 -0300 (-03) From: Pedro Franco de Carvalho To: Pedro Alves , Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/4] Use get_remote_packet_size in download_tracepoint In-Reply-To: <925c0f76-f54c-0f7a-49a1-46ea365dc84a@redhat.com> References: <20180625103720.2F6DAD801CC@oc3748833570.ibm.com> <878t72mvxo.fsf@linux.vnet.ibm.com> <925c0f76-f54c-0f7a-49a1-46ea365dc84a@redhat.com> Date: Tue, 26 Jun 2018 18:49:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 18062618-8235-0000-0000-00000DC8C60B X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009259; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000266; SDB=6.01052702; UDB=6.00539689; IPR=6.00830626; MB=3.00021866; MTD=3.00000008; XFM=3.00000015; UTC=2018-06-26 18:48:59 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18062618-8236-0000-0000-000041AA3115 Message-Id: <87o9fxbcyz.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00621.txt.bz2 Pedro Alves writes: > I'm not sure I understand the details or the suggestions below (the > patches don't seem to be meant to apply on top of current master, but > they're using buf.data()), but I'd just like to point out that ideally > GDB should not gdb_assert or abort on user input or remote stub > limitations (small remote packet size), since neither are a GDB bug. Sorry, I messed up the formatting. I used the assert because other places in remote.c also use xsnprintf with the remote packet size and so fail with an assert if this size is too small. But I agree that it makes more sense not to abort, so I can change all uses of xsnprintf in remote_target::download_tracepoint to snprintf and raise an error if the return value indicates the packet size is too small. >> I am also assuming throughout this function that size_t and >> gdb::char_vector::size_type are compatible (since buf.size () returns >> the latter and xsnprintf takes a size_t). Is this ok? > > It is. Thanks! -- Pedro Franco de Carvalho