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

Corinna Vinschen
2010-03-03T10:41:07Z

On Mar 3 11:16, Corinna Vinschen wrote:
> On Mar 2 15:57, Tom Tromey wrote:
> > >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
> >
> > Tom> Here's a patch, please let me know what you think.
> >
> > Tom> 2010-03-02 Tom Tromey <tromey@redhat.com>
> > Tom> * utils.c (host_char_to_target): Add 'gdbarch' argument.
> >
> > [...]
> >
> > Oops! I took some code from Corinna's earlier patch but then neglected
> > to put her name on the ChangeLog entry. I've corrected that locally.
>
> No worries. I tested your code on the latest Cygwin release and it
> works fine.

However, there's a problem in GDB which spoils the effort a bit.

When GDB is started, setlocale() is called from captured_main().
Afterwards, _initialize_charset() and, in turn, nl_langinfo() is
called, and the pointer returned by nl_langinfo(CODESET) is
stored as the name of the codeset.
So the codeset name is not copied into a safe storage area here,
just the pointer is memorized.

Later, while captured_main() is still initializing GDB, the interp_set()
function is called, which calls tui_init(), which in turn initializes
readline. Readline calls setlocale(). Oops. The old pointer to
nl_langinfo(CODESET) might not be valid anymore afterwards.

See the Linux manpage for nl_langinfo:

RETURN VALUE
[...]
This pointer may point to static data that may be overwritten on the
next call to nl_langinfo() or setlocale(3).

So, does anything speak against copying the codeset name into some
local storage, rather than just storing the pointer returned by
nl_langinfo?

Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat