From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7460 invoked by alias); 3 Mar 2010 17:08:50 -0000 Received: (qmail 7257 invoked by uid 22791); 3 Mar 2010 17:08:48 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Mar 2010 17:08:42 +0000 Received: (qmail 18495 invoked from network); 3 Mar 2010 17:08:41 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Mar 2010 17:08:41 -0000 Date: Wed, 03 Mar 2010 17:08:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFA] defs.h: Define GDB_DEFAULT_TARGET_[WIDE_]CHARSET for Cygwin and MingW builds Message-ID: <20100303170645.GA23545@caradoc.them.org> Mail-Followup-To: Tom Tromey , gdb-patches@sourceware.org References: <20100228184749.GA17375@caradoc.them.org> <20100228192159.GP5683@calimero.vinschen.de> <20100228222702.GC29360@caradoc.them.org> <20100301103125.GB9730@calimero.vinschen.de> <20100301173054.GD5683@calimero.vinschen.de> <20100301193126.GA9416@caradoc.them.org> 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: 2010-03/txt/msg00102.txt.bz2 On Tue, Mar 02, 2010 at 03:55:08PM -0700, Tom Tromey wrote: > This patch nearly works -- it regresses on a Python test that looks at > gdb.parameter('target-charset') directly and then gets confused by > "auto". I think the only solution for this is to add a new Python API. > (It would be easy enough to just hack the test case somehow -- but the > libstdc++ printers use this same idiom, so a real solution is needed.) I agree. This is a general problem: I had the same issue with gdb.parameter('endian'). It'd be nice to have a standard way to query the effective value of the parameter! > I wasn't sure where to put the Cygwin override; I took Daniel's > suggestion of i386_cygwin_init_abi; but Corinna's earlier patches > changed all Windows targets, not just Cygwin, and I didn't see a good > place to do that. This is an interesting mess. We have both a Windows target issue and a Windows native issue. Handling Windows has become a separate issue; I don't see any need to wait on this patch which fixes Cygwin. What I'd suggest: create an i386-windows-tdep.c. Define a new OSABI for Windows, and sniff for it. Then you have an i386_windows_init_abi and you can put things there. Unfortunately, the Cygwin OSABI sniffer is going to be a problem for this. It isn't actually sniffing for Cygwin binaries, it's sniffing for pei-i386 objects. Is there a practical way to do this right? If we can rely on the cygwin DLL being in the image header, we could have a single sniffer (rename it to i386_windows_osabi_sniffer, move it to i386-windows-tdep.c) that returns GDB_OSABI_WINDOWS if not linked to Cygwin and GDB_OSABI_CYGWIN if linked to Cygwin. I know it's easy to get this information out of a Windows executable. I don't know if there's an easy way to get BFD to tell it to you. It doesn't really look like it is. It's printed from objdump -p (bfd/peXXigen.c:pe_print_idata, I think). Or there may be some better way. Corinna, do you know? Is there some other marker to distinguish a Cygwin executable besides linking to the DLL? Anyway, once you've got sniffers that distinguish Windows from Cygwin binaries, the rest is easy. In the Windows implementation of auto_charset, if GetACP is available, call it. That's not 100% right, in that you could *theoretically* be debugging a Windows binary on a remote system with a different charset, but it's all the work I think we should do for a default. At this point, I think it's correct to call GetACP even for a Cygwin GDB. The GDB might be a Cygwin executable but the program being debugged might not be, and it will use the non-Cygwin Windows settings. -- Daniel Jacobowitz CodeSourcery