From: Daniel Jacobowitz <dan@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] defs.h: Define GDB_DEFAULT_TARGET_[WIDE_]CHARSET for Cygwin and MingW builds
Date: Wed, 03 Mar 2010 17:08:00 -0000 [thread overview]
Message-ID: <20100303170645.GA23545@caradoc.them.org> (raw)
In-Reply-To: <m3r5o2bagj.fsf@fleche.redhat.com>
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
next prev parent reply other threads:[~2010-03-03 17:08 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-28 13:05 Corinna Vinschen
2010-02-28 14:29 ` Daniel Jacobowitz
2010-02-28 15:03 ` Corinna Vinschen
2010-02-28 18:48 ` Daniel Jacobowitz
2010-02-28 19:22 ` Corinna Vinschen
2010-02-28 22:27 ` Daniel Jacobowitz
2010-03-01 10:31 ` Corinna Vinschen
2010-03-01 17:11 ` Eli Zaretskii
2010-03-01 17:28 ` Corinna Vinschen
2010-03-01 17:21 ` Tom Tromey
2010-03-01 17:23 ` Daniel Jacobowitz
2010-03-01 17:27 ` Corinna Vinschen
2010-03-01 17:31 ` Corinna Vinschen
2010-03-01 19:25 ` Tom Tromey
2010-03-01 19:31 ` Daniel Jacobowitz
2010-03-01 20:06 ` Corinna Vinschen
2010-03-01 20:44 ` Eli Zaretskii
2010-03-01 21:50 ` Daniel Jacobowitz
2010-03-02 10:44 ` Corinna Vinschen
2010-03-02 13:54 ` Daniel Jacobowitz
2010-03-02 14:13 ` Corinna Vinschen
2010-03-02 15:03 ` Daniel Jacobowitz
2010-03-02 17:43 ` Corinna Vinschen
2010-03-02 17:59 ` Tom Tromey
2010-03-02 18:22 ` Corinna Vinschen
2010-03-02 18:28 ` Corinna Vinschen
2010-03-02 22:55 ` Tom Tromey
2010-03-02 22:57 ` Tom Tromey
2010-03-03 10:16 ` Corinna Vinschen
2010-03-03 10:41 ` Corinna Vinschen
2010-03-03 10:59 ` Corinna Vinschen
2010-03-03 16:26 ` Tom Tromey
2010-03-03 10:16 ` Corinna Vinschen
2010-03-03 16:25 ` Tom Tromey
2010-03-03 16:46 ` Corinna Vinschen
2010-03-05 8:55 ` Charles Wilson
2010-03-03 21:15 ` Tom Tromey
2010-03-04 9:34 ` Corinna Vinschen
2010-03-04 15:24 ` Christopher Faylor
2010-03-04 15:38 ` Corinna Vinschen
2010-03-03 17:08 ` Daniel Jacobowitz [this message]
2010-03-03 17:22 ` Corinna Vinschen
2010-03-03 17:27 ` Corinna Vinschen
2010-03-03 17:33 ` Daniel Jacobowitz
2010-03-03 17:42 ` Eli Zaretskii
2010-03-03 18:00 ` Corinna Vinschen
2010-03-03 18:05 ` Daniel Jacobowitz
2010-03-03 18:22 ` Corinna Vinschen
2010-03-03 19:39 ` Daniel Jacobowitz
2010-03-03 20:16 ` Eli Zaretskii
2010-03-03 20:26 ` Daniel Jacobowitz
2010-03-03 21:08 ` Tom Tromey
2010-03-01 17:12 ` Tom Tromey
2010-03-01 17:21 ` Daniel Jacobowitz
2010-03-01 17:28 ` Tom Tromey
2010-03-01 17:50 ` Corinna Vinschen
2010-02-28 16:56 ` Eli Zaretskii
2010-02-28 17:05 ` Corinna Vinschen
2010-02-28 17:45 ` Eli Zaretskii
2010-02-28 17:52 ` Corinna Vinschen
2010-02-28 18:11 ` Corinna Vinschen
2010-02-28 18:59 ` Eli Zaretskii
2010-02-28 19:23 ` Corinna Vinschen
2010-02-28 18:59 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100303170645.GA23545@caradoc.them.org \
--to=dan@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox