This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Problem with source paths with new Cygwin release


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 <windows.h>           /* For MAX_PATH...  */
#include <sys/cygwin.h>               /* 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.  */
 




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]