From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7352 invoked by alias); 19 Oct 2009 04:46:55 -0000 Received: (qmail 7342 invoked by uid 22791); 19 Oct 2009 04:46:53 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f175.google.com (HELO mail-px0-f175.google.com) (209.85.216.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 04:46:49 +0000 Received: by pxi5 with SMTP id 5so1816898pxi.12 for ; Sun, 18 Oct 2009 21:46:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.39 with SMTP id d39mr273400wfj.223.1255927608089; Sun, 18 Oct 2009 21:46:48 -0700 (PDT) In-Reply-To: <4ADB9759.7060305@vmware.com> References: <4ADB9759.7060305@vmware.com> From: Hui Zhu Date: Mon, 19 Oct 2009 04:46:00 -0000 Message-ID: Subject: Re: Seems like a bug in target_read_stack / dcache_xfer_memory? To: Michael Snyder Cc: "gdb-patches@sourceware.org" , "drow@false.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00423.txt.bz2 I just want talk to you about it. + if (target_read_memory (entry->u.mem.addr, mem, entry->u.mem.l= en)) + { + entry->u.mem.mem_entry_not_accessible =3D 1; + if (record_debug) + warning (_("Process record: error reading memory at " + "addr =3D %s len =3D %d."), + paddress (gdbarch, entry->u.mem.addr), + entry->u.mem.len); + } + else + { + if (target_write_memory (entry->u.mem.addr, + record_get_loc (entry), + entry->u.mem.len)) Maybe we need change it to: if (target_read_memory (entry->u.mem.addr, mem, entry->u.mem.len) <=3D 0) if (target_write_memory (entry->u.mem.addr, + record_get_loc (entry), + entry->u.mem.len) <=3D 0) Thanks, Hui On Mon, Oct 19, 2009 at 06:31, Michael Snyder wrote: > OK, this is right at the hairy edge of my understanding, and I > admit up front that I did not carefully follow the email thread, but... > > There was this email thread about reading beyond the stack, and > using dcache, which I did not follow carefully. =A0And now I think > I'm running into it. > > Short version: =A0code in memory_xfer_partial looks like this: > > 1280 =A0 =A0 =A0 =A0 =A0 =A0/* FIXME drow/2006-08-09: If we're going to p= reserve const > 1281 =A0 =A0 =A0 =A0 =A0 =A0 =A0 correctness dcache_xfer_memory should ta= ke readbuf and > 1282 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writebuf. =A0*/ > 1283 =A0 =A0 =A0 =A0 =A0 =A0res =3D dcache_xfer_memory (ops, target_dcach= e, memaddr, > 1284 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0(void *) writebuf, > 1285 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0reg_len, 1); > 1286 =A0 =A0 =A0 =A0 =A0if (res <=3D 0) > 1287 =A0 =A0 =A0 =A0 =A0 =A0return -1; > > I think that's wrong. =A0I think it needs to test for "res =3D=3D 0". > > Comment at dcache_xfer_memory says: > > =A0The meaning of the result is the same as for target_write > > (Gripe: someone please fix that comment. =A0Why should I have to > go find another function in another file to find out what this > function returns?) > > So the comment at target_write says... =A0oh wait! =A0There is no > comment at target_write! =A0I'm afraid I'm going to have to start > getting grumpy now... > > Well, that returns target_write_with_progress. =A0The comment > there makes no mention of the return value. =A0But it returns > target_write_partial. =A0STILL no comment about the return value. > But this returns target_xfer_partial. =A0GUESS WHAT? > > Well, this returns memory_xfer_partial, which is right back > where I started. =A0And *its* comment says: > > =A0The arguments and return > =A0value are just as for target_xfer_partial > > Ummm, =A0come on guys. =A0Its Sunday and I've had a long day. > Joke's getting old. =A0Whoever took the comments, please put them back. > > Anyway, I don't even remember now how I figured this out, but > I *THINK* what all these guys return is either 0 for success, > or an errno value less than zoro. > > And if that's true, then line 1286 up there needs to bail out > on zero and let the other target stack methods have a chance > to read the memory. > > Eh? > > We now return you to the nice Michael. =A0 ;-) > > Daniel, you're not the target, you're only Cc:ed because your > name is in the one comment that I *did* find. > > >