debug under windows

CodeLite installation/troubleshooting forum
User avatar
eranif
CodeLite Plugin
Posts: 6056
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: debug under windows

Post by eranif » Wed Oct 13, 2010 6:59 pm

brownhamer wrote:Unfortunately it does not solve the problem for me. The 'file' attribute from cygwin gdb contains the cygwin style filename as well.
Can you give an example for such output?

Eran
Make sure you have read the HOW TO POST thread

brownhamer

Re: debug under windows

Post by brownhamer » Thu Oct 14, 2010 10:25 am

DEBUG>>00000012^done,line="96",file="/cygdrive/d/View/NLMGD1VT01/src/games/sust/src/common/sust_main_main.c",fullname="/cygdrive/d/View/NLMGD1VT01/src/games/sust/src/common/sust_main_main.c",macro-info="0"

User avatar
eranif
CodeLite Plugin
Posts: 6056
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: debug under windows

Post by eranif » Thu Oct 14, 2010 12:21 pm

Thanks for the output.

I have a solution:
By defining an environment variable CYGROOT=C, codelite will replace the /cygdrive/d with C:\ (or the content of CYGROOT)

Since from my experience, the pattern is clear:
/cygdrive/n (where n is the drive name) codelite can simply perform a simple substitution

Does this sound reasonable?

Eran
Make sure you have read the HOW TO POST thread

brownhamer

Re: debug under windows

Post by brownhamer » Thu Oct 14, 2010 1:28 pm

It works for me... but I think it could be resolved more generic.

The pattern in this case indeed is /cygdrive/n, however cygwin allows any customized name for the cygdrive mapping using the fstab file. This is why I think the suggested solution will probably not work for all scenarios. For instance the file 'c:\dev\file.c' is by default presented as '/cygdrive/c/dev/file.c', but using the fstab I could change that to '/cygwintowindowsdrive/c/home/temp/file.c' if I wanted.

After some more thought, I think the problem should be abstracted a little further. The path given back by GDB has to be 'resolved' by an external tool in our case. I don't know of any other situations where this is required, but I can imagine there are more, for instance if GDB is giving back relative paths (if it ever is).
I would suggest to add some sort of options to have GDB paths resolved by a user defined command. For this situation the command would be 'cygpath -w %file%', but other command could be used.
I understand this more generic approach comes with a performance penalty, but that is something that cannot be avoided.

Another solution could be to have an option to use the default resolving of the /cygdrive/n pattern, and the more generic option as a last resort.
Thus:
- check if the file in 'fullname' is a valid file, if not use the value from 'file'
- check if the file in 'file' is a valid file, if not check if the /cygdrive/n pattern option is selected and the 'fullname' or 'file' starts with /cygdrive
- check if the command to resolve the path option is selected

If all 3 fail, the file cannot be opened/selected. This would also solve the 'hard-coded' check for /cygdrive in 'fulname', which actually made CodeLite use a non-generic implementation.

User avatar
eranif
CodeLite Plugin
Posts: 6056
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: debug under windows

Post by eranif » Thu Oct 14, 2010 1:34 pm

brownhamer wrote:Another solution could be to have an option to use the default resolving of the /cygdrive/n pattern, and the more generic option as a last resort.
Thus:
- check if the file in 'fullname' is a valid file, if not use the value from 'file'
- check if the file in 'file' is a valid file, if not check if the /cygdrive/n pattern option is selected and the 'fullname' or 'file' starts with /cygdrive
- check if the command to resolve the path option is selected
This sounds like a valid direction + implementing a small cache for the file paths (which will be cleared on start/stop debug) can reduce the penalty of executing an external tool

Eran
Make sure you have read the HOW TO POST thread

brownhamer

Re: debug under windows

Post by brownhamer » Thu Oct 14, 2010 2:00 pm

Sounds like a winning solution to me as well.

EddieG
CodeLite Curious
Posts: 2
Joined: Thu Oct 14, 2010 1:01 pm
Genuine User: Yes
IDE Question: all
Contact:

Re: debug under windows

Post by EddieG » Thu Oct 14, 2010 2:33 pm

Maybe if the cached filename itself is checked for validity before use (and then try to resolve it otherwise) I don't think there is a need to clear the cache on start/stop debug. It could be done on project close/rebuild/clean/close IDE.

This should make the debugger IDE respond a bit faster when it has to open a new file not opened yet in this debug session but which has already been opened in another session. Unless someone is debugging through 1000 files the cache should be accessible rather fast.

I guess it depends on whether the resolving with an external tool is actually noticeable when debugging.

User avatar
eranif
CodeLite Plugin
Posts: 6056
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: debug under windows

Post by eranif » Thu Oct 14, 2010 3:16 pm

EddieG wrote:I guess it depends on whether the resolving with an external tool is actually noticeable when debugging
Executing new process is slow under Windows (and it will be noticeable) - this is why the cache is needed.

Clearing the cache on codelite restart is reasonable to me, assuming no one is modifying fstab while debugging (and even in this case, it is reasonable to require codelite restart)

Eran
Make sure you have read the HOW TO POST thread

brownhamer

Re: debug under windows

Post by brownhamer » Thu Oct 14, 2010 3:46 pm

and even in this case, it is reasonable to require codelite restart
It sure is, modifying fstab during debugging I consider a no no.

User avatar
eranif
CodeLite Plugin
Posts: 6056
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: debug under windows

Post by eranif » Thu Oct 14, 2010 7:41 pm

I added a support for running an external tool (cygpath -w $(File))

there is one caveat:
You should provide the full path to cygpath (e.g. C:\cygwin\bin\cygpath -w $(File))

I tested it and it is working as expected

Please give it a try
The fix exists in revision 4443
Eran
Make sure you have read the HOW TO POST thread

Post Reply