[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] Re: remote debugging - Windows/Unix
|
Hi,
Martin makes a very important point about needing a copy of the target
libraries on your host and letting your cross-gdb knowing about the
location of those. In the "C/C++ Remote Application" you can add these
paths on the "Debugger" tab.
On the gdb command-line, I belive you can use the "set
solib-search-path" command.
Ewa.
-----Original Message-----
From: dsdp-tm-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Martin Oberhuber
Sent: Friday, August 24, 2007 2:12 PM
Cc: Ewa Matejska; Target Management developer discussions; Johanna
Subject: [dsdp-tm-dev] Re: remote debugging - Windows/Unix
Hi,
here is a nice pointer for a paper about cross
development (remote debugging) with Eclipse, the tools
required and also a little bit about the cross toolchains
(gcc, gdb, binutils):
http://www.macraigor.com/downloads/Macraigor_with_Eclipse.pdf
and here is another old E-Mail I just dug out, which you might
find interesting: Unfortunately, the E-Mail address that I have from
Kieran Flynn is not correct any more, so I cannot ask him personally.
-------------------------------------------------------------
Hello Kieran,
it looks like there's two distinct problems you have:
1.) The Debugger's source path mapping is not what you
want it to be. Since you built on remote, the debug
info has pathes like /home/kieran/... embedded, these
need to be mapped to local F:\kieran\... etc.
This source path mapping can be edited in the Launch
Configuration Dialog, Source Path Mapping tab.
2.) Since you're debugging a Linux executable on Windows,
your debugger needs access to the Linux libs and
sharedlibs, and NOT the cygwin variants of these.
Basically, you need to setup a LINUX /usr/lib/...
structure that is visible from Windows, and point
your debugger's libraryLoadPath to it. Such a setup
is very typical, most embedded debuggers have a
/target/lib, /target/bin, /target/share etc. structure
somewhere to mimic the layout of the remote filesystem
for the debugger.
Looking at the ELDK (embedded linux development kit)
might help.
3.) Remote Builds - when you execute "make" in an RSE
Commandview, it will automatically parse any error
output and allow you navigate to it in the editor.
The other option is to edit the CDT's "make command"
to do something like "ssh remotesystem make".
Above that, the CDT project has a bug from HP where
they contribute a solution for remote edit & build.
I'd be keep to hear from you how it's working since
I haven't tried it so far:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=168048
https://bugs.eclipse.org/bugs/show_bug.cgi?id=88546
https://bugs.eclipse.org/bugs/show_bug.cgi?id=71484
https://bugs.eclipse.org/bugs/show_bug.cgi?id=30091
Thanks,
--
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
Kieran wrote:
> Hi Martin,
>
> Thanks for your help on that. I did as you said and it's working
quite
> well now! For the reference of anyone else who needs to do it, tryign
to
> build the "cygwin" package of gdb won't work, you need to get the
"real"
> gdb and compile it FOR cygwin (crossed with whatever architecture you
> want).
> I have a few other questions though and maybe you can help point me
to a
> solution. This might be a bit verbose, but hopefully that means
you'll
> find it easier to help me out...
>
> The project is set up like this: project/
> project/src/
> project/build/
> project/install/
> project/install/lib
> project/install/bin
>
> and so on. The windows machine is running eclipse and is also running
> cygwin.
> the machine with the project is a linux box. the project folder is
> accessible both in windows under a drive letter, and in cygwin at a
> mount point, so all edditing etc is done through windows side, only
> remote debugging is done via rse. The first time the debugger starts,
it
> can't see the source code for main() so it shows the assembly. I can
> point it to the code for _that_ file but I can't get it to see the
code
> for any of the library files. Also in modules in the top right corner
it
> shows the main binary and all the libraries from the project as not
> having symbols loaded. After that a mixture of some libraries are
> loaded, some are not. For example libraries like \lib\ld-linux.so.2
must
> have loaded via cygwin. Some of the libraries that aren't in cygwin
> obviously didn't load as they are on the linux machine.
> It seems sort of hit and miss to get eclipse to see all the code, all
> the binaries/libraries and link it all together and I have to do it
> almost one file at a time. I'm sure there's a better way but I can't
see
> it. Any suggestions?
>
> Second, we have a highly customised build process here, is there any
way
> of doing remote builds in the same nature as teh remote debugging?
>
> I really appreciate your help on this
>
> Kieran
>
>
>
> Martin Oberhuber wrote:
>
>> For remote debugging, you'll need a _local_ gdb executable that is
>> capable of understanding the remote exe file and architecture, and
>> connecting to the remote gdbserver. The remote gdbserver is only a
>> very thin layer, most work will be done locally.
>
>> I'm not sure what version of gdb you could get for Windows X Linux
>> debugging. Most vendors who do cross-compile / cross-debug in their
>> commercial products based on GNU Tools and Eclipse, build their own
>> versions of gdb for the cross-support from the sources. Therefore,
>> cygwin gdb or mingw gdb may not work out of the box unless you
compile
>> them yourself and enable cross-support for linux. [building from
source
>> may not be too difficult].
>
>> I do agree, though, that the error message should be more
informative.
>
>> Ewa, can you help any further? Is there any point in running a whole
>> gdb remotely and piping the gdb/mi channel through the RSE
IHostShell,
>> instead of just running the gdbserver remotely?
>
>> Cheers
>
Cheers,
--
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
