[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-tm-dev] Re: remote debugging - Windows/Unix


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.


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


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

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:

Martin Oberhuber
Target Management Project Lead, DSDP PMC Member

Kieran wrote:
 > Hi Martin,
 > Thanks for your help on that. I did as you said and it's working
 > well now! For the reference of anyone else who needs to do it, tryign
 > build the "cygwin" package of gdb won't work, you need to get the
 > 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
 > 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,
 > 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
 > for any of the library files. Also in modules in the top right corner
 > 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
 > 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
 > it. Any suggestions?
 > Second, we have a highly customised build process here, is there any
 > 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
 >> them yourself and enable cross-support for linux. [building from
 >> may not be too difficult].
 >> I do agree, though, that the error message should be more
 >> 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
 >> instead of just running the gdbserver remotely?
 >> Cheers

Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
dsdp-tm-dev mailing list