public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Re: GDB/ELF/Cygwin source path problem
@ 2003-09-24 12:11 Michael Elizabeth Chastain
  2003-09-24 19:03 ` Kristian Otnes
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-24 12:11 UTC (permalink / raw)
  To: gdb, kristian.otnes

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: GDB/ELF/Cygwin source path problem
  2003-09-24 12:11 GDB/ELF/Cygwin source path problem Michael Elizabeth Chastain
@ 2003-09-24 19:03 ` Kristian Otnes
  0 siblings, 0 replies; 5+ messages in thread
From: Kristian Otnes @ 2003-09-24 19:03 UTC (permalink / raw)
  To: gdb; +Cc: mec

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: GDB/ELF/Cygwin source path problem
  2003-09-24  6:05 Kristian Otnes
@ 2003-09-27 18:58 ` Miki Tebeka
  0 siblings, 0 replies; 5+ messages in thread
From: Miki Tebeka @ 2003-09-27 18:58 UTC (permalink / raw)
  To: gdb

Hello Kris,

>That worked fine until recent updates in Cygwin (around Sept. 1 2003)
>environment. I now have problems with high level debugging due to that
>the path information in the source files in most cases are missing.
>The problem was introduced by simply updating Cygwin, ie. no changes
>in Insight/GDB.
>
>(Source paths are typically missing if the source file is located
>in the same directory as the compiler is running, something which
>is what our make system usually does. If the source file is located
>in for instance "../" relative to where the compiler is running, the
>source path is seen. I have checked the ELF file, and source paths
>are included for all files.)
>
>This is probably related to the symbol reader in GDB. I think that Cygwin
>has changed somewhat with respect to fstat() contents etc.

Try running gdb without the UI (gdb -nw) and see if the problem continues.
If you're ok without UI then it's a tcl/tk problem and you need to have a
look
at the tcl source (libgui/library ?)

HTH.

Bye.
----------------------------------------------------------------------------
-
Smile, damn it, smile.

lambda msg: {
        'name' : 'Miki Tebeka',
        'email' : 'mikit@zoran.co.il',
        'url' : ' http://www.cs.bgu.ac.il/~tebeka',
        'quote' : 'The only difference between children and adults is the
price of the toys'
}[msg]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: GDB/ELF/Cygwin source path problem
@ 2003-09-24 20:09 Michael Elizabeth Chastain
  0 siblings, 0 replies; 5+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-24 20:09 UTC (permalink / raw)
  To: gdb, kristian.otnes

Hi Kris,

Try coff_symfile_read in coffread.c or elf_symfile_read in elfread.c.
I thought Cygwin was still a COFF platform but if you say it's ELF,
then elfread.c would read it.

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

Okay, that mostly rules out the idea that gcc is putting strange
information into the file.

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

It's not that hard to debug gdb with gdb.  The procedure is:

  % gdb gdb
  (gdb) set prompt [top] 
  [top] set arge myfile.exe
  [top] break elf_symfile_read
  [top] run

I've never done it with insight so I don't know how the gui plays
with this.

Michael C

^ permalink raw reply	[flat|nested] 5+ messages in thread

* GDB/ELF/Cygwin source path problem
@ 2003-09-24  6:05 Kristian Otnes
  2003-09-27 18:58 ` Miki Tebeka
  0 siblings, 1 reply; 5+ messages in thread
From: Kristian Otnes @ 2003-09-24  6:05 UTC (permalink / raw)
  To: gdb

I have been using Insight (with GDB embedded) for a cross target
PowerPC-ELF configuration.

That worked fine until recent updates in Cygwin (around Sept. 1 2003)
environment. I now have problems with high level debugging due to that
the path information in the source files in most cases are missing.
The problem was introduced by simply updating Cygwin, ie. no changes
in Insight/GDB.

(Source paths are typically missing if the source file is located
in the same directory as the compiler is running, something which
is what our make system usually does. If the source file is located
in for instance "../" relative to where the compiler is running, the
source path is seen. I have checked the ELF file, and source paths
are included for all files.)

This is probably related to the symbol reader in GDB. I think that Cygwin
has changed somewhat with respect to fstat() contents etc.

Could anyone please inform me where to look in the GDB source files
for adding some debug printout in order to fix the problem? I
started looking into it, but got lost somewhere in there trying
to grasp all the internal structures.

Best regards
Kris.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-09-27 18:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-24 12:11 GDB/ELF/Cygwin source path problem Michael Elizabeth Chastain
2003-09-24 19:03 ` Kristian Otnes
  -- strict thread matches above, loose matches on Subject: below --
2003-09-24 20:09 Michael Elizabeth Chastain
2003-09-24  6:05 Kristian Otnes
2003-09-27 18:58 ` Miki Tebeka

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).