RE: Problem with source paths with new Cygwin release

RE: Problem with source paths with new Cygwin release

[Kristian Otnes]

To sum up a bit:

I rebuilt the original snapshot from August 8 2003 with updated
cygwin environment, and the problem with missing source paths
persisted.

I then fetched an Insight snapshot from September 5 and built
it with updated cygwin environment, and got the same error
as already reported by Craig:

gdbtk/generic/gdbtk-cmds.c:2891: warning: implicit declaration of function
`cygwin32_conv_to_full_win32_path'
make[1]: *** [gdbtk-cmds.o] Error 1

OK, so there has been something changed with conversion to full paths,
it looks like some API change somewhere in Cygwin if you ask me....

I don't have any solution for this right now except going back
to older version of at least the following modules:

cygutils: 1.2.1-2 -> 1.1.4-2
cygwin: 1.5.3-1 -> 1.3.22-1

Then Insight works with respect to source paths, but the bash
shell doesn't even start. If I go back on bash:

bash: 2.05b-13 -> 2.05b-9

I can start the bash shell, but I get lots of errors. Probably
in a quite useless state...

And that is how far I am right now...

Kristian



------

Today after updating the Cygwin environment, Insight started
having problems with source paths when doing high level debugging.
Most source files are shown only in assembly code, and when
using the Insight function browser, the source paths seem to have
been stripped away from almost all source files. Thus, only
assembly code is shown.

The new Cygwin package was 1.5.3-1. I used the Cygwin setup tool
and went back to 1.3.22-1, and everything worked fine again.

I have been working with Insight in Windows environment
using Cygwin. I built Insight based on a snapshot from August
8 2003 probably using Cygwin 1.3.22-1 release. It was built
for PowerPC/ELF architecture.

Anyone happen to know the reason?

Is it likely that rebuilding Insight after an upgrade would also
solve the problem?

Best regards
Kristian Otnes

RE: Problem with source paths with new Cygwin release

[Kristian Otnes]

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

RE: Problem with source paths with new Cygwin release

[Keith Seitz]

On Thu, 2003-09-04 at 14:56, Kristian Otnes wrote:
> It must be a GDB/Cygwin related problem as you suggest. I am using
> a cross target compiler for PowerPC/ELF.

I'm betting that's its more a generic gdb problem. I don't think cygwin
is really the issue: gdb has "worked" for a long time on cygwin.

> Maybe related to somehow Cygwin handles paths? I see the paths in the
> ELF file. Might be an API change somewhere?!

Doesn't seem likely that this should suddenly fail. I'm putting my money
on the symbol readers.

> Since Insight includes GDB when compiling, I am not sure how closely
> the Insight snapshots follow GDB updates. And I don't know how closely
> GDB follows Cygwin or vice versa. In other words, it can be a number of
> causes.

Insight snapshots are taken at the same time as gdb. In fact, I don't
even do anything related to releases -- the (very) kind gdb folk do it
for me. (Thanks, Andrew! :-)

Nonetheless, you're right: the best approach is to build something new.
Since 6.0 is due out "any day now" (so that means anytime in the next
month or two or three), I would encourage you to try this on 6.0. If
problems exist with 6.0, gdb developers will certainly want to know
about it.

Good luck,
Keith

RE: Problem with source paths with new Cygwin release

[Kristian Otnes]

It must be a GDB/Cygwin related problem as you suggest. I am using
a cross target compiler for PowerPC/ELF.

Maybe related to somehow Cygwin handles paths? I see the paths in the
ELF file. Might be an API change somewhere?!

Since Insight includes GDB when compiling, I am not sure how closely
the Insight snapshots follow GDB updates. And I don't know how closely
GDB follows Cygwin or vice versa. In other words, it can be a number of
causes.

The best thing is probably to build a clean new version and see if
the problem persists. It could maybe be fixed if the build uses some
libraries included with cygwin/cygutils modules, but I have no idea
how that works.

I will see, as I mentioned, if I can try to rebuild things at some
point.

Thanks for your help so far Keith.

Kristian

-----Original Message-----
From: Keith Seitz [mailto:keiths@redhat.com] 
Sent: 4. september 2003 23:31
To: Kristian Otnes
Cc: insight
Subject: RE: Problem with source paths with new Cygwin release

On Thu, 2003-09-04 at 14:11, Kristian Otnes wrote:

> This would typically give a GDB printout:
> 
> 879	foo.c: No such file or directory.
> 	in foo.c
> 
> whereas it shows a few lines of C code if I use the older
> cygwin/cygutils modules

If command line gdb is giving you this error, it looks like gdb's symbol
readers might be screwed up.

Can you clarify: You're debugging native cygwin apps with gdb/Insight or
a cross targetting ppc-elf?

Keith

RE: Problem with source paths with new Cygwin release

[Keith Seitz]

On Thu, 2003-09-04 at 14:11, Kristian Otnes wrote:

> This would typically give a GDB printout:
> 
> 879	foo.c: No such file or directory.
> 	in foo.c
> 
> whereas it shows a few lines of C code if I use the older
> cygwin/cygutils modules

If command line gdb is giving you this error, it looks like gdb's symbol
readers might be screwed up.

Can you clarify: You're debugging native cygwin apps with gdb/Insight or
a cross targetting ppc-elf?

Keith

RE: Problem with source paths with new Cygwin release

[Kristian Otnes]

>Try:
>
>$ gdb myexecutable
>(gdb) list FUNCTION
>

This would typically give a GDB printout:

879	foo.c: No such file or directory.
	in foo.c

whereas it shows a few lines of C code if I use the older
cygwin/cygutils modules

>Try setting breakpoints and running, too:
>
>(gdb) break FUNCTION
>(gdb) run

Setting a break point at a valid function works. When the
CPU gets there, it is halted, and Insight will only show the
assembly code.

Kristian Otnes (kristian.otnes@tevero.no)
Tevero AS (www.tevero.no)
P.O.Box 96
NO-1317 Baerums Verk
Norway
Phone: +47 67 56 29 95

RE: Problem with source paths with new Cygwin release

[Keith Seitz]

On Thu, 2003-09-04 at 13:47, Kristian Otnes wrote:
> >Does command line gdb (of the same version) suffer from the same
> >problem?
> 
> I am not too familiar with GDB, but if I used the GDB console and
> changed the directory to where the source file was, then I would be
> able to see the source code for all source files in that directory.

Try:

$ gdb myexecutable
(gdb) list FUNCTION

Try setting breakpoints and running, too:

(gdb) break FUNCTION
(gdb) run
or
(gdb) target TARGET
(gdb) load
(gdb) run (if sim) or cont (if board)

Keith

RE: Problem with source paths with new Cygwin release

[Kristian Otnes]

An additional comment/warning: I also had to go back on the 'cygutils'
module from 1.2.1-2 to 1.1.4-2, since otherwise 'make' seemed to crash.
Obviously some incompatibility there.

>Does command line gdb (of the same version) suffer from the same
>problem?

I am not too familiar with GDB, but if I used the GDB console and
changed the directory to where the source file was, then I would be
able to see the source code for all source files in that directory.
In other words confirming that path info was lost somehow. Maybe
when reading symbols etc from the ELF file?

>> Is it likely that rebuilding Insight after an upgrade would also
>> solve the problem?
>
>Not sure. There's a relatively easy way to find out, though! ;-)

Heh-heh, I knew someone would say that... I will see if I get around to
it...

Kristian


>===== Original Message From Keith Seitz <keiths@redhat.com> =====
>On Thu, 2003-09-04 at 12:57, Kristian Otnes wrote:
>> Today after updating the Cygwin environment, Insight started
>> having problems with source paths when doing high level debugging.
>> Most source files are shown only in assembly code, and when
>> using the Insight function browser, the source paths seem to have
>> been stripped away from almost all source files. Thus, only
>> assembly code is shown.
>
>Does command line gdb (of the same version) suffer from the same
>problem?
>
>> Anyone happen to know the reason?
>
>Not off hand, sorry.
>
>> Is it likely that rebuilding Insight after an upgrade would also
>> solve the problem?
>
>Not sure. There's a relatively easy way to find out, though! ;-)
>
>Keiht

Kristian Otnes (kristian.otnes@tevero.no)
Tevero AS (www.tevero.no)
P.O.Box 96
NO-1317 Baerums Verk
Norway
Phone: +47 67 56 29 95

Re: Problem with source paths with new Cygwin release

[Keith Seitz]

On Thu, 2003-09-04 at 12:57, Kristian Otnes wrote:
> Today after updating the Cygwin environment, Insight started
> having problems with source paths when doing high level debugging.
> Most source files are shown only in assembly code, and when
> using the Insight function browser, the source paths seem to have
> been stripped away from almost all source files. Thus, only
> assembly code is shown.

Does command line gdb (of the same version) suffer from the same
problem?

> Anyone happen to know the reason?

Not off hand, sorry.

> Is it likely that rebuilding Insight after an upgrade would also
> solve the problem?

Not sure. There's a relatively easy way to find out, though! ;-)

Keiht

Problem with source paths with new Cygwin release

[Kristian Otnes]

Today after updating the Cygwin environment, Insight started
having problems with source paths when doing high level debugging.
Most source files are shown only in assembly code, and when
using the Insight function browser, the source paths seem to have
been stripped away from almost all source files. Thus, only
assembly code is shown.

The new Cygwin package was 1.5.3-1. I used the Cygwin setup tool
and went back to 1.3.22-1, and everything worked fine again.

I have been working with Insight in Windows environment
using Cygwin. I built Insight based on a snapshot from August
8 2003 probably using Cygwin 1.3.22-1 release. It was built
for PowerPC/ELF architecture.

Anyone happen to know the reason?

Is it likely that rebuilding Insight after an upgrade would also
solve the problem?

Best regards
Kristian Otnes