From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22004 invoked by alias); 8 Oct 2003 00:34:44 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21995 invoked from network); 8 Oct 2003 00:34:43 -0000 Received: from unknown (HELO kiwi.ods.com.au) (144.132.165.174) by sources.redhat.com with SMTP; 8 Oct 2003 00:34:43 -0000 Received: from cybertec.com.au (kiwi [172.16.100.4]) by kiwi.ods.com.au (8.12.8/8.12.8) with ESMTP id h980YREI028119; Wed, 8 Oct 2003 10:34:29 +1000 Message-ID: <3F835B93.3050303@cybertec.com.au> Date: Wed, 08 Oct 2003 00:34:00 -0000 From: Chris Johns User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii CC: michaelstather@nuzi.de, gdb@sources.redhat.com Subject: Re: Path handling bug in GDB included with MingW 3.1.0-1 References: <002d01c38b8a$6e2d34f0$2101a8c0@kyromaster> <1438-Tue07Oct2003231328+0200-eliz@elta.co.il> In-Reply-To: <1438-Tue07Oct2003231328+0200-eliz@elta.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00128.txt.bz2 Eli Zaretskii wrote: >>From: "Michael Stather" >>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