From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12063 invoked by alias); 20 Oct 2004 18:07:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11897 invoked from network); 20 Oct 2004 18:07:25 -0000 Received: from unknown (HELO mail.amplepower.com) (216.39.162.139) by sourceware.org with SMTP; 20 Oct 2004 18:07:25 -0000 Received: from [192.168.8.30] (helo=knuth.amplepower.com ident=roth) by mail.amplepower.com with esmtp (Exim 3.36 #1 (Debian)) id 1CKKrr-00075m-00; Wed, 20 Oct 2004 11:07:23 -0700 Date: Wed, 20 Oct 2004 18:07:00 -0000 From: "Theodore A. Roth" X-X-Sender: roth@knuth.amplepower.com To: Andrew Cagney cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] initialize err variable in load_section_callback() In-Reply-To: <4176A188.1030904@gnu.org> Message-ID: References: <4176A188.1030904@gnu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-10/txt/msg00346.txt.bz2 On Wed, 20 Oct 2004, Andrew Cagney wrote: > Theodore A. Roth wrote: > > Hi, > > > > I just encountered a problem with using the "load" command with a remote > > avr target. The first packet would be sent to the remote target and then > > gdb would just give up with this error message: > > > > (gdb) load > > Loading section .text, size 0x1f8 lma 0x0 > > Sending packet: $M0,a:0c9446000c9463000c94#d7...Ack > > Packet received: OK > > Memory access error while loading section .text. > > > > It looks like load_section_callback() in symfile.c is assuming that a > > call to target_write_memory_partial() will set the err variable. > > Unfortunately, that is not a valid assumption. > > > > The attached patch got things working again, but this feels like a hack > > to me since target_write_memory_partial() should really be setting err > > to a sane value before returning. > > > > Patch is against today's cvs mainline. > > Here's the contract: > /* 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. */ > So the bug is further down the target stack. Both target_write_memory_partial() and target_read_memory_partial() break that contract then: 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); else return target_xfer_memory_partial (memaddr, buf, len, 1, err); } If target_xfer_partial_p() returns true (which the avr port does), then err is never set and the caller will see garbage if it didn't initialize err. Should the return value of the target_xfer_partial() call be checked, or should err just be blindly see to zero? --- Ted Roth PGP Key ID: 0x18F846E9 Jabber ID: troth@jabber.org