From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13009 invoked by alias); 1 Jul 2009 20:12:01 -0000 Received: (qmail 12998 invoked by uid 22791); 1 Jul 2009 20:12:00 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jul 2009 20:11:54 +0000 Received: (qmail 21117 invoked from network); 1 Jul 2009 20:11:51 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Jul 2009 20:11:51 -0000 From: Pedro Alves To: danny.backx@scarlet.be Subject: Re: Patch : gdbserver get_image_name on CE Date: Wed, 01 Jul 2009 20:12:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <1244903385.20290.9.camel@pavilion> <200906302258.00604.pedro@codesourcery.com> <1246473648.15871.201.camel@pavilion> In-Reply-To: <1246473648.15871.201.camel@pavilion> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907012113.06018.pedro@codesourcery.com> 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-07/txt/msg00043.txt.bz2 On Wednesday 01 July 2009 19:40:48, Danny Backx wrote: > > And you never did explain what was broken with get_image_name > > that you had to fix, as I asked $n emails ago, right? > > Err. I am almost certain that the return value of GetProcessMemory isn't > a reliable way to verify success. Thanks! You know that I couldn't guess what you were thinking or were almost certain, right? > Its final parameter is. Or at least > that is my experience. Of course, MSDN docs don't mention this. I'm not convinced of this. I think you must stumbling on some other bug, or a bug in the device. MSDN docs mention this: http://msdn.microsoft.com/en-us/library/ms680553(VS.85).aspx "Reads data from an area of memory in a specified process. The entire area to be read must be accessible or the operation fails." That's why we read data bytewise to know the length or the string first. So what you're doing may work for you, but it may fail for someone else (other device, binary, etc.). It makes *no sense* to be able to read the data in one go, but not be able to read it bytewise. This would mean that ReadProcessMemory could fail in many other circumstances --- it is used when gdb wants to read memory of off the inferior... So, please, now that you have a gdbserver that works, debug gdbserver with gdbserver, and step through that routine (the old implementation), and see where/why it is failing. Posting a log of that debug session showing the failure would do wonders in convincing me where is the bug. Hey, you may even have a compiler bug, right? > I tested this on ARM and on i386. Real devices, not emulators. The ARM > implementation worked as it was, and continued to work after my fix. The > i386 version didn't work before, does work after the fix. > > Is this sufficient explanation? I'm not convinced yet. :-) I'll see about cleaning up the bits of your patch that are OK and apply them (you still aren't following the code conventions). Then we can focus on just this bit. -- Pedro Alves