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

Daniel Jacobowitz
2010-03-02T15:03:43Z

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.

--
Daniel Jacobowitz
CodeSourcery