RE: GDB/ELF/Cygwin source path problem

["Kristian Otnes" <kristian dot otnes at tevero dot no>]

Michael,
thanks for your time and help.

I haven't specifically looked at the assembly files, but
I have looked at the resulting ELF file which includes the debug
info. It is the ELF file that is used by the GDB symbol reader.
And the paths are in there.

The thing was that the same ELF file gave different results
with Cygwin version 1.3.22-1 compared to the current
1.5.x-y versions available.

We are using an old GCC cross compiler, so it may be that
the resulting ELF format has changed in newer GCC versions,
but I am not so sure about that. But for various reasons
we don't want to change the compiler now.

Anyway, I just checked on Cygwin, and there has been some
changes in the stat() and dirent() internal structures when
going from 1.3.x to 1.5.x, not fstat() as I indicated. GDB
seems to be using them, but that may be a sidetrack here.

Anyway, what I wanted was to do some old fashioned debugging
with rebuilding Insight (and GDB) with some printf's inside to
see what was going on inside the symbol reader. And if anyone
knows whereabouts source file names and their paths are read,
I would appreciate a tip.

Kris


-----Original Message-----
From: Michael Elizabeth Chastain [mailto:mec@shout.net] 
Sent: 24. september 2003 14:11
To: gdb@sources.redhat.com; kristian.otnes@tevero.no
Subject: Re: GDB/ELF/Cygwin source path problem

Try "gcc -S ...", with all the options that you normally use,
and adding a "-S".  Then look in the generated assembly code
and see what the file names look like.  That might help.

Try doing the exact "gcc -S ..." with the old working cygwin dll
and the new non-working cygwin dll.  Perhaps cygwin.dll changed
in such a way that gcc emits new information now.

Try running the exact same executable with the old and new
cygwin dll.  That is, not re-compiling, and with the *exact*
same file.

These things would help localize the problem.

Apologies if this is too simple and you have already done it.

Michael C
GDB QA Guy