From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21803 invoked by alias); 29 Oct 2009 18:27:27 -0000 Received: (qmail 21783 invoked by uid 22791); 29 Oct 2009 18:27:25 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Oct 2009 18:27:21 +0000 Received: (qmail 23477 invoked from network); 29 Oct 2009 18:27:20 -0000 Received: from unknown (HELO ?192.168.2.2?) (sandra@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Oct 2009 18:27:20 -0000 Message-ID: <4AE9DE8A.8080905@codesourcery.com> Date: Thu, 29 Oct 2009 18:27:00 -0000 From: Sandra Loosemore User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: gdb-patches@sourceware.org CC: Chris Mears , Pedro Alves Subject: PATCH: fix PR gdb/10783 Content-Type: multipart/mixed; boundary="------------010901010104080706010809" 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 X-SW-Source: 2009-10/txt/msg00691.txt.bz2 This is a multi-part message in MIME format. --------------010901010104080706010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1129 We had a customer bug report that the GDB find command was not correctly finding things given a large search range. This was using gdbserver on an arm-none-linux-gnueabi target. I independently tracked this down to the same problem reported in PR 10783 -- it affects the target-side gdbserver search code as well as the server-side simple_search_memory function. The attached patch fixes both places. Note that the version of the patch attached to the issue also didn't correctly handle the keep_len != 0 case (e.g., find/w instead of find/b). I tested this with the arm-none-linux-gnueabi gdbserver case using lots of different combinations of search ranges to verify that it was correctly finding and reporting the match no matter what the offset within the range. OK to check in? -Sandra 2009-10-29 Sandra Loosemore PR gdb/10783 gdb/ * target.c (simple_search_memory): Correct read_addr initialization in loop for searching subsequent chunks. gdb/gdbserver/ * server.c (handle_search_memory_1): Correct read_addr initialization in loop for searching subsequent chunks. --------------010901010104080706010809 Content-Type: text/x-patch; name="gdb.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb.patch" Content-length: 1231 Index: gdb/target.c =================================================================== RCS file: /cvs/src/src/gdb/target.c,v retrieving revision 1.230 diff -u -r1.230 target.c --- gdb/target.c 26 Oct 2009 18:28:13 -0000 1.230 +++ gdb/target.c 29 Oct 2009 17:58:39 -0000 @@ -2305,7 +2305,7 @@ if (search_space_len >= pattern_len) { unsigned keep_len = search_buf_size - chunk_size; - CORE_ADDR read_addr = start_addr + keep_len; + CORE_ADDR read_addr = start_addr + chunk_size + keep_len; int nr_to_read; /* Copy the trailing part of the previous iteration to the front Index: gdb/gdbserver/server.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/server.c,v retrieving revision 1.103 diff -u -r1.103 server.c --- gdb/gdbserver/server.c 9 Oct 2009 00:31:01 -0000 1.103 +++ gdb/gdbserver/server.c 29 Oct 2009 17:58:39 -0000 @@ -557,7 +557,7 @@ if (search_space_len >= pattern_len) { unsigned keep_len = search_buf_size - chunk_size; - CORE_ADDR read_addr = start_addr + keep_len; + CORE_ADDR read_addr = start_addr + chunk_size + keep_len; int nr_to_read; /* Copy the trailing part of the previous iteration to the front --------------010901010104080706010809--