This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] defs.h: Define GDB_DEFAULT_TARGET_[WIDE_]CHARSET for Cygwin and MingW builds
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