debug-problem with cygwin-linux-cross
Wedde, Thomas
thomas.wedde@hfwk.de
Fri Dec 9 09:46:00 GMT 2005
Hi !
Thank you for your fast reply Dan..
> > I compiled a cross toolchain with crosstools 0.38 (thx Dan !)
> > - gcc 3.3.3
> > - glibc 3.2.3
> > - binutils 2.15
> > - host&build: i686-cygwin-linux
> > - target : i386-linux-gnu
> > Under WinXP with cygwin an it runs without problems.
> >
> > After the compilation I was a little confused about the output path
> > structure
> > (C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-
> gnu\i386-unknown-linux-gnu\bin -> contained the tools from cygwin
> >
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\bin
> -> contained the new toolchain
> > C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-
> gnu\include
> > was nearly empty but some includefiles where needed so I copied them
to
> > C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-
> gnu\i386-unknown-linux-gnu\inlcude
> > and so on...)
>
> You shouldn't need to do that... what happens if you don't?
Okay, I try to explain that.
After compilation, there are two include paths in the result path:
(1)
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\inc
lude
(2)
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\i38
6-unknown-linux-gnu\include
And (1) is nearly empty, except of other paths:
(1)\c++\3.3.3\i386-unknown-linux-gnu\bits
(1)\c++\3.3.3\bits
(1)\c++\3.3.3\backward
(1)\c++\3.3.3\ext
Each of them contain a few headers, for example (1)\c++\3.3.3\ contain
iostream
So if I want to include C++ Standard headers, such as iostream, I have
to put all the files in these paths in the same /include directory,
because if I don't the references on the headers do not work (iostream
includes other headers which are only in (2) and so on)
The same problem is for libraries...
For me there is a understanding problem why the result path structure is
so fragmented.
In (2)/../bin there are my binaries of the result toolchain
(i386-unknown-linux-gnu-g++.exe) and
In (1)/../bin there are also binaries, but with the old tools (gcc.exe)
I tried to recompile the toolchain, but there is the same result.
Each of the two paths contain the paths of the other, but
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu
Is nearly empty (not much files) and
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\i38
6-unknown-linux-gnu
contains most of the results...
Do you know what is going wrong here ?
> > If I want to debug my application with gdbserver on the target and
gdb
> > 6.0 on my cygwin host I get several errors:
> >
------------------------------------------------------------------------
> > ----
> > warning: Unable to find dynamic linker breakpoint function.
> > GDB will be unable to debug shared library initializers
> > and track explicitly loaded dynamic code.
> > Error while mapping shared library sections:
> > /lib/libstdc++.so.5: No such file or directory. ...
> > Error while reading shared library symbols:
> > Stopped due to shared library event
> > /lib/ld-linux.so.2: No such file or directory.
> > Reply contains invalid hex digit 78 ...
> >
> > Seems that it can not find those libs although they are present (and
I
> > added the path to them to the linker options)
> > I tried to copy them around, for example to cygwin/usr/lib, but this
> > doesn't help.
> > If I do : i386-unknown-linux-gnu-ld --verbose | grep SEARCH
> > The answer is: SEARCH_DIR("=usr/local/lib"); SEARCH_DIOR("=/lib");
> > SEARCH_DIOR("=usr/lib")
>
> Did you read
> http://www.kegel.com/linux/gdbserver.html
> ?
Yes i read that, but sadly it did not help.
I found some hints that the not-finding of the libraries could be a
linker-problem so I think I should verifiy that my toolchain is correct
at first, before I can surely say that it is a gdb-error...
Giving the new /lib path to the gdb-options did not help in this case
(by the way: I use eclipse as a frontend for my debug session).
> > Although I can step-trough my program at termination of it, gdb
always
> > return the "Reply contains invalid hex digit 78" and aborts.
>
> Now *there's* a question you need to take to the gdb mailing list...
> - Dan
I already had this problem under linux during remote-debugging the
target and solved it by using exactly that gdb 6.0 instead of gdb 6.1. -
so I tried to compile it for cygwin and I think there must be a
connection between my cross-compiled gdb and this error (of course it is
;) but maybe youre right and I should post this to the gdb-mailingslist)
One thing last: while browsing through the web I always got links to the
CrossGCC-FAQ (also in singnatures of this mailinglist) but I never find
them - because all I got is a redirection to billgatliff.com, but there
are no FAQs on this site.... (there is nothing about cross-gcc on this
site).. or am I just blind.. !?
thanks in advance
Thomas
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
More information about the crossgcc
mailing list