* generic_load: Add ``set remote {read,write}-packet-size NNNN''
@ 1999-11-02 23:26 Andrew Cagney
1999-11-03 21:23 ` Andrew Cagney
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cagney @ 1999-11-02 23:26 UTC (permalink / raw)
To: GDB Patches
Hello,
The attatched patch to remote.c adds support for the two commands:
set remote read-packet-size VALUE
set remote write-packet-size VALUE
(and deprecates the old badly named ``set remotepacketsize''). The
command has the following behavour:
<=0 The default packet size (as determined
by playing around with REGISTER_RAW_SIZE
is restored.
>=16k Illegal until the alloca() are removed.
>= ~REGISTER_RAW_SIZE/2
The user is prompted for confirmation that
they really really want to change the buffer
size.
other The specified size is used but also capped
by the size of the ``g'' packet returned
by the target (consistent with the current
behavour)!
Of course, if someone has better names (or other comments) please post
:-)
Andrew
(gdb) set remote read-packet-size 0
Packet size set to the default of 400 bytes.
(gdb) set remote read-packet-size 200
(gdb) show remote read-packet-size
The maximum number of characters per memory-read packet is 200.
(gdb) set remote read-packet-size 401
The read packet size of 401 is larger then the
default of 400 for this target.
Do you really want to make the change? (y or n) n
(gdb) show remote read-packet-size
The maximum number of characters per memory-read packet is 200.
(gdb) set remote read-packet-size 401
The read packet size of 401 is larger then the
default of 400 for this target.
Do you really want to make the change? (y or n) y
(gdb) show remote read-packet-size
The maximum number of characters per memory-read packet is 401.
(gdb)
Wed Nov 3 17:14:39 1999 Andrew Cagney <cagney@b1.cygnus.com>
* remote.c (get_memory_packet_size, set_memory_packet_size): New
functions. Set/compute the size of a memory read/write packet.
(set_memory_read_packet_size, set_memory_write_packet_size): New.
Verify changes to the memory read/write packet size.
(memory_read_packet_size, memory_write_packet_size):
New. Determine the current memory read/write packet size. A
function is needed as ``actual_register_packet_size'', a variable
is used in the calculation.
(register_remote_packet_sizes, build_remote_packet_sizes):
Initialize packet sizes according the current architecture.
(prefered_write_packet_size, actual_write_packet_size,
prefered_read_packet_size, actual_read_packet_size): New
variables.
(remote_fetch_registers, remote_fetch_registers,
remote_write_bytes, remote_read_bytes, build_remote_gdbarch_data):
Update.
(_initialize_remote): Add the commands ``set remote
read-packet-size'' and ``set remote write-packet-size''.
Deprecate ``set remotepacketsize''.
Index: remote.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/remote.c,v
retrieving revision 1.253
diff -p -r1.253 remote.c
*** remote.c 1999/10/25 08:36:49 1.253
--- remote.c 1999/11/03 07:22:33
*************** static serial_t remote_desc = NULL;
*** 280,307 ****
to denote that the target is in kernel mode. */
static int cisco_kernel_mode = 0;
- /* Maximum number of bytes to read/write at once. The value here
- is chosen to fill up a packet (the headers account for the 32). */
- #define MAXBUFBYTES(N) (((N)-32)/2)
-
- /* Having this larger than 400 causes us to be incompatible with m68k-stub.c
- and i386-stub.c. Normally, no one would notice because it only matters
- for writing large chunks of memory (e.g. in downloads). Also, this needs
- to be more than 400 if required to hold the registers (see below, where
- we round it up based on REGISTER_BYTES). */
- /* Round up PBUFSIZ to hold all the registers, at least. */
- #define PBUFSIZ ((REGISTER_BYTES > MAXBUFBYTES (400)) \
- ? (REGISTER_BYTES * 2 + 32) \
- : 400)
-
-
- /* This variable sets the number of bytes to be written to the target
- in a single packet. Normally PBUFSIZ is satisfactory, but some
- targets need smaller values (perhaps because the receiving end
- is slow). */
-
- static int remote_write_size;
-
/* This variable sets the number of bits in an address that are to be
sent in a memory ("M" or "m") packet. Normally, after stripping
leading zeros, the entire address would be sent. This variable
--- 280,285 ----
*************** static int remote_write_size;
*** 315,332 ****
static int remote_address_size;
- /* This is the size (in chars) of the first response to the `g' command. This
- is used to limit the size of the memory read and write commands to prevent
- stub buffers from overflowing. The size does not include headers and
- trailers, it is only the payload size. */
-
- static int remote_register_buf_size = 0;
-
/* Tempoary to track who currently owns the terminal. See
target_async_terminal_* for more details. */
static int remote_async_terminal_ours_p;
/* Generic configuration support for packets the stub optionally
supports. Allows the user to specify the use of the packet as well
as allowing GDB to auto-detect support in the remote stub. */
--- 293,477 ----
static int remote_address_size;
/* Tempoary to track who currently owns the terminal. See
target_async_terminal_* for more details. */
static int remote_async_terminal_ours_p;
+ \f
+ /* This is the size (in chars) of the first response to the ``g''
+ packet. It is used, as a heuristic, when determining the maximum
+ size of memory-read and memory-write packets. A target will
+ typically only reserve a buffer large enough to hold the ``g''
+ packet. Since the size does not include headers and trailers. */
+
+ static long actual_register_packet_size;
+
+ /* This is the maximum size (in chars) of a non read/write packet. It
+ is also used as a cap on the size of read/write packets. */
+
+ static long remote_packet_size;
+ /* compatibility. */
+ #define PBUFSIZ (remote_packet_size)
+
+ /* User configurable variables for the number of characters in a
+ memory read/write packet. Normally PBUFSIZ is satisfactory, but
+ some targets need smaller values (perhaps because the receiving end
+ is slow). Other targets need larger values because they really do
+ have larger buffers. Two variables are used ``prefered_...'' and
+ ``actual_...'. The former is set through the ``set remote
+ {read,write}-size'' command. It is they verified and, if valid
+ copied to the corresponding ``actual_..'' variable. */
+
+ /* Update the size of a read/write packet. If they user wants
+ something really big then do a sanity check. */
+
+ static void
+ set_memory_packet_size (long *prefered_packet_size,
+ char *rw,
+ long *actual_packet_size)
+ {
+ /* FIXME: Need to further cap the packet within reasonable (but
+ somewhat arbitrary) limits. */
+ #ifndef MAX_REMOTE_PACKET_SIZE
+ #define MAX_REMOTE_PACKET_SIZE 16384
+ #endif
+ if (*prefered_packet_size > MAX_REMOTE_PACKET_SIZE)
+ {
+ /* This number comes from the knowledge (folk law?) that some
+ hosts don't cope very well with large alloca() calls.
+ Eventually the alloca() code will be replaced by calls to
+ xmalloc()/make_cleanups() allowing this restriction to either
+ be lifted or removed. */
+ *prefered_packet_size = *actual_packet_size;
+ error ("The %s packet size is larger than the maximum allowable (%d).\n",
+ rw, MAX_REMOTE_PACKET_SIZE);
+ }
+ else if (*prefered_packet_size > remote_packet_size
+ && !query ("The %s packet size of %ld is larger then the\n"
+ "default of %ld for this target.\n"
+ "Do you really want to make the change? ",
+ rw, *prefered_packet_size, remote_packet_size))
+ {
+ /* Revert to what was there before. Stop the problem of a
+ rejected operation apparently apparently having some
+ effect. */
+ *prefered_packet_size = *actual_packet_size;
+ }
+ else if (*prefered_packet_size <= 0)
+ {
+ /* Revert to the default packet size for this target. */
+ *prefered_packet_size = remote_packet_size;
+ *actual_packet_size = 0;
+ fprintf_unfiltered (gdb_stdout,
+ "Packet size set to the default of %d bytes.\n",
+ remote_packet_size);
+ }
+ else
+ {
+ /* What is actually used is also determined by other factors -
+ see get_memory_packet_size(). */
+ *actual_packet_size = *prefered_packet_size;
+ }
+ }
+
+ /* Compute the current size of a read/write packet. Since this makes
+ use of ``actual_register_packet_size'' the computation is dynamic. */
+
+ static long
+ get_memory_packet_size (long what_they_want,
+ long actual_packet_size)
+ {
+ long what_they_get;
+ /* Start with what the user configured. */
+ if (actual_packet_size > 0)
+ what_they_get = actual_packet_size;
+ else
+ what_they_get = remote_packet_size;
+ /* If the user didn't forced the packet size, cap it according to
+ the size of the target's G packet. */
+ if (what_they_get < remote_packet_size
+ && actual_register_packet_size > 0
+ && what_they_get > actual_register_packet_size)
+ what_they_get = actual_register_packet_size;
+ return what_they_get;
+ }
+
+ static long prefered_write_packet_size;
+ static long actual_write_packet_size;
+
+ static void
+ set_memory_write_packet_size (char *args, int from_tty,
+ struct cmd_list_element * c)
+ {
+ set_memory_packet_size (&prefered_write_packet_size, "write",
+ &actual_write_packet_size);
+ }
+
+ static long
+ memory_write_packet_size (long what_they_want)
+ {
+ return get_memory_packet_size (what_they_want, actual_write_packet_size);
+ }
+
+ static long prefered_read_packet_size;
+ static long actual_read_packet_size;
+
+ static void
+ set_memory_read_packet_size (char *args, int from_tty,
+ struct cmd_list_element * c)
+ {
+ set_memory_packet_size (&prefered_read_packet_size, "read",
+ &actual_read_packet_size);
+ }
+
+ static long
+ memory_read_packet_size (int what_they_want)
+ {
+ return get_memory_packet_size (what_they_want, actual_read_packet_size);
+ }
+
+ /* Register packet size initialization. Since the bounds change when
+ the architecture changes (namely REGISTER_BYTES) this all needs to
+ be multi-arched. */
+
+ static void
+ register_remote_packet_sizes (void)
+ {
+ REGISTER_GDBARCH_SWAP (remote_packet_size);
+ REGISTER_GDBARCH_SWAP (actual_register_packet_size);
+ REGISTER_GDBARCH_SWAP (prefered_write_packet_size);
+ REGISTER_GDBARCH_SWAP (actual_write_packet_size);
+ REGISTER_GDBARCH_SWAP (prefered_read_packet_size);
+ REGISTER_GDBARCH_SWAP (actual_read_packet_size);
+ REGISTER_GDBARCH_SWAP (prefered_write_packet_size);
+ REGISTER_GDBARCH_SWAP (actual_write_packet_size);
+ }
+
+ static void
+ build_remote_packet_sizes (void)
+ {
+ /* Maximum number of characters in a packet. This default m68k-stub.c and
+ i386-stub.c stubs. */
+ remote_packet_size = 400;
+ /* Should REGISTER_BYTES needs more space than the default, adjust
+ the size accordingly. Remember that each byte is encoded as two
+ characters. 32 is the overhead for the packet
+ header/footer. cagney/1999-10-26: Actually, I suspect that 8
+ (``$NN:G...#NN'') is a better guess. I suspect that the below
+ was padded a little. */
+ if (REGISTER_BYTES > ((remote_packet_size - 32) / 2))
+ remote_packet_size = (REGISTER_BYTES * 2 + 32);
+
+ /* This one is filled in when a ``g'' packet is received. */
+ actual_register_packet_size = 0;
+
+ prefered_write_packet_size = remote_packet_size;
+ actual_write_packet_size = remote_packet_size;
+ prefered_read_packet_size = remote_packet_size;
+ actual_read_packet_size = remote_packet_size;
+ }
+ \f
/* Generic configuration support for packets the stub optionally
supports. Allows the user to specify the use of the packet as well
as allowing GDB to auto-detect support in the remote stub. */
*************** remote_fetch_registers (regno)
*** 2749,2756 ****
sprintf (buf, "g");
remote_send (buf);
! if (remote_register_buf_size == 0)
! remote_register_buf_size = strlen (buf);
/* Unimplemented registers read as all bits zero. */
memset (regs, 0, REGISTER_BYTES);
--- 2894,2904 ----
sprintf (buf, "g");
remote_send (buf);
! /* Save the size of the packet sent to us by the target. Its used
! as a heuristic when determining the max size of packets that the
! target can safely receive. */
! if (actual_register_packet_size == 0)
! actual_register_packet_size = strlen (buf);
/* Unimplemented registers read as all bits zero. */
memset (regs, 0, REGISTER_BYTES);
*************** remote_write_bytes (CORE_ADDR memaddr, c
*** 3095,3103 ****
check_binary_download (memaddr);
/* Determine the max packet size. */
! max_buf_size = min (remote_write_size, PBUFSIZ);
! if (remote_register_buf_size != 0)
! max_buf_size = min (max_buf_size, remote_register_buf_size);
buf = alloca (max_buf_size + 1);
/* Subtract header overhead from max payload size - $M<memaddr>,<len>:#nn */
--- 3243,3249 ----
check_binary_download (memaddr);
/* Determine the max packet size. */
! max_buf_size = memory_write_packet_size (len);
buf = alloca (max_buf_size + 1);
/* Subtract header overhead from max payload size - $M<memaddr>,<len>:#nn */
*************** remote_read_bytes (memaddr, myaddr, len)
*** 3228,3243 ****
char *myaddr;
int len;
{
! char *buf = alloca (PBUFSIZ);
int max_buf_size; /* Max size of packet output buffer */
int origlen;
! /* Chop the transfer down if necessary */
- max_buf_size = min (remote_write_size, PBUFSIZ);
- if (remote_register_buf_size != 0)
- max_buf_size = min (max_buf_size, remote_register_buf_size);
-
origlen = len;
while (len > 0)
{
--- 3374,3387 ----
char *myaddr;
int len;
{
! char *buf;
int max_buf_size; /* Max size of packet output buffer */
int origlen;
! /* Create a buffer big enough for this packet. */
! max_buf_size = memory_read_packet_size (len);
! buf = alloca (max_buf_size);
origlen = len;
while (len > 0)
{
*************** set_remote_cmd (args, from_tty)
*** 5220,5225 ****
--- 5364,5372 ----
static void
build_remote_gdbarch_data ()
{
+ build_remote_packet_sizes ();
+
+ /* Cisco stuff */
tty_input = xmalloc (PBUFSIZ);
}
*************** _initialize_remote ()
*** 5228,5243 ****
{
static struct cmd_list_element *remote_set_cmdlist;
static struct cmd_list_element *remote_show_cmdlist;
/* architecture specific data */
build_remote_gdbarch_data ();
register_gdbarch_swap (&tty_input, sizeof (&tty_input), NULL);
register_gdbarch_swap (NULL, 0, build_remote_gdbarch_data);
- /* runtime constants - we retain the value of remote_write_size
- across architecture swaps. */
- remote_write_size = PBUFSIZ;
-
init_remote_ops ();
add_target (&remote_ops);
--- 5375,5388 ----
{
static struct cmd_list_element *remote_set_cmdlist;
static struct cmd_list_element *remote_show_cmdlist;
+ struct cmd_list_element *tmpcmd;
/* architecture specific data */
build_remote_gdbarch_data ();
register_gdbarch_swap (&tty_input, sizeof (&tty_input), NULL);
+ register_remote_packet_sizes ();
register_gdbarch_swap (NULL, 0, build_remote_gdbarch_data);
init_remote_ops ();
add_target (&remote_ops);
*************** terminating `#' character and checksum."
*** 5298,5309 ****
&setlist),
&showlist);
! add_show_from_set
! (add_set_cmd ("remotewritesize", no_class,
! var_integer, (char *) &remote_write_size,
! "Set the maximum number of bytes per memory write packet.\n",
! &setlist),
! &showlist);
remote_address_size = TARGET_PTR_BIT;
add_show_from_set
--- 5443,5473 ----
&setlist),
&showlist);
! /* Establish commands for configuring memory packets. */
! /* NOTE: The assignment to ``->sfunc occures after the call to
! add_show_from_set(). This stops the show command getting the set
! commands sfunc value. */
! tmpcmd = add_set_cmd
! ("remotewritesize", no_class,
! var_integer, (char *) &prefered_write_packet_size,
! "Set the maximum number of bytes per memory packet (deprecated).\n",
! &setlist);
! add_show_from_set (tmpcmd, &showlist);
! tmpcmd->function.sfunc = set_memory_write_packet_size;
! tmpcmd = add_set_cmd
! ("write-packet-size", no_class,
! var_zinteger, (char *) &prefered_write_packet_size,
! "Set the maximum number of characters per memory-write packet.\n",
! &remote_set_cmdlist);
! add_show_from_set (tmpcmd, &remote_show_cmdlist);
! tmpcmd->function.sfunc = set_memory_write_packet_size;
! tmpcmd = add_set_cmd
! ("read-packet-size", no_class,
! var_zinteger, (char *) &prefered_read_packet_size,
! "Set the maximum number of characters per memory-read packet.\n",
! &remote_set_cmdlist);
! add_show_from_set (tmpcmd, &remote_show_cmdlist);
! tmpcmd->function.sfunc = set_memory_read_packet_size;
remote_address_size = TARGET_PTR_BIT;
add_show_from_set
From jimb@cygnus.com Wed Nov 03 06:49:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: muller@cerbere.u-strasbg.fr
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: print_symbol_info patch for source code not current language
Date: Wed, 03 Nov 1999 06:49:00 -0000
Message-id: <npd7trk4us.fsf@zwingli.cygnus.com>
References: <muller@cerbere.u-strasbg.fr's> <message> <of> <Fri,> <29> <Oct> <199923:28:56> <+0200> <381824BF.BCE63370@cygnus.com> <5mogdjbkr2.fsf@jtc.redbacknetworks.com> <199910291101.NAA00678@cerbere.u-strasbg.fr> <npzox2klaw.fsf@zwingli.cygnus.com> <3.0.6.32.19991029232856.0089fdc0@ics.u-strasbg.fr> <3.0.6.32.19991101233836.008a5100@ics.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00158.html
Content-length: 1028
> easy (its a fake one !)
>
> static int test(int a;double c);
> would give
> if pascal is current laguage in auto mode
>
> static int test(a : longint;c : double);
>
> The function syntax is C but thesyntax of args is the pascal one !!
Yeah, that's what I was afraid of.
This is a bug in GDB. There is no plausible reason to want to print
the function using one language, and its arguments in a different
language. Some piece of code is using current-language when it
shouldn't. Could you track this down, and see where the inappropriate
switch from C to Pascal occurs?
I haven't actually looked at the code yet, though, so I don't know how
easy it will be to fix. I have the feeling that C and C++ are sharing
code in some ungodly fashion which will make this difficult to fix.
> I really tried first your proposal and as I did not like the result
> above I changed the method to what I sent you !
I understand. But in situations like this it's important to fix the
real bug, instead of kludging around it.
From muller@cerbere.u-strasbg.fr Wed Nov 03 07:19:00 1999
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: print_symbol_info patch for source code not current language
Date: Wed, 03 Nov 1999 07:19:00 -0000
Message-id: <199911031533.QAA26903@cerbere.u-strasbg.fr>
References: <muller@cerbere.u-strasbg.fr's> <message> <of> <Mon,> <01> <Nov> <1999> <23:38:36> <+0100> <muller@cerbere.u-strasbg.fr's> <message> <of> <Fri,> <29> <Oct> <199923:28:56> <+0200> <381824BF.BCE63370@cygnus.com> <5mogdjbkr2.fsf@jtc.redbacknetworks.com> <199910291101.NAA00678@cerbere.u-strasbg.fr> <npzox2klaw.fsf@zwingli.cygnus.com> <3.0.6.32.19991029232856.0089fdc0@ics.u-strasbg.fr> <3.0.6.32.19991101233836.008a5100@ics.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00159.html
Content-length: 2023
At 09:49 03/11/99 -0500, Jim Blandy wrote:
>
>> easy (its a fake one !)
>>
>> static int test(int a;double c);
>> would give
>> if pascal is current laguage in auto mode
>>
>> static int test(a : longint;c : double);
>>
>> The function syntax is C but thesyntax of args is the pascal one !!
>
>Yeah, that's what I was afraid of.
>
>This is a bug in GDB. There is no plausible reason to want to print
>the function using one language, and its arguments in a different
>language. Some piece of code is using current-language when it
>shouldn't. Could you track this down, and see where the inappropriate
>switch from C to Pascal occurs?
But this will not be easy I fear !
print_symbol_info calls
type_print
which in turn just uses
LA_PRINT_TYPE()
but the problem is that I am not sure that using source language would
be a good thing for
all calls to type_print !
I only thought this would be helpful for print_symbol_info
because there you can get several different sources.
But I would not like to have a
"p PASCAL_RECORD"
giving a pascal format if I am currently inside some C code
that uses a global pascal variable !
>I haven't actually looked at the code yet, though, so I don't know how
>easy it will be to fix. I have the feeling that C and C++ are sharing
>code in some ungodly fashion which will make this difficult to fix.
>
>> I really tried first your proposal and as I did not like the result
>> above I changed the method to what I sent you !
>
>I understand. But in situations like this it's important to fix the
>real bug, instead of kludging around it.
The problem is that even if the case of args of a function is quite clear
I suspect that in other cases it will no be so easy to decide
when we should use current_language and when
we should use the source file langage !
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
From scottb@netwinder.org Wed Nov 03 08:36:00 1999
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Patch to get rdi_share to build again...
Date: Wed, 03 Nov 1999 08:36:00 -0000
Message-id: <382063B3.FC2C8BC2@netwinder.org>
X-SW-Source: 1999-q4/msg00160.html
Content-length: 838
1999-11-03 Scott Bambrough <scottb@netwinder.org>
* gdb/rdi-share/Makefile.in: bytesex.o renamed angel_bytesex.o.
Index: Makefile.in
===================================================================
RCS file: /cvs/gdb/gdb/gdb/rdi-share/Makefile.in,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 Makefile.in
--- Makefile.in 1999/11/02 04:44:25 1.1.1.3
+++ Makefile.in 1999/11/03 16:31:19
@@ -94,7 +94,7 @@
LDFLAGS = @LDFLAGS@
LIBS = @LIBS@
libangsd_a_LIBADD =
-libangsd_a_OBJECTS = ardi.o bytesex.o crc.o devsw.o drivers.o \
+libangsd_a_OBJECTS = ardi.o angel_bytesex.o crc.o devsw.o drivers.o \
etherdrv.o hostchan.o hsys.o logging.o msgbuild.o params.o rx.o \
serdrv.o serpardr.o tx.o unixcomm.o
AR = ar
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From fnasser@cygnus.com Wed Nov 03 09:16:00 1999
From: Fernando Nasser <fnasser@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Patch to get rdi_share to build again...
Date: Wed, 03 Nov 1999 09:16:00 -0000
Message-id: <38206DFC.4F10115A@cygnus.com>
References: <382063B3.FC2C8BC2@netwinder.org>
X-SW-Source: 1999-q4/msg00161.html
Content-length: 1304
Thanks Scott. I had noticed it and immediately checked the fix into the
repository so it was broke for a few minutes only -- exactly the time
when the snapshot was taken. :-(
Scott Bambrough wrote:
>
> 1999-11-03 Scott Bambrough <scottb@netwinder.org>
>
> * gdb/rdi-share/Makefile.in: bytesex.o renamed angel_bytesex.o.
>
> Index: Makefile.in
> ===================================================================
> RCS file: /cvs/gdb/gdb/gdb/rdi-share/Makefile.in,v
> retrieving revision 1.1.1.3
> diff -u -r1.1.1.3 Makefile.in
> --- Makefile.in 1999/11/02 04:44:25 1.1.1.3
> +++ Makefile.in 1999/11/03 16:31:19
> @@ -94,7 +94,7 @@
> LDFLAGS = @LDFLAGS@
> LIBS = @LIBS@
> libangsd_a_LIBADD =
> -libangsd_a_OBJECTS = ardi.o bytesex.o crc.o devsw.o drivers.o \
> +libangsd_a_OBJECTS = ardi.o angel_bytesex.o crc.o devsw.o drivers.o \
> etherdrv.o hostchan.o hsys.o logging.o msgbuild.o params.o rx.o \
> serdrv.o serpardr.o tx.o unixcomm.o
> AR = ar
>
> --
> Scott Bambrough - Software Engineer
> REBEL.COM http://www.rebel.com
> NetWinder http://www.netwinder.org
--
Fernando Nasser
Cygnus Solutions - Toronto Office E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #502 Tel: 416-482-3039
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From kevinb@cygnus.com Wed Nov 03 09:44:00 1999
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <cagney@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: RFA: remote_address_size changes
Date: Wed, 03 Nov 1999 09:44:00 -0000
Message-id: <991103174409.ZM14789@ocotillo.lan>
X-SW-Source: 1999-q4/msg00162.html
Content-length: 2884
Andrew,
As you know, I'm working on a port for a 64 bit target and am using
the gdbarch machinery.
When connecting to my remote target, remote_address_size was not
being set properly. The reason for this is because at the time
of initialization in _initialize_remote(), TARGET_PTR_BIT refers
to the ptr_bit field in default_gdbarch instead of in a gdbarch
struct created for the target. As a result, remote_address_size
was set to the pointer size of the host and not the target.
I have fixed the problem by deferring the real initialization of
remote_address_size until we get into one of remote_open_1() or
remote_async_open_1(). In order to handle the situation where
the user wants to set it to something else prior to issuing a
"target remote ..." command, I set remote_address_size to 0 in
_initialize_remote(). If, when we get to remote_open_1(), it
hasn't been set to something non-zero by the user, it'll get
initialized properly via TARGET_PTR_BIT.
One of the things I don't like about this patch is that if the user
does "show remoteaddresssize" before connecting to a target, it'll
display as zero. OTOH, it isn't correct to display the host pointer
size either, so perhaps this isn't so bad.
The other thing that bothers me is that if the user uses the same gdb
session to connect to several different targets with different address
sizes [does anyone ever do this?], the conditional initialization
if (remote_address_size == 0)
remote_address_size = TARGET_PTR_BIT;
will not set remote_address_size correctly.
Kevin
* remote.c (_initialize_remote): Initialize remote_address_size
to zero.
(remote_open_1, remote_async_open_1): Set remote_address_size
to TARGET_PTR_BIT if not already set by the user (or by
already opening a target).
Index: remote.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/remote.c,v
retrieving revision 1.253
diff -u -r1.253 remote.c
--- remote.c 1999/10/25 08:36:49 1.253
+++ remote.c 1999/11/03 17:08:38
@@ -1775,6 +1775,9 @@
general_thread = -2;
continue_thread = -2;
+ if (remote_address_size == 0)
+ remote_address_size = TARGET_PTR_BIT;
+
/* Force remote_write_bytes to check whether target supports
binary downloading. */
init_packet_config (&remote_protocol_binary_download);
@@ -1859,6 +1862,9 @@
general_thread = -2;
continue_thread = -2;
+ if (remote_address_size == 0)
+ remote_address_size = TARGET_PTR_BIT;
+
/* Force remote_write_bytes to check whether target supports
binary downloading. */
init_packet_config (&remote_protocol_binary_download);
@@ -5305,7 +5311,7 @@
&setlist),
&showlist);
- remote_address_size = TARGET_PTR_BIT;
+ remote_address_size = 0;
add_show_from_set
(add_set_cmd ("remoteaddresssize", class_obscure,
var_integer, (char *) &remote_address_size,
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: generic_load: Add ``set remote {read,write}-packet-size NNNN''
1999-11-02 23:26 generic_load: Add ``set remote {read,write}-packet-size NNNN'' Andrew Cagney
@ 1999-11-03 21:23 ` Andrew Cagney
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 1999-11-03 21:23 UTC (permalink / raw)
To: GDB Patches
Well,
After much feedback :-), I've reviewed the behavour of the commands and
consequently changed it to:
set remote memory-{read,write}-packet-size {VALUE,fixed,limit}
The VALUE is either a ``limit'' or ``fixed''. A ``limit'' is further
reduced by GDB being paranoid about overrunning the targets buffer. A
fixed value bypasses that mechanism. GDB's existing behavour is to
``limit'' the packet size and that is made the default.
The main motivation for the change is that my initial implementaton
would change the packet size whenever the architecture changed :-(. The
new implementation is more transparent (?).
For instance:
Initially the packet size is not set so the target default is used and
that can be changed to anything:
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is 0. Packets are limited to 400 bytes.
(gdb) set remote memory-read-packet-size 200
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is 200. Packets are limited to 200 bytes.
(gdb) set remote memory-read-packet-size 10000
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is 10000. Packets are limited to 400 bytes.
Fixing the packet size attracts a warning and a different show output:
(gdb) set remote memory-read-packet-size fixed
The target may not be able to correctly handle a memory-read packet size
of 200 bytes.
Change the packet size? (y or n) y
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is fixed at 200 bytes.
(gdb) set remote memory-read-packet-size limit
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is 200. Packets are limited to 200 bytes.
(gdb) set remote memory-read-packet-size 0
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is 0. Packets are limited to 400 bytes.
Changing the architecture leads to fairly consistent behavour (say there
are two architectures byte50 and byte60):
(gdb) set remote memory-read-packet-size fixed
...
(gdb) set remote memory-read-packet-size 100
(gdb) set architecture byte50
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is fixed at 100 bytes.
(gdb) set architecture byte60
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is fixed at 100 bytes.
(gdb) set remote memory-read-packet-size limit
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is 100. Packets are limited to 60 bytes.
(gdb) set architecture byte50
(gdb) show remote memory-read-packet-size
The memory-read-packet-size is 100. Packets are limited to 50 bytes.
More importantly the sequence:
set remote .... NNN
file ZYX
and
file ZYX
set remote .... NNN
now have identical behavour.
Thoughts. Better names?
Andrew
Andrew Cagney wrote:
>
> Hello,
>
> The attatched patch to remote.c adds support for the two commands:
>
> set remote read-packet-size VALUE
> set remote write-packet-size VALUE
>
> (and deprecates the old badly named ``set remotepacketsize''). The
> command has the following behavour:
>
> <=0 The default packet size (as determined
> by playing around with REGISTER_RAW_SIZE
> is restored.
>
> >=16k Illegal until the alloca() are removed.
>
> >= ~REGISTER_RAW_SIZE/2
> The user is prompted for confirmation that
> they really really want to change the buffer
> size.
>
> other The specified size is used but also capped
> by the size of the ``g'' packet returned
> by the target (consistent with the current
> behavour)!
>
> Of course, if someone has better names (or other comments) please post
> :-)
>
> Andrew
>
> (gdb) set remote read-packet-size 0
> Packet size set to the default of 400 bytes.
> (gdb) set remote read-packet-size 200
> (gdb) show remote read-packet-size
> The maximum number of characters per memory-read packet is 200.
> (gdb) set remote read-packet-size 401
> The read packet size of 401 is larger then the
> default of 400 for this target.
> Do you really want to make the change? (y or n) n
> (gdb) show remote read-packet-size
> The maximum number of characters per memory-read packet is 200.
> (gdb) set remote read-packet-size 401
> The read packet size of 401 is larger then the
> default of 400 for this target.
> Do you really want to make the change? (y or n) y
> (gdb) show remote read-packet-size
> The maximum number of characters per memory-read packet is 401.
> (gdb)
>
> ------------------------------------------------------------------------
> Wed Nov 3 17:14:39 1999 Andrew Cagney <cagney@b1.cygnus.com>
>
> * remote.c (get_memory_packet_size, set_memory_packet_size): New
> functions. Set/compute the size of a memory read/write packet.
> (set_memory_read_packet_size, set_memory_write_packet_size): New.
> Verify changes to the memory read/write packet size.
> (memory_read_packet_size, memory_write_packet_size):
> New. Determine the current memory read/write packet size. A
> function is needed as ``actual_register_packet_size'', a variable
> is used in the calculation.
> (register_remote_packet_sizes, build_remote_packet_sizes):
> Initialize packet sizes according the current architecture.
> (prefered_write_packet_size, actual_write_packet_size,
> prefered_read_packet_size, actual_read_packet_size): New
> variables.
> (remote_fetch_registers, remote_fetch_registers,
> remote_write_bytes, remote_read_bytes, build_remote_gdbarch_data):
> Update.
> (_initialize_remote): Add the commands ``set remote
> read-packet-size'' and ``set remote write-packet-size''.
> Deprecate ``set remotepacketsize''.
>
From muller@cerbere.u-strasbg.fr Thu Nov 04 02:43:00 1999
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb-patches@sourceware.cygnus.com
Subject: Watching complex expressions patch
Date: Thu, 04 Nov 1999 02:43:00 -0000
Message-id: <199911041058.LAA04309@cerbere.u-strasbg.fr>
References: <Pine.LNX.4.10.9911031800380.19860-100000@hpcll168.cup.hp.com>
X-SW-Source: 1999-q4/msg00170.html
Content-length: 5912
I think that the approach of VALUE_LAZY for the watchpoint is completely
wrong !
I propose here a patch that completely change the mecanism of which
memory must be
watched :
if you have a struct t { int a,b,c;}
and you set a watch to t.c
you only want to get stopped if t.c changes not if t.a or t.b changes
but currently using the VALUE_LAZY seems to be quite unsure
On go32 target,
the code wanted to watch first t.c and then this entire t struct and that
is wrong of course !
So my mecanism remembers the last memory that has been set a watch
and after reject all watches of bigger memory regions including that memory !
For more complex watch, with intermediate value that can change
like if p is a pointer to the above struct t
watch p->c
will the watch both current location of t.c (if p is set to &t)
and location of p as it is not inside the memory region of t.c itself !
(Even if you imagine that you have complicated case where the same memory is
fetched several times it still should work correctly !)
Index: breakpoint.c
===================================================================
RCS file: /cvs/gdb/gdb/gdb/breakpoint.c,v
retrieving revision 1.1.1.16
diff -b -c -r1.1.1.16 breakpoint.c
*** breakpoint.c 1999/11/02 04:44:13 1.1.1.16
--- breakpoint.c 1999/11/04 10:30:09
***************
*** 951,956 ****
--- 951,959 ----
if (within_current_scope)
{
+ CORE_ADDR last_lval_address = 0;
+ int last_lval_size = 0;
+ int last_type = 0;
/* Evaluate the expression and cut the chain of values
produced off from the value chain.
***************
*** 967,977 ****
/* Look at each value on the value chain. */
for (; v; v = v->next)
{
! /* If it's a memory location, and GDB actually needed
! its contents to evaluate the expression, then we
! must watch it. */
! if (VALUE_LVAL (v) == lval_memory
! && ! VALUE_LAZY (v))
{
CORE_ADDR addr;
int len, type;
--- 970,982 ----
/* Look at each value on the value chain. */
for (; v; v = v->next)
{
! /* If it's a memory location, then we must watch it. */
! if ((VALUE_LVAL (v) == lval_memory) &&
! /* Unless its a bigger part from a small part we want to
! watch */
! !((VALUE_ADDRESS (v) + VALUE_OFFSET (v) <= last_lval_address) &&
! (VALUE_ADDRESS (v) + VALUE_OFFSET (v) + TYPE_LENGTH
(VALUE_TYPE (v))
! >= last_lval_address + last_lval_size)))
{
CORE_ADDR addr;
int len, type;
***************
*** 983,988 ****
--- 988,997 ----
type = hw_read;
else if (b->type == bp_access_watchpoint)
type = hw_access;
+ /* Non terminal are only important if
+ their value changes */
+ if (last_type)
+ type = hw_write;
val = target_insert_watchpoint (addr, len, type);
if (val == -1)
***************
*** 991,996 ****
--- 1000,1008 ----
break;
}
val = 0;
+ last_lval_size = len;
+ last_lval_address = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
+ last_type = type;
}
}
/* Failure to insert a watchpoint on any memory value in the
***************
*** 1309,1323 ****
&& !b->duplicate)
{
value_ptr v, n;
b->inserted = (is == mark_inserted);
/* Walk down the saved value chain. */
for (v = b->val_chain; v; v = v->next)
{
/* For each memory reference remove the watchpoint
at that address. */
! if (VALUE_LVAL (v) == lval_memory
! && ! VALUE_LAZY (v))
{
CORE_ADDR addr;
int len, type;
--- 1321,1352 ----
&& !b->duplicate)
{
value_ptr v, n;
+ CORE_ADDR last_lval_address = 0;
+ int last_lval_size = 0;
+ int last_type = 0;
b->inserted = (is == mark_inserted);
/* Walk down the saved value chain. */
for (v = b->val_chain; v; v = v->next)
{
/* For each memory reference remove the watchpoint
+ at that address. */
+ /* If it's a memory location, then we must watch it. */
+ if ((VALUE_LVAL (v) == lval_memory) &&
+ /* Unless its a bigger part from a small part we want to
+ watch */
+ !((VALUE_ADDRESS (v) + VALUE_OFFSET (v) <= last_lval_address) &&
+ (VALUE_ADDRESS (v) + VALUE_OFFSET (v) + TYPE_LENGTH
(VALUE_TYPE (v))
+ >= last_lval_address + last_lval_size)))
+ /* For each memory reference remove the watchpoint
at that address. */
! /* If it's a memory location, then we must watch it. */
! if ((VALUE_LVAL (v) == lval_memory) &&
! /* Unless its a bigger part from a small part we want to
! watch */
! !((VALUE_ADDRESS (v) + VALUE_OFFSET (v) <= last_lval_address) &&
! (VALUE_ADDRESS (v) + VALUE_OFFSET (v) + TYPE_LENGTH
(VALUE_TYPE (v))
! >= last_lval_address + last_lval_size)))
{
CORE_ADDR addr;
int len, type;
***************
*** 1329,1339 ****
--- 1358,1373 ----
type = hw_read;
else if (b->type == bp_access_watchpoint)
type = hw_access;
+ if (last_type)
+ type = hw_write;
val = target_remove_watchpoint (addr, len, type);
if (val == -1)
b->inserted = 1;
val = 0;
+ last_lval_size = len;
+ last_lval_address = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
+ last_type = type;
}
}
/* Failure to remove any of the hardware watchpoints comes here. */
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
From msnyder@cygnus.com Thu Nov 04 11:31:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Watching complex expressions patch
Date: Thu, 04 Nov 1999 11:31:00 -0000
Message-id: <3821DF12.7A84@cygnus.com>
References: <Pine.LNX.4.10.9911031800380.19860-100000@hpcll168.cup.hp.com> <199911041058.LAA04309@cerbere.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00171.html
Content-length: 1046
Pierre Muller wrote:
>
> I think that the approach of VALUE_LAZY for the watchpoint is
> completely wrong !
>
> I propose here a patch that completely change the mecanism of
> which memory must be watched :
>
> if you have a struct t { int a,b,c;}
> and you set a watch to t.c
> you only want to get stopped if t.c changes not if t.a or t.b
> changes but currently using the VALUE_LAZY seems to be quite unsure
> On go32 target,
> the code wanted to watch first t.c and then this entire t struct
> and that is wrong of course !
You are quite right!
This problem is not limited to go32, I think it is general.
I will review your patch, and if it really fixes this problem
I will be very happy.
> So my mecanism remembers the last memory that has been set a watch
> and after reject all watches of bigger memory regions including that
> memory !
Hmmm... I'm not sure that's really a valid approach.
What if the user deliberately says:
watch t.a
watch t
You might argue that is unnecessary, but we have
no reason to forbid it.
From shebs@cygnus.com Thu Nov 04 11:50:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: muller@cerbere.u-strasbg.fr
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Watching complex expressions patch
Date: Thu, 04 Nov 1999 11:50:00 -0000
Message-id: <199911041950.LAA23185@andros.cygnus.com>
References: <199911041058.LAA04309@cerbere.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00172.html
Content-length: 748
Date: Thu, 04 Nov 1999 11:46:19 +0100
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
So my mecanism remembers the last memory that has been set a watch
and after reject all watches of bigger memory regions including that memory !
I'm not clear on what you're getting at here, but it sounds wrong.
GDB should allow the user to set any combination of watchpoints on the
same or related pieces of data. The reason is the same as for
breakpoints; it's possible to attach conditions to watchpoints, and
you may have reason to attach one condition to "watch t.c", but a
different condition to a "watch t". GDB should evaluate both
conditions whenever t.c changes, but only one condition each time t.a
or t.b changes.
Stan
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1999-11-03 21:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-02 23:26 generic_load: Add ``set remote {read,write}-packet-size NNNN'' Andrew Cagney
1999-11-03 21:23 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox