Re: [Mingw-users] gdb debugging question

[Kai R. <kai...@lu...>]

Earnie Boyd wrote:
> 
> Kevin Wooten wrote:
> >
> > We are trying to use the MinGW collection to build a multi platform server,
> > on both linux and win32. Currently we are runnning into a problem trying to
> > debug the executable on the win32 platform. It seems the file names in the
> > debug symbols are produced as '//C/someprobject/file.cpp' when loading the
> > executable into gdb it cannot open the file ( I am assuming because there is
> > no attempt to translate it to a valid win32 path ).
> 
> This would indeed be incorrect for MinGW, if you're using Cygwin gcc I
> could see this happening.  You'll have to give us what versions of gcc
> and binutils you're using.  Try adding a directory path to find the
> source in gdb.  I don't remember if gdb handles C:/foo correctly.  You
> may need to be on the drive in which the source exists and add a
> directory to search for source without the C:/.

 There is another Mingw-related bug in this area, in the GNU linker. As it is
well known, the 'dynamic linker', 'ld-linux.so.2', 'ld.so.1' or something, is
chained to the shared library 'libc.so.6' in Linux targets, and same kind of
thing happens with Solaris2, SVR4.x's etc. The linker should find the 'linked'
file almost automagically when handling the 'libc.so.6', earlier needing only
the extra '-rpath-link' option to point to its location in the cross-environment.
It can be possible that now the directories pointed with '-L' are searched for
it automatically.

 So the following should work:

--------------------------- clip ---------------------------------------
GNU assembler version 2.10.1 (ppc-linux-gnu) using BFD version 2.10.1
 e:\usr\local\lib\gcc-lib\ppc-linux-gnu\2_95.3\collect2.exe
 -m elf32ppclinux
 -dynamic-linker /lib/ld.so.1
 -rpath-link e:/usr/local/ppc-linux-gnu/lib    <--------- !!!!!!
 -o tst_ppc-linux.x
 e:\usr\local\lib\gcc-lib\ppc-linux-gnu\2_95.3\..\..\..\..\ppc-linux-gnu\
lib\crt1.o
--------------------------- clip ---------------------------------------

 It works if the binutils are Cygwin-hosted but not with the Mingw-host...
I tried several binutils, starting from the '990817' I had for the Mingw-target,
to the recent '20010130' weekly snapshot. Not any of them worked...

--------------------------- clip ---------------------------------------
ppc-linux-gnu\2_95.3\..\..\..\..\ppc-linux-gnu\lib\crtn.o
e:/usr/local/ppc-linux-gnu/lib/libc.so.6: undefined reference to `_dl_init_next@
GLIBC_2.0'
e:/usr/local/ppc-linux-gnu/lib/libc.so.6: undefined reference to `_dl_lazy@GLIBC
_2.1.1'
e:/usr/local/ppc-linux-gnu/lib/libc.so.6: undefined reference to `_dl_dst_substi
tute@GLIBC_2.1.1'
--------------------------- clip ---------------------------------------

 The workaround is to add the 'ld.so.1%s' to the lib-spec, but this causes
it appearing as 'NEEDED' in the 'objdump -p' output of the executable, while
when the linker works, it is left away.

 I have tried to track this, but haven't yet found where the bug hides...
Using the '//E' instead of 'e:' or '\\' instead of '/' didn't help either.

 Has anybody else crashed into this same bug?

Cheers, Kai