This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] defs.h: Define GDB_DEFAULT_TARGET_[WIDE_]CHARSET for Cygwin and MingW builds


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]