public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: "Kristian Otnes" <kristian.otnes@tevero.no>
To: <insight@sources.redhat.com>
Subject: RE: Problem with source paths with new Cygwin release
Date: Mon, 29 Sep 2003 20:45:00 -0000	[thread overview]
Message-ID: <000801c386ca$ab4b7230$770a2f0a@zinfandel> (raw)

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



             reply	other threads:[~2003-09-29 20:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-29 20:45 Kristian Otnes [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-09-05  9:38 Kristian Otnes
2003-09-04 21:12 Kristian Otnes
2003-09-04 21:29 ` Keith Seitz
2003-09-04 21:56   ` Kristian Otnes
2003-09-04 22:02     ` Keith Seitz
2003-09-04 20:47 Kristian Otnes
2003-09-04 20:52 ` Keith Seitz
2003-09-04 19:57 Kristian Otnes
2003-09-04 20:11 ` Keith Seitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000801c386ca$ab4b7230$770a2f0a@zinfandel' \
    --to=kristian.otnes@tevero.no \
    --cc=insight@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).