CodeLite IDE

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

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"

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

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.

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

Sounds like a winning solution to me as well.

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.

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

and even in this case, it is reasonable to require codelite restart

It sure is, modifying fstab during debugging I consider a no no.

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