From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6810 invoked by alias); 9 Nov 2011 15:25:31 -0000 Received: (qmail 6791 invoked by uid 22791); 9 Nov 2011 15:25:28 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 15:24:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id ADECD2BB3AF; Wed, 9 Nov 2011 10:24:53 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zk2xn+PC4DM3; Wed, 9 Nov 2011 10:24:53 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7E6762BB0AE; Wed, 9 Nov 2011 10:24:53 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 2EE0A145615; Wed, 9 Nov 2011 10:24:41 -0500 (EST) Date: Wed, 09 Nov 2011 15:25:00 -0000 From: Joel Brobecker To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] windows-nat: Decode system error numbers Message-ID: <20111109152441.GN14508@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-11/txt/msg00227.txt.bz2 > and as it stands this is printed by the debuggee GDB: > > error return .../gdb/windows-nat.c:2312 was 6 > > but with the patch applied a proper error message is produced instead: > > error return .../gdb/windows-nat.c:2332 was: The handle is invalid. (6) This is nice, I like it. > This code builds and works as manually verified above; these errors > never trigger in the test suite so that doesn't really cover it -- my > understanding is they are not meant to trigger unless GDB or the > system is malfunctioning for some reason. I don't know of any way to force the triggering of these errors under "normal" circumstances either. But I did notice that we get them occasionally during our testsuite nightly run, with an error number 5 (permissing denied kind of thing?). This happened when trying to kill the inferior, for instance. It's very hard to reproduce, very rare and random, so I've never been able to get to the bottom of it. And the only hints I got on the web was that Borland had the same problem, and that they "fixed" it. Since I could not observe any anomaly besides the error message (inferior was killed as expected, for instance), I was left wondering whether Borland just disabled the error message... > 2011-11-09 Maciej W. Rozycki > > gdb/ > * windows-nat.c (check): Decode the error number retrieved with > GetLastError. A Windows maintainer can approve your code. I looked at the code, and nothing really jumped at me, except maybe the fact that you decrement size and use it change one element in buf at the same time. Personally, I'm not fond of these practices in general, but I can live with that in this case. -- Joel