From f5be36b572af790aa8bca7dd2f2e4e0da5d2a8cb Mon Sep 17 00:00:00 2001 From: Daniel Jacobowitz Date: Fri, 31 Mar 2006 18:17:29 +0000 Subject: Local changes to take full advantage of qPacketInfo --- gdb/symfile.c | 5 ++++- gdb/target.c | 4 +++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/gdb/symfile.c b/gdb/symfile.c index 59cd3dc7595..a4c883be12f 100644 --- 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) diff --git a/gdb/target.c b/gdb/target.c index 80b7b711142..1d4e035dc7b 100644 --- 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; -- cgit v1.2.1