From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31669 invoked by alias); 2 Mar 2010 17:43:29 -0000 Received: (qmail 31654 invoked by uid 22791); 2 Mar 2010 17:43:28 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Tue, 02 Mar 2010 17:43:23 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5D3656D42F5; Tue, 2 Mar 2010 18:43:20 +0100 (CET) Date: Tue, 02 Mar 2010 17:43:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [RFA] defs.h: Define GDB_DEFAULT_TARGET_[WIDE_]CHARSET for Cygwin and MingW builds Message-ID: <20100302174320.GA1425@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <20100301173054.GD5683@calimero.vinschen.de> <20100301193126.GA9416@caradoc.them.org> <83eik34vr8.fsf@gnu.org> <20100301215033.GB17815@caradoc.them.org> <20100302104358.GA26083@calimero.vinschen.de> <20100302135405.GA16596@caradoc.them.org> <20100302141324.GA27721@calimero.vinschen.de> <20100302150323.GA20342@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100302150323.GA20342@caradoc.them.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-03/txt/msg00059.txt.bz2 On Mar 2 10:03, Daniel Jacobowitz wrote: > On Tue, Mar 02, 2010 at 03:13:24PM +0100, Corinna Vinschen wrote: > > It looks to me as if a call to get_current_arch() in target_charset() > > is the way to go. Otherwise, I don't see how this can be set up. > > The problem here are the various places which call the target_charset() > > function. The one call in c-lang.c, function charset_for_string_type() > > looks simple, but the calls in util.c and python/py-utils.c look > > pretty tricky. Or can I just refer to get_current_arch() in these > > places? > > We're only supposed to call get_current_arch in the functions that > implement UI commands. Everything else has to be passed a relevant > architecture. This is a lot of hassle, but it's the way the design > worked out. > > The one in c-lang.c is easy. charset_for_string_type takes a byte > order already; wherever its callers get a byte order, they will get it > from the gdbarch, so just pass the gdbarch instead. I checked, both > eventual callers have one available > > For utils, both calls come through parse_escape. Since this has more > calls, obviously, it's more of a mess :-( > > * echo_command is a command and can use get_current_arch. > > * Ditto for do_setshow_command. > > * Um, I guess the same is true for mi_parse_argv, but at this point I > think something's wrong infrastructurally. Why do we care about the > target charset when decoding MI commands? C has c_parse_escape, which > always uses the host charset, and pushes conversion to the target > charset elsewhere... at least, this will make the problem visible at > the call site instead of buried. > > * That leaves the three yylex definitions, for Java, ObjC, and Pascal. > For those, use parse_gdbarch. Sorry, but I have to step down from patching this. There's too much code involved I never had a look into and this is getting way over my head for the simple seeming task of just setting a sane default for a native Cygwin GDB. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat