From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: Re: Using gdb with Borland's free compiler?
Date: Wed, 01 Oct 2003 13:10:00 -0000 [thread overview]
Message-ID: <20031001131015.GA32515@redhat.com> (raw)
In-Reply-To: <20031001055806.GB933@gnat.com>
On Tue, Sep 30, 2003 at 10:58:06PM -0700, Joel Brobecker wrote:
>> So far the basic problem with just using cygwin's gdb seems to be lack
>> of understanding of MS-DOS paths. It should be doable to fix up gdb to
>> understand those better in the cygwin port, if that was the only
>> problem.
>
>This part is actually (almost) easy. By simply defining a few macros
>that do the conversion between DOS and cygwin formats, we managed to
>get a cygwin GDB that talks DOS paths. We never submitted these patches
>for approval because we felt they would never be accepted. After all,
>when you use a cygwin debugger, chances are you prefer to see cygwin
>paths. Maybe we could compromise by using a two-state variable or
>a boolean variable. We would have cygwin paths by default, but changing
>the setting of this variable would allow you to get DOS paths instead?
I have the same policy with gdb that I do with cygwin as far as DOS paths
are concerned. I certainly don't want to make them hard to use but if
there are problems using them, I'm not going to be first in line to
fix the problem.
I thought that someone had actually made some changes to gdb a while ago
to get things working correctly with DOS paths but this isn't the kind
of thing that I routinely check.
>I say it's almost easy because we tested these changes against GNAT,
>which is a migw compiler. We never stress-tested it against a cygwin
>compiler for instance.
>
>The real annoying problem that we have been facing with a cygwin GDB
>is its dependence on the cygwin dll. That makes distribution of GDB
>binaries more challenging, because now we need to distribute this DLL
>too. All is fine when the customer host doesn't use cygwin, but it
>becomes potentially problematic when he does and the DLL versions
>don't match...
And, of course, it requires you to distribute source code for the cygwin
DLL itself. FWIW, newer cygwin DLLs are always guaranteed to work with
older binaries, so it should be just a matter of checking the version
and not installing the older version.
(And, nearly every time I say this, someone says "I'm pretty sure there
was some problem with a newer DLL but I don't remember what it was.")
cgf
next prev parent reply other threads:[~2003-10-01 13:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-28 23:24 Michael Elizabeth Chastain
2003-09-29 13:26 ` Andrew Cagney
2003-09-30 22:46 ` Chris Johns
2003-10-01 14:49 ` Andrew Cagney
2003-10-02 3:44 ` Chris Johns
2003-10-02 13:44 ` Christopher Faylor
2003-10-02 22:43 ` Chris Johns
2003-10-02 23:12 ` Andrew Cagney
2003-10-03 2:56 ` Chris Johns
2003-10-01 0:07 ` Christopher Faylor
2003-10-01 5:03 ` Eli Zaretskii
2003-10-01 5:58 ` Joel Brobecker
2003-10-01 13:10 ` Christopher Faylor [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-09-28 22:23 Vivi Orunitia
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=20031001131015.GA32515@redhat.com \
--to=cgf@redhat.com \
--cc=gdb@sources.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