From: Daniel Jacobowitz <drow@false.org>
To: "Theodore A. Roth" <troth@openavr.org>
Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] initialize err variable in load_section_callback()
Date: Fri, 04 Mar 2005 17:51:00 -0000 [thread overview]
Message-ID: <20050304175110.GA3986@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.53.0412271832320.9467@knuth.amplepower.com>
On Mon, Dec 27, 2004 at 06:33:48PM -0800, Theodore A. Roth wrote:
> This patch got left hanging. Is it a lost cause or can I get approval to
> commit it?
Sorry about the delay; a coworker just ran into this, which prodded me
to take another look at the problem. I'm committing something similar.
Your patch isn't quite right... here's the documented behavior
of target_read_memory_partial:
/* Make a single attempt at transfering LEN bytes. On a successful
transfer, the number of bytes actually transfered is returned and
ERR is set to 0. When a transfer fails, -1 is returned (the number
of bytes actually transfered is not defined) and ERR is set to a
non-zero error indication. */
Here's a bit of target_read_partial:
/* Request the transfer of up to LEN 8-bit bytes of the target's
OBJECT. The OFFSET, for a seekable object, specifies the starting
point. The ANNEX can be used to provide additional data-specific
information to the target.
Return the number of bytes actually transfered, zero when no
further transfer is possible, and -1 when the transfer is not
supported.
"No further transfer is possible" is an error condition.
remote_xfer_partial and inf_ptrace_xfer_partial don't seem to agree
about whether an I/O failure is a "return 0" or a "return -1"
condition; I am inclined to agree with the inf_ptrace implementation,
since the transfer is supported, but failed. An argument could be made
for either.
This patch makes target_write_memory_partial obey its specification, as
long as target_read_partial obeys its. No further transfer and
unsupported are both error conditions. The specifications could still
use some clarifying (separately).
Tested on i686-linux native, and tested by hand that load doesn't blow
up any more.
> > > - when -ve, set *err -VE return value
> >
> > I assume -ve is an error code? Sould I extend my patch to also check for
> > retval < -1 and if so set *err to retval?
He just meant "negative": if the return value is negative, set *err to
its absolute value. I stuck with the existing use of errno instead.
--
Daniel Jacobowitz
CodeSourcery, LLC
2005-03-04 Daniel Jacobowitz <dan@codesourcery.com>
* target.c (target_read_memory_partial): Always initialize
ERR.
(target_write_memory_partial): Likewise.
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.101
diff -u -p -r1.101 target.c
--- target.c 24 Feb 2005 13:51:35 -0000 1.101
+++ target.c 4 Mar 2005 17:08:12 -0000
@@ -1,7 +1,7 @@
/* Select target systems and architectures at runtime for GDB.
Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
- 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+ 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
Contributed by Cygnus Support.
@@ -1249,8 +1249,26 @@ int
target_read_memory_partial (CORE_ADDR memaddr, char *buf, int len, int *err)
{
if (target_xfer_partial_p ())
- return target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY, NULL,
- buf, NULL, memaddr, len);
+ {
+ int retval;
+
+ retval = target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY,
+ NULL, buf, NULL, memaddr, len);
+
+ if (retval <= 0)
+ {
+ if (errno)
+ *err = errno;
+ else
+ *err = EIO;
+ return -1;
+ }
+ else
+ {
+ *err = 0;
+ return retval;
+ }
+ }
else
return target_xfer_memory_partial (memaddr, buf, len, 0, err);
}
@@ -1259,8 +1277,26 @@ int
target_write_memory_partial (CORE_ADDR memaddr, char *buf, int len, int *err)
{
if (target_xfer_partial_p ())
- return target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY, NULL,
- NULL, buf, memaddr, len);
+ {
+ int retval;
+
+ retval = target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY,
+ NULL, NULL, buf, memaddr, len);
+
+ if (retval <= 0)
+ {
+ if (errno)
+ *err = errno;
+ else
+ *err = EIO;
+ return -1;
+ }
+ else
+ {
+ *err = 0;
+ return retval;
+ }
+ }
else
return target_xfer_memory_partial (memaddr, buf, len, 1, err);
}
next prev parent reply other threads:[~2005-03-04 17:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-19 20:22 Theodore A. Roth
2004-10-20 17:34 ` Andrew Cagney
2004-10-20 18:07 ` Theodore A. Roth
2004-10-26 0:04 ` Andrew Cagney
2004-10-26 18:19 ` Theodore A. Roth
2004-12-28 9:10 ` Theodore A. Roth
2005-03-04 17:51 ` Daniel Jacobowitz [this message]
2004-12-02 14:45 Paul Schlie
2005-01-04 7:31 Paul Schlie
2005-01-14 23:29 ` Paul Schlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050304175110.GA3986@nevyn.them.org \
--to=drow@false.org \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=troth@openavr.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox