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 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


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