From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95210 invoked by alias); 6 Mar 2017 16:01:13 -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 95185 invoked by uid 89); 6 Mar 2017 16:01:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-8.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,UNSUBSCRIBE_BODY autolearn=ham version=3.3.2 spammy=transfers, Hx-languages-length:1885, arnez, Arnez X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Mar 2017 16:01:10 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v26Frtv3101405 for ; Mon, 6 Mar 2017 11:01:10 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2918g6fgbd-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 06 Mar 2017 11:01:09 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 6 Mar 2017 16:01:05 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 6 Mar 2017 16:01:02 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 59D0017D805F for ; Mon, 6 Mar 2017 16:04:17 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v26G11Fj33620014 for ; Mon, 6 Mar 2017 16:01:01 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3E41F42045 for ; Mon, 6 Mar 2017 16:00:55 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2DEF24205E for ; Mon, 6 Mar 2017 16:00:55 +0000 (GMT) Received: from oc1027705133.ibm.com (unknown [9.152.212.222]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP for ; Mon, 6 Mar 2017 16:00:55 +0000 (GMT) From: Andreas Arnez To: gdb-patches@sourceware.org Subject: [PATCH 0/3] PR gdb/21220: Fix quadratic runtime of memory writes into inferior on GNU/Linux Date: Mon, 06 Mar 2017 16:01:00 -0000 X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17030616-0020-0000-0000-00000281B28D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17030616-0021-0000-0000-00001F9E4010 Message-Id: <1488816060-20776-1-git-send-email-arnez@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-06_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703060134 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00042.txt.bz2 On GNU/Linux native targets, when writing into inferior memory, only a single word is currently transferred at a time. This causes trouble with large transfers, because memory_xfer_partial wastes a lot of effort in this case: allocate a buffer and copy all remaining bytes of the transfer request into it, then fill the breakpoints in, but just transfer the first word of this buffer, and drop the rest. This quadratic behavior affects large "restore" operations, as reported by PR 21220, as well as reverse-stepping a large memory-copy instruction, such as in the s390-specific test case s390-mvcle.exp. The quadratic run-time of a large restore operation was already addressed and circumvented by this patch: https://sourceware.org/ml/gdb-patches/2013-07/msg00611.html -- "Improve performance of large restore commands" But then another patch broke the circumvention: https://sourceware.org/ml/gdb-patches/2016-06/msg00565.html -- "Optimize memory_xfer_partial for remote" This series fixes the problem in two different ways: * When using ptrace with PTRACE_POKEDATA, do not return to the caller after transferring a single word, but attempt to fulfill the whole transfer request in one invocation. * If possible, do not even use PTRACE_POKEDATA, but write to /proc//mem instead. To avoid another regression, a new dump/restore test case is added as well. Andreas Arnez (3): inf-ptrace: Do not stop memory transfers after a single word Test case for dump/restore of large array linux-nat: Exploit /proc//mem for writing gdb/inf-ptrace.c | 115 ++++++++++++++++++---------------------- gdb/linux-nat.c | 32 +++++------ gdb/testsuite/gdb.base/dump.c | 37 +++++++++++++ gdb/testsuite/gdb.base/dump.exp | 8 +++ 4 files changed, 112 insertions(+), 80 deletions(-) -- 2.3.0