Path handling bug in GDB included with MingW 3.1.0-1

Path handling bug in GDB included with MingW 3.1.0-1

[Michael Stather]

Hi,

I´ve seen a strange bug in the GDB that´s included with MingW32 3.1.0-1
under WinXP pro:
I´ve a little program which has only 2 lines.
Assuming it is in c:\p, I compile it, and then I set a breakpoint like this:

g++ -g -o p.exe c:/p/p.cpp -mwindows
gdb
break "c:/p/p.cpp:7"
Run

gdb won´t stop at the breakpoint.
however if I do:

cd c:\m
g++ -g -o p.exe p.cpp -mwindows
gdb
break "p.cpp:7"
run

it breaks correctly.
I think there´s something broken within the path handling
Is this bug already fixed or am I doing something wrong here? Regards
Michael Stather

Re: Path handling bug in GDB included with MingW 3.1.0-1

[Christopher Faylor]

[reply-to set]
On Sun, Oct 05, 2003 at 11:48:35PM +0200, Michael Stather wrote:
>I?ve seen a strange bug in the GDB that?s included with MingW32 3.1.0-1
>under WinXP pro:
>I?ve a little program which has only 2 lines.
>Assuming it is in c:\p, I compile it, and then I set a breakpoint like this:
>
>g++ -g -o p.exe c:/p/p.cpp -mwindows
>gdb
>break "c:/p/p.cpp:7"
>Run
>
>gdb won?t stop at the breakpoint.
>however if I do:
>
>cd c:\m
>g++ -g -o p.exe p.cpp -mwindows
>gdb
>break "p.cpp:7"
>run
>
>it breaks correctly.
>I think there?s something broken within the path handling
>Is this bug already fixed or am I doing something wrong here? Regards

I'm sorry but you have to go to mingw.org to get support on this version
of gdb.  There are local patches applied to it and it is not supported
by this mailing list.

Re: Path handling bug in GDB included with MingW 3.1.0-1

[Eli Zaretskii]

> From: "Michael Stather" <michaelstather@nuzi.de>
> Date: Sun, 5 Oct 2003 23:48:35 +0200
> 
> g++ -g -o p.exe c:/p/p.cpp -mwindows
> gdb
> break "c:/p/p.cpp:7"
> Run
> 
> gdb won\x7ft stop at the breakpoint.
> however if I do:
> 
> cd c:\m
> g++ -g -o p.exe p.cpp -mwindows
> gdb
> break "p.cpp:7"
> run
> 
> it breaks correctly.

Sounds like the MinGW port isn't writing leading directories of the
files into the debug info.

Questions:

What is the default debug info format used by the MinGW port of GCC?

Does it help to use -gstabs+ instead of just -g?

Do you see the leading directories of the source file names if you
run "objdump --debug" on the object files?

Re: Path handling bug in GDB included with MingW 3.1.0-1

[Christopher Faylor]

On Tue, Oct 07, 2003 at 11:13:28PM +0200, Eli Zaretskii wrote:
>>From: "Michael Stather" <michaelstather@nuzi.de>
>>Date: Sun, 5 Oct 2003 23:48:35 +0200
>> 
>> g++ -g -o p.exe c:/p/p.cpp -mwindows
>> gdb
>> break "c:/p/p.cpp:7"
>> Run
>> 
>> gdb won\x7ft stop at the breakpoint.
>> however if I do:
>> 
>> cd c:\m
>> g++ -g -o p.exe p.cpp -mwindows
>> gdb
>> break "p.cpp:7"
>> run
>> 
>> it breaks correctly.
>
>Sounds like the MinGW port isn't writing leading directories of the
>files into the debug info.
>
>Questions:
>
>What is the default debug info format used by the MinGW port of GCC?
>
>Does it help to use -gstabs+ instead of just -g?
>
>Do you see the leading directories of the source file names if you
>run "objdump --debug" on the object files?

Do we *really* want to go down the road of supporting a patched gdb
here?  There are people who are familiar with the changes that have gone
into mingw gdb in the mingw mailing list.  For whatever reason, they
have chosen not to spend any time getting their patches back into gdb
proper and do not, apparently, read this mailing list.

I don't see any reason why we should be taking up bandwidth trying to
support what is essentially a gdb fork here.  Do we support Apple's
gdb users here?  I don't think we do and this is a similar issue.

cgf

Re: Path handling bug in GDB included with MingW 3.1.0-1

[Eli Zaretskii]

> Date: Tue, 7 Oct 2003 19:22:34 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> Do we *really* want to go down the road of supporting a patched gdb
> here?  There are people who are familiar with the changes that have gone
> into mingw gdb in the mingw mailing list.  For whatever reason, they
> have chosen not to spend any time getting their patches back into gdb
> proper and do not, apparently, read this mailing list.
> 
> I don't see any reason why we should be taking up bandwidth trying to
> support what is essentially a gdb fork here.

