The search_simple_memory function in gdb/target.c has an error that leads to incorrect reporting of found patterns. The problem occurs only when the search space length is larger than the chunk size. I believe the cause is a simple mixup of variables. I think the following change should fix it. --- orig/gdb-7.0/gdb/target.c 2009-09-16 02:16:40.000000000 +1000 +++ fixed/gdb-7.0/gdb/target.c 2009-10-16 02:10:35.000000000 +1100 @@ -2302,7 +2302,7 @@ simple_search_memory (struct target_ops 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; int nr_to_read; /* Copy the trailing part of the previous iteration to the front
Thanks. Pasting here the example you showed on IRC: (gdb) find /b 0xcaa6000, 0x0caa7000, 'B', 'u', 'r', 'n', 'e', 'r' 0xcaa6324 <--- this one is correct 1 pattern found. (gdb) find /b 0xbaa6000, 0x0caa7000, 'B', 'u', 'r', 'n', 'e', 'r' ^^^^^^^^^--- lowered the start address 0xc9197d2 \ 0xc91985c \_ no mention of 0xcaa6324 anymore ): 0xc91993c / 0xca98fac / 4 patterns found.
Subject: Bug 10783 CVSROOT: /cvs/src Module name: src Changes by: sandra@sourceware.org 2009-10-29 20:12:26 Modified files: gdb : ChangeLog target.c gdb/gdbserver : ChangeLog server.c Log message: 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. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.11014&r2=1.11015 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/target.c.diff?cvsroot=src&r1=1.230&r2=1.231 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/gdbserver/ChangeLog.diff?cvsroot=src&r1=1.294&r2=1.295 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/gdbserver/server.c.diff?cvsroot=src&r1=1.103&r2=1.104
I've checked in the patch attached to this message. As noted, the bug was also present in the target-side gdbserver logic. http://sourceware.org/ml/gdb-patches/2009-10/msg00691.html