]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commitdiff
Local changes to take full advantage of qPacketInfo
authorDaniel Jacobowitz <drow@false.org>
Fri, 31 Mar 2006 18:17:29 +0000 (18:17 +0000)
committerDaniel Jacobowitz <drow@false.org>
Fri, 31 Mar 2006 18:17:29 +0000 (18:17 +0000)
gdb/symfile.c
gdb/target.c

index 59cd3dc75952e93490d2de5460d8f2303a600673..a4c883be12ffed4d6f37303c7f6e0da3528ba224 100644 (file)
@@ -1516,7 +1516,10 @@ load_command (char *arg, int from_tty)
    we don't want to run a subprocess.  On the other hand, I'm not sure how
    performance compares.  */
 
-static int download_write_size = 512;
+/* FIXME drow/2006-03-30: This used to be 512.  The remote target will
+   throttle it if it's too large; is there any use in having a small
+   value here?  */
+static int download_write_size = 16384;
 static void
 show_download_write_size (struct ui_file *file, int from_tty,
                          struct cmd_list_element *c, const char *value)
index 80b7b7111429825a1d497e0c0cb2b65c11de6a33..1d4e035dc7b6f583a6b417d5c84b604ba7f02772 100644 (file)
@@ -1420,7 +1420,9 @@ target_read_whole (struct target_ops *ops,
                   enum target_object object,
                   const char *annex, gdb_byte **buf_p)
 {
-  size_t buf_alloc = 512, buf_pos = 0;
+  /* FIXME: Should we use the memory write size parameters for this
+     too?  Or something at another level entirely?  */
+  size_t buf_alloc = 32768, buf_pos = 0;
   gdb_byte *buf = xmalloc (buf_alloc);
   LONGEST n, total;