Perhaps there's history to this that I'm not aware of.  All I saw was
a question from a user of a GDB port for which I thought I could
provide some help at a price of a few moments required to write a
short email message.  I don't see the alleged waste of bandwidth as a
real issue here (I doubt that you do, too), and have no idea how
heavily is the MinGW port patched and whether the patch authors
unwillingness to send the patches upstream is something that warrants
a boycott on their users.

For the record, I do see it as a Good Thing to have the MinGW port as
part of the official GDB distro, and if my response was even a small
contribution to that, my time and our bandwidth were well spent.  You
don't win the hearts of people by refusing to answer their questions,
at least in my experience.

[Sorry for being a bit blunt, but I was quite astonished of being
pounced upon for answering a simple request.]

Re: Path handling bug in GDB included with MingW 3.1.0-1

[Christopher Faylor]

On Wed, Oct 08, 2003 at 07:52:21AM +0200, Eli Zaretskii wrote:
>> Date: Tue, 7 Oct 2003 19:22:34 -0400
>> From: Christopher Faylor <cgf@redhat.com>
>> 
>>Do we *really* want to go down the road of supporting a patched gdb
>>here?  There are people who are familiar with the changes that have
>>gone into mingw gdb in the mingw mailing list.  For whatever reason,
>>they have chosen not to spend any time getting their patches back into
>>gdb proper and do not, apparently, read this mailing list.
>>
>>I don't see any reason why we should be taking up bandwidth trying to
>>support what is essentially a gdb fork here.
>
>Perhaps there's history to this that I'm not aware of.  All I saw was a
>question from a user of a GDB port for which I thought I could provide
>some help at a price of a few moments required to write a short email
>message.  I don't see the alleged waste of bandwidth as a real issue
>here (I doubt that you do, too), and have no idea how heavily is the
>MinGW port patched and whether the patch authors unwillingness to send
>the patches upstream is something that warrants a boycott on their
>users.

So it's your assertion that we should support anything with the name
"gdb" in it no matter where it came from?  I thought this mailing list
was for supporting the FSF version of gdb.  Should I have Red Hat gdb
customers send their queries here, too?  Or are we just drawing the line
at commercial customers?

>For the record, I do see it as a Good Thing to have the MinGW port as
>part of the official GDB distro, and if my response was even a small
>contribution to that, my time and our bandwidth were well spent.  You
>don't win the hearts of people by refusing to answer their questions,
>at least in my experience.

This is unrelated to whether it is a good thing to have MinGW as part of
the gdb family.  Again, this is a *gdb fork* we're talking about.  The
best you can do, since you don't have the actual source code, is offer
opinions on what might be happening.  That might be helpful but it also
might lead someone astray.

You could download the mingw patches, of course.  Then you would be
potentially tainted from doing further gdb development but you might
be able to answer questions more definitively.

Since there are people out there who are actually familiar with the
source code in question, it makes sense to redirect queries to them.
This is what I did.  I did it in my capacity as the person responsible
for gdb on Windows.

>[Sorry for being a bit blunt, but I was quite astonished of being
>pounced upon for answering a simple request.]

Imagine my astonishment when as the Windows maintainer I tried to
redirect the questions to the place where they would actually be
answered only to see someone trying to answer the question anyway.
I have been trying on and off for some time to get the MinGW authors to
submit their code to the FSF, mentioning that gdb for mingw won't be
supported until that happens.  If we're going to support it anyway, then
that rather dilutes my argument.

cgf

Re: Support for unofficial GDB (was: Path handling bug in GDB included with MingW 3.1.0-1)

[Eli Zaretskii]

> Date: Wed, 8 Oct 2003 09:43:47 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> So it's your assertion that we should support anything with the name
> "gdb" in it no matter where it came from?

I think we should try to support what we can when we can.  It all
depends on the available time and the necessary effort.  For example,
if someone asks a question about the official GDB, and it turns out
that to answer it I need to invest 2 hours digging into GDB, I'd
probably decide not to help that person.  OTOH, if the answer to a
question takes a minute to write and send, I'd probably do that for
anyone, unless I know that person to be a sworn enemy of GDB.

> Should I have Red Hat gdb customers send their queries here, too?
> Or are we just drawing the line at commercial customers?

It's a free world.  Everybody should decide for themselves where they
draw the line.  I tried to explain mine above; YMMV.  I will never try
to impose my criteria on others, since the support given here is
essentially a volunteer project.

> The best you can do, since you don't have the actual source code, is offer
> opinions on what might be happening.

That's what I did, actually.

> That might be helpful but it also might lead someone astray.

