Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Debug a project built on x86 target with IDE 4 in Windows?: (6 Items)
   
Debug a project built on x86 target with IDE 4 in Windows?  
I'm trying to help someone else get this going, here's the situation:

- porting a large project from Linux
   * note: makefiles are large and hierarchical
   * makefile builds self-hosted on Neutrino 6.3.2 commandline
- commandline gdb on target works OK, but wish to use IDE4 on Windows
- source & binary files on target accessible to windows host via samba server
- qconn is running successfully

Multiple attempts to create project in Win IDE 4 by importing source from target (via samba share), creating debug 
launch and pointing at the binary built on the self-hosted target.

Is there any way that this can work? 

Building in IDE is not feasible due to large hierarchical makes -- does this mean no IDE debugging?

Thanks,

Rich
Re: Debug a project built on x86 target with IDE 4 in Windows?  
Let me clarify!

I have a complex Makefile and 185 sourcecode files.
I have successfully translated all my Linux stuff to QNX stuff and the make works fine on QNX

Now I want to debug it from Momentics. I have had my hands held multiple times through the process of setting up a 
Momentics project and debug configuration that works and allows me to debug from scratch.

I have next attempted to interrupt and debug a running program and have used "C/C++ QNX Attach to Process w/QConn (IP)" 
as my configuration.
Even though I browsed to the same source file locations that I used in my "C/C++ QNX QConn (IP)" configuration, the "C/C
++ QNX Attach to Process w/QConn (IP)" can't find the source while the "C/C++ QNX QConn (IP)" can.

Bottom line: I can debug from scratch, but can't debug a running process. I have successfully used gdb and the command 
line to do what I want it to do. When it stops it tells me what line number and function name it stopped at. But whe 
Momentics is interacting with gdb, for some reason, it can't get at the same hooks for source code that gdb did (on the 
target).
- Frank
Re: Debug a project built on x86 target with IDE 4 in Windows?  
Momentics and I have come to an uneasy truce.

This feels somehow tenuous, because my results have not been always consistent. I am taking GREAT pains to do this the 
same way each time.

The lastest thing I have found is that when I get an error message saying something about no such file found or can't 
establish the limits of the function xyz,..

I tried this:

First, when I told the configuration view where my source code resides, I gave it the location on the target system disk
 where the source code existed. I moved it up to the head of the list. AND I SELECTED THE OPTION CHECK FOR MULTIPLE 
FILES...(I think this was important!)

Then when I first encountered the no such file, when I tried to attach to the running file, I simply opened what I 
thought the most likely copy of my main souce for this project, "SimpleDownload.c". Now before I do anything else, I try
 to set a breakpoint in the code. Momentics then threw up a popup called "Select Source File" ---> There were three 
copies of SimpleDownload.c. The one at the top was the one imported into the project. It had a .c icon in front of it. 
The others had generic file icons in front of them. I selected the top one and the debug session proceeded as if I had 
done everything right!!!!

Furthermore, every time I did this again, the Select Source File window popped up right away to ask me where my source 
code resided. There must be some event that must happen to make the IDE go out and try to find source code. The code was
 there in both my failure cases and my subsequent success cases to ask me to select the source file, but if I didn't 
enter data in EXACTLY the right sequence and explicitly set a breakpoint, it appears that the IDE defaults for these 
kinds of projects in assuming there is no source code.

It just seems that there are an awful lot of possibilities for Momentics that have some counterintuitive roadblocks 
lying around them and the documentation doesn't really give a good step-by-step how-to tutorial for these cases.

If you guys see nothing wrong with what I've done, then for goodness sake, let's codify this methodology in a tutorial 
so poor fools like me don't have to waste a week of trial and error efforts to "get er done".

Thanks for your patience
RE: Debug a project built on x86 target with IDE 4 in Windows?  
What version of IDE you are using? There was a problem in 4.0.1 where source
tab did not work for additional directories for some compiler/debug formats
combinations, in this case Path mapping would work. In path mapping you need
to map compiled path to IDE path, for example /home/me/project/a <->
C:\Development\workspace\a

(To add it use source locations tab from debug configuration or from debug
session)
Post Deleted
Re: Debug a project built on x86 target with IDE 4 in Windows?  
Hi Frank,

I think that in your case the most obvious  option is to use regular make project  in IDE (there are another options, 
but we'll talk later about them).
In this case I'd recommend you to create project with out-of-workspace location. To do it, in the new project wizard you
 should un-check default location and define the remote one which is visible as a local one on your Windows machine 
(remote directory could be the one where your project is originally located. The best way is in my oppinion is to map 
network location to the Windows drive, using for example subst command:

subst l:   \\remote\drive\dir

There could be a problem if your project  makefiles references explicitly to the objects of the remote file system (it 
could be easier if the macros are used).

In this case everything should work well besides the fact that things are going slower than on the local drive.
Another option (faster, but needs some extra work is to create new regular make project on the windows host (locally) 
and add sources to this project using linked folder. This approach leads to some changes in the make file, but building 
I believe should be faster.
And the third option (maybe the most preferable for you). Still build project on the target. Then use import (see Import
->C/C++->C/C++ Executable, fill necessary information in the Launch Configuration dialog and add source locations to 
your remote sources (while testing this option I still use mapped remote directory created in the beginning of this 
message), but you can also use mapping option mentioned by Elena. Everything should work smooth, I believe.

If you have more question, please dont hesitate and ask them/

Alex