Commit: 4bce40dca8e4fc700f468fa8d07be73910b4719d - binutils_os216 (git)

GNU Binutils with patches for OS216

Commit MetaInfo

• Révision: 4bce40dca8e4fc700f468fa8d07be73910b4719d (tree)
• l'heure: 2006-04-01 03:17:29
• Auteur: Daniel Jacobowitz <drow@fals...>
• Commiter: Daniel Jacobowitz

Message de Log

Local changes to take full advantage of qPacketInfo

Change Summary

• modified: gdb/symfile.c
• modified: gdb/target.c

Modification

--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -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)

--- a/gdb/target.c
+++ b/gdb/target.c
@@ -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;