From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29718 invoked by alias); 29 Sep 2003 20:45:52 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 29666 invoked from network); 29 Sep 2003 20:45:50 -0000 Received: from unknown (HELO mail44.fg.online.no) (148.122.161.44) by sources.redhat.com with SMTP; 29 Sep 2003 20:45:50 -0000 Received: from zinfandel (ti221110a080-2011.bb.online.no [80.213.7.219]) by mail44.fg.online.no (8.9.3p2/8.9.3) with ESMTP id WAA25936 for ; Mon, 29 Sep 2003 22:45:48 +0200 (MEST) From: "Kristian Otnes" To: Subject: RE: Problem with source paths with new Cygwin release Date: Mon, 29 Sep 2003 20:45:00 -0000 Organization: Tevero Message-ID: <000801c386ca$ab4b7230$770a2f0a@zinfandel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-q3/txt/msg00181.txt.bz2 This is just for the records, in case someone else should ever have some similar problems. The below was also posted on the gdb mailing list, where I tried to follow up on the problem I had. I doubt if it will be included in GDB, although I think a good principle would be to ensure paths are properly converted at the point of building the symbol table, just in case. I didn't take the time to figure out how the old Cygwin somehow managed to cope with it as it was, but now Insight/GDB works very well for my use. Kris This may be a fix to an almost non-existing problem, refer to thread. However, the problem was very real for me.... I found out that the problem is probably related to that source paths are stored in Windows format (i.e. "c:\..." in the ELF file I end up with (I use an old GCC binary made for DOS usage). GCC made for Cygwin would probably use "/cygdrive/c/..." format, although I haven't checked that. When trying to open the source file in gdb/source.c, GDB starts with looking for source using the "$cdir:$cwd" which is sort of expanded in at least two places. It will first expand the compilation directory ($cdir) and pass to openp() function in source.c something like: "c:/mydir/:$cwd". However, openp() will also search for the ':' sourcepath delimiter in order to possibly find $cwd. And since the delimiter is part of the Windows style path, things start going wrong. Rather than trying to fix the problem in openp(), I applied the following in buildsym.c in order to fix paths when building the symbol table. The below fix worked for me, but I have no clue how GDB actually works, so I don't know if there are any sideeffects. /* Start recording information about source code that came from an included (or otherwise merged-in) source file with a different name. NAME is the name of the file (cannot be NULL), DIRNAME is the directory in which it resides (or NULL if not known). */ /* START FIX by Kristian Otnes, 2003-09-28, see details below */ #ifdef __CYGWIN__ #include /* For MAX_PATH... */ #include /* For cygwin_conv_to_... */ #endif /* END FIX by Kristian Otnes, 2003-09-28 */ void start_subfile (char *name, char *dirname) { struct subfile *subfile; /* START FIX by Kristian Otnes, 2003-09-28 */ /* In case the symbol info contained Windows type paths (c:\...) we */ /* should convert to Posix style path. Otherwise there might be */ /* problems later with opening source files in the debugger. */ #ifdef __CYGWIN__ char *_dirname; char *_name; /* 'name' will typically not be a full path, but it doesn't hurt to */ /* convert it to Posix style... */ if (name) { _name = alloca(MAX_PATH + 1); cygwin_conv_to_posix_path(name, _name); name = _name; } if (dirname) { _dirname = alloca(MAX_PATH + 1); cygwin_conv_to_posix_path(dirname, _dirname); dirname = _dirname; } #endif /* END FIX by Kristian Otnes, 2003-09-28 */ /* See if this subfile is already known as a subfile of the current main source file. */