From: Sandra Loosemore <sandra@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Chris Mears <chris@cmears.id.au>, Pedro Alves <pedro@codesourcery.com>
Subject: PATCH: fix PR gdb/10783
Date: Thu, 29 Oct 2009 18:27:00 -0000 [thread overview]
Message-ID: <4AE9DE8A.8080905@codesourcery.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
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 <sandra@codesourcery.com>
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.
[-- Attachment #2: gdb.patch --]
[-- Type: text/x-patch, Size: 1231 bytes --]
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
next reply other threads:[~2009-10-29 18:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 18:27 Sandra Loosemore [this message]
2009-10-29 19:15 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE9DE8A.8080905@codesourcery.com \
--to=sandra@codesourcery.com \
--cc=chris@cmears.id.au \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox