Re: Using gdb with Borland's free compiler?

Re: Using gdb with Borland's free compiler?

[Michael Elizabeth Chastain]

Hello,

MinGW is not even one of our supported platforms; you would have to
to talk to the MiNGW folks about that.

I don't know of anyone using gdb + borland on Windows.
You would be breaking new territory here.

For windows, we have Cygwin with gcc, and djgpp running directly.

This is not very helpful, I know, but that's the situation.

Michael C
GDB QA Guy

Re: Using gdb with Borland's free compiler?

[Andrew Cagney]

> Hello,
> 
> MinGW is not even one of our supported platforms; you would have to
> to talk to the MiNGW folks about that.

Given the regular MinGW questions, perhaphs it should be?

> I don't know of anyone using gdb + borland on Windows.
> You would be breaking new territory here.
> 
> For windows, we have Cygwin with gcc, and djgpp running directly.
> 
> This is not very helpful, I know, but that's the situation.
> 
> Michael C
> GDB QA Guy
> 

Re: Using gdb with Borland's free compiler?

[Chris Johns]

Andrew Cagney wrote:
> 
> Given the regular MinGW questions, perhaphs it should be?
> 

I am currently looking at the MinGW patch. It has some interesting 
changes that I am sure can be sorted out. I am not a Windows user and my 
interest is cross gdb using MinGW. This means I know little about the 
support for debugging MinGW programs and Windows APIs.

-- 
  Chris Johns, cjohns at cybertec.com.au

Re: Using gdb with Borland's free compiler?

[Christopher Faylor]

On Mon, Sep 29, 2003 at 09:23:29AM -0400, Andrew Cagney wrote:
>>MinGW is not even one of our supported platforms; you would have to
>>to talk to the MiNGW folks about that.
>
>Given the regular MinGW questions, perhaphs it should be?

If wishes were horses...

Someone actually has to do the work.  I'll certainly review it but I'm not
going to do it.

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.

The alternative is to fix readline, fix bfd, and make many other
accommodations for a non-UNIX MinGW environment.

As far as Borland is concerned, I would be surprised if it used a
debugging format that gdb knows about so there would be another hurdle
to getting it working.  It would be wonderful to have gdb understand
MSVC windows debug format, though.

cgf

Re: Using gdb with Borland's free compiler?

[Eli Zaretskii]

> Date: Tue, 30 Sep 2003 20:07:53 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> 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.

Should be easily doable by following the trail of the DJGPP port.  In
fact, it's possible that just by adding to filenames.h definitions
suitable for Cygwin would do, since the rest of GDB's sources is
supposedly already portable wrt this aspect.

Re: Using gdb with Borland's free compiler?

[Joel Brobecker]

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

ACT's two cents...
-- 
Joel

Re: Using gdb with Borland's free compiler?

[Christopher Faylor]

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

Re: Using gdb with Borland's free compiler?

[Andrew Cagney]

> Andrew Cagney wrote:
> 
> Given the regular MinGW questions, perhaphs it should be?
> 
> 
> I am currently looking at the MinGW patch. It has some interesting changes that I am sure can be sorted out. I am not a Windows user and my interest is cross gdb using MinGW. This means I know little about the support for debugging MinGW programs and Windows API

It might be prudent to not look at the existing patch too hard.  You'll 
need to be able to sign a document stating that what you contribute is 
your own work ....

Alternatively, you could use this list as an audit trail and explain 
what needs to be done.

Andrew

Re: Using gdb with Borland's free compiler?

[Chris Johns]

Andrew Cagney wrote:
> 
> It might be prudent to not look at the existing patch too hard.  You'll 
> need to be able to sign a document stating that what you contribute is 
> your own work ....
> 

I do not know the Win32 API so makes this a little more effort than I can spare. I 
have asked about ths history of the patch on the MinGW list.

> Alternatively, you could use this list as an audit trail and explain 
> what needs to be done.

Not sure I understand what you mean. Is a list of the current patch changes ok ?

I was planing on breaking down the patch and sending them to the gdb patches list.

-- 
  Chris Johns, cjohns at cybertec . com . au

Re: Using gdb with Borland's free compiler?

[Christopher Faylor]

On Thu, Oct 02, 2003 at 01:44:40PM +1000, Chris Johns wrote:
>Andrew Cagney wrote:
>>It might be prudent to not look at the existing patch too hard.  You'll
>>need to be able to sign a document stating that what you contribute is
>>your own work ....
>
>I do not know the Win32 API so makes this a little more effort than I
>can spare.  I have asked about ths history of the patch on the MinGW
>list.
>
>>Alternatively, you could use this list as an audit trail and explain
>>what needs to be done.
>
>Not sure I understand what you mean.  Is a list of the current patch
>changes ok ?
>
>I was planing on breaking down the patch and sending them to the gdb
>patches list.

You can't really do that unless you are the author of the patches, though.

cgf

Re: Using gdb with Borland's free compiler?

[Chris Johns]

Christopher Faylor wrote:
> 
> You can't really do that unless you are the author of the patches, though.
> 

Sure. I was hoping the author was part of the MinGW team and so the 
history could be proven. I have asked on the MinGW user list but so far 
nothing has appeared. I assume this is ok. Is it ?

It looks like this is about as far as I can take the MinGW work.

This is what I have found.

The major part of the work is readline. The display and input 
interfacing to Win32, some code to read directories and various ifdefs 
for interfaces not supported by MinGW.

The BFD change is minor. A few lines in opncls.c to detect if an fd has 
been opened as read only or read/write.

The changes needed for GDB are:

  Headers in config to add mingw32 as a target plus configure.host,
  and configure.tgt change.

  Changes to configure.in.

  Change 'struct environ' to 'struct gdb_environ' as mingw has
  'environ' in a system header file as a '#define'.

  Change event-loop.c to support Win32 handles for mingw32.

  Added missing POSIX modes to gdb_stat.h plus minor changes in
  remote-fileio.c due to a different 'struct stat'. (*)

  Added support for ser-tcp over winsock2 for target tcp. (*)

  Support for mingw in win32-nat.c.

  Small number of minor changes, eg missing SIGQUIT, no fork
  check in top.c.


(*) I have added these.

-- 
  Chris Johns, cjohns at cybertec.com.au

Re: Using gdb with Borland's free compiler?

[Andrew Cagney]

>  Headers in config to add mingw32 as a target plus configure.host,
>  and configure.tgt change.

FYI, there are three largely orthogonal problems here:

- host support (so it can be run on mingw)
Missing fork.  Struct problems.  This should be largely handled by 
configure.in.

- native support (so it can debug mingw programs)
The win32-nat.c changes.

- architecture support (so it can handle mingw ISA/ABI issues)
tm-*.h *.mt, *-tdep.c.

Note that, for the last one, GDB's been restructured so that the  tm-*.h 
file is no longer needed.  If the patches still have a tm-*.h file then 
`why' is something to investigate further.

>  Changes to configure.in.
> 
>  Change 'struct environ' to 'struct gdb_environ' as mingw has
>  'environ' in a system header file as a '#define'.

If nothing else, bug report this.  Fixing it should be a no-op.

>  Change event-loop.c to support Win32 handles for mingw32.
> 
>  Added missing POSIX modes to gdb_stat.h plus minor changes in
>  remote-fileio.c due to a different 'struct stat'. (*)
> 
>  Added support for ser-tcp over winsock2 for target tcp. (*)

As a ser-winsock2 file or as mods to ser-tcp?

>  Support for mingw in win32-nat.c.
> 
>  Small number of minor changes, eg missing SIGQUIT, no fork
>  check in top.c.

Andrew

Re: Using gdb with Borland's free compiler?

[Chris Johns]

Andrew Cagney wrote:
> 
>>  Headers in config to add mingw32 as a target plus configure.host,
>>  and configure.tgt change.
> 
> 
> FYI, there are three largely orthogonal problems here:
> 

How does readline fit in ?

> - host support (so it can be run on mingw)
> Missing fork.  Struct problems.  This should be largely handled by 
> configure.in.
> 

Yes. Currently this is handled by a defined in defs.h, CANT_FORK. The file utils.c 
has a fork() call but no check.

> - native support (so it can debug mingw programs)
> The win32-nat.c changes.

This need a win32 person to look at this.

>
> - architecture support (so it can handle mingw ISA/ABI issues)
> tm-*.h *.mt, *-tdep.c.
> 

Can mingw32-tdep.c have misc type functions such as gettimeofday if the mingw runtime 
does not support it ?

> Note that, for the last one, GDB's been restructured so that the  tm-*.h 
> file is no longer needed.  If the patches still have a tm-*.h file then 
> `why' is something to investigate further.

Ok.

> 
>>  Changes to configure.in.
>>
>>  Change 'struct environ' to 'struct gdb_environ' as mingw has
>>  'environ' in a system header file as a '#define'.
> 
> 
> If nothing else, bug report this.  Fixing it should be a no-op.
> 

Will do.

>>  Change event-loop.c to support Win32 handles for mingw32.
>>
>>  Added missing POSIX modes to gdb_stat.h plus minor changes in
>>  remote-fileio.c due to a different 'struct stat'. (*)
>>
>>  Added support for ser-tcp over winsock2 for target tcp. (*)
> 
> 
> As a ser-winsock2 file or as mods to ser-tcp?
> 

I added ser-mingw.c and changed ser-tcp.c to remove references to ser-unix.c 
functions. I then added a call to a new funtion 'ser_platform_tcp_init (ops)' to 
_initialize_ser_tcp and added ser_platform_tcp_init to ser-unix.c.

It could be ser-win32.c rather than ser-mingw.c.

Looking at this again I wonder if net_open and net_close should be public 
(ser_tcp_open/ser_tcp_close) and _initialise_ser_tcp should be in ser-unix.c. Same 
for ser-pipe.c.

This means configure selects either ser-unix.c or ser-mingw.c.

The net_open code needs a mingw (win32?) specific call to start the winsock dll. 
Shame but I see no simple solution to this.

-- 
  Chris Johns, cjohns at cybertec . com . au

Using gdb with Borland's free compiler?

[Vivi Orunitia]

Hi all,

The subject pretty much states what I want to ask. Is it possible to use 
gdb to debug programs that's compiled with borland's free commandline 
compiler? If possible, how can I do it?

Here's what I have tried so far. I downloaded the latest version of gdb 
source but couldn't figure out how to build it using the borland compiler 
I'm using. The ./configure doesn't seem to work when using a windows 
platform. However, I was able to find a pre-built binary of gbd over at 
the MinGW site and downloaded that instead, but it wasn't the latest 
version though(I believe it was 5.2.1 or something). GDB runs but as it 
stands now, I don't think it can recognize any of the debug symbols 
generated by borland's compiler.

If someone could just walk me through this on getting it to work or on 
how to build it I would greatly appreciate it. This is of course assuming 
that what I want to do is possible. A quick search on the mailing-list 
hasn't turn up anything relating to what I'm looking to do

Thanks