I cannot guarantee I don't lead people astray even when I do have the
full sources.

> Since there are people out there who are actually familiar with the
> source code in question, it makes sense to redirect queries to them.
> This is what I did.  I did it in my capacity as the person responsible
> for gdb on Windows.

It's okay with me to direct people to other relevant forums, but that
doesn't contradict attempts by others to offer their opinions here.  I
don't read the MinGW list, so I couldn't be of help to the redirected
discussion.

Of course, if it's written somewhere in the charter of this list that
questions about MinGW and other unofficial versions should not be
asked here, then I apologize for my ignorance and wasted bandwidth.

> I have been trying on and off for some time to get the MinGW authors to
> submit their code to the FSF, mentioning that gdb for mingw won't be
> supported until that happens.  If we're going to support it anyway, then
> that rather dilutes my argument.

I'm sorry if I (unbeknownst to me) interfered with your efforts, but
offering an opinion of the kind I posted hardly qualifies as
``support''.

Re: Path handling bug in GDB included with MingW 3.1.0-1

[Chris Johns]

Eli Zaretskii wrote:
>>From: "Michael Stather" <michaelstather@nuzi.de>
>>Date: Sun, 5 Oct 2003 23:48:35 +0200
>>
>>g++ -g -o p.exe c:/p/p.cpp -mwindows
>>gdb
>>break "c:/p/p.cpp:7"
>>Run
>>
>>gdb won?t stop at the breakpoint.
>>however if I do:
>>
>>cd c:\m

Not sure if this is suppose to be 'm' or 'p' and if this makes a difference.

>>g++ -g -o p.exe p.cpp -mwindows
>>gdb
>>break "p.cpp:7"
>>run
>>
>>it breaks correctly.
> 
> 
> Sounds like the MinGW port isn't writing leading directories of the
> files into the debug info.
> 

The 5.2.1-1 patch for MinGW stripped a leading '/' from a path for some 
reason.

> Questions:
> 
> What is the default debug info format used by the MinGW port of GCC?

stabs

> 
> Does it help to use -gstabs+ instead of just -g?
> 

No change the trace below.

> Do you see the leading directories of the source file names if you
> run "objdump --debug" on the object files?

I tried the 20030930 snapshot with a new MinGW patch the other day and I 
could set the break point and gdb stopped. I posted this result to the 
MinGW mailing list.

I decided to try gdb 6.0. This is what I have found with a simple hello 
world compiled with:

  > g++ -g -o p p.cpp -mwindows

and gdb run in a cmd box on XP:

  (gdb) info files
  Symbols from "C:\p/p.exe".
  Local exec file:
          `C:\p/p.exe', file type pei-i386.
          Entry point: 0x401000
          0x00401000 - 0x00433300 is .text
          0x00434000 - 0x00435234 is .data
          0x00436000 - 0x0043a9e0 is .bss
          0x0043b000 - 0x0043b7f4 is .idata
  (gdb) b "c:\p/p.cpp:6"
  Internal: readin p.cpp pst for `c:\p/p.cpp' found when no symtab found.
  (gdb) b "c:/p/p.cpp:6"
  Breakpoint 1 at 0x4012da: file p.cpp, line 6.
  (gdb) b "c:\p\p.cpp:6"
  No source file named c:\p\p.cpp.
  (gdb) b "p.cpp:6"
  Note: breakpoint 1 also set at pc 0x4012da.
  Breakpoint 2 at 0x4012da: file p.cpp, line 6.
  (gdb) maintenance info symtabs
  { objfile C:\p/p.exe ((struct objfile *) 010EFB00)
    { symtab p.cpp ((struct symtab *) 011A1D00)
      dirname C:/p/
      fullname C:/p/p.cpp
      blockvector ((struct blockvector *) 01193D10) (primary)
      debugformat stabs
    }
   [snip]

The MinGW patch I used is on SF under the MinGW project. It contains no 
changes to the source file or symbol handling in GDB.

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

Re: Path handling bug in GDB included with MingW 3.1.0-1

[Eli Zaretskii]

> Date: Wed, 08 Oct 2003 10:34:27 +1000
> From: Chris Johns <cjohns@cybertec.com.au>
> 
>   (gdb) b "c:/p/p.cpp:6"
>   Breakpoint 1 at 0x4012da: file p.cpp, line 6.
>   (gdb) b "c:\p\p.cpp:6"
>   No source file named c:\p\p.cpp.

I don't see any problem here, except some syntactic sugar: users of
GDB on DOS/Windows systems are well advised to use forward slashes as
opposed to backslashes.  If commands work with forward slashes, your
GDB is fully operational.

(The ugly "C:\p/p.cpp" thingie is most probably GCC's fault, anyway.)