On Windows, debugger breakpoints are using file fullname path istead of short filename (SFN, 8.3 filename), wich doesn't work on non-ASCII path and file names.
Can you try if you manually enter the same break command, but just skip the quote at the beginning and the end of the command? You can enter commands when the debugger is stopped.
There are several ways to do this:
- use run to cursor (might not work, because it uses temporary breakpoints),
- use debug -> step into (this should break at the beginning of main),
- there is an option to load the debugger, but not run the debuggee (check this in the settings -> debugger for the option),
- make an infinite loop in the program and use the pause button
- add the breakpoint command as an initial command in the settings
You could also test this is a separate external debugger session.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
Inside CodeBlocks I used "debug -> step into" to break at beginning of main.
Then I set two breakpoints, both without quotes:
break main.cpp:94
break C:\Example\Latin1 name - directory\Test_Project\main.cpp:95
I also did the same on an external gdb session, and I also tried some other combinations with and without quotes and shortnames.
For both requested tests, the first command succeded and the second one failed, see attatchment.
It seems gdb also fails to set breakpoints in full non-ASCII pathname files.
As CodeBlocks sets the working directory to gdb with shortname, as shown in first attatchment (C:/Example/LATIN1~1/PROJET~1/), could it issue breaks with filename only or with shortname paths to resolve this problem?
It seems this is a problem with gdb, but anyway, since CodeBlocks issues the "directory" command to gdb, it's not necessary to set full or short name path to file, at least in these test cases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bluehazzard: Can you try with a separate non-cb gdb session? Does it work there? I'm not going to
switch to windows soons, so I cannot test this. :(
Denis Melo: C::B has to handle putting breakpoints in random files, this is the reason it uses absolute paths. It could be smarter and use relative paths for files in the project, but it isn't. And we need to handle the generic case after all, so this won't fix it.
Last edit: Teodor Petrov 2020-03-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did some research on gdb open bugs.
There I found two tickets that can be related to this problem, btw one of them is nine years old, from Teodor Petrov:
The issue related on ticket 13870 "resolved" the problem. If we issue "list" command before, these breaks with fullname non-ASCII path without quotes work.
After this first test with ticket 13870 I could not test ticket 12706, since gdb is now behaving strange, as if it have some sort of caching. Sometimes gdb set a break, sometimes it set a break only after second try.
Anyway, even though I can't tell if this is right, as you can see in attachment, after a new session, gdb now set breaks if I put commands in this order: target exec (relative no quotes path), file (relative path with quotes), break (full path with quotes).
Inside CodeBlocks, none of the tries that worked direct inside a gdb session worked. I guess the best solution is to use relative paths for files in the project, as suggested Petrov.
Denis,
What GNU GCC compiler package are you using on Windows and the version and where did you get it from?
For example:
MSSY2 or MINGW64 or Cygwin or TDM-GCC etc
Downloaded from: http://siteABC
Thanks,
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The compiler package I was using was MSYS2, downloaded from the original website: https://www.msys2.org/, 64 bits.
Since I'm always using the latest gcc available, and according to https://gcc.gnu.org/releases.html, I believe at the time GCC was in version 7.5.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info. My main GNU GCC compiler I use on Windows is the same . The current GCC version is 10.3.0 (package version 10.3.0-2) and GDB 10.2 (package 10.2-1).
Have you tried these versions to see if the problem still exists?
Can you try if you manually enter the same break command, but just skip the quote at the beginning and the end of the command? You can enter commands when the debugger is stopped.
There are several ways to do this:
- use run to cursor (might not work, because it uses temporary breakpoints),
- use debug -> step into (this should break at the beginning of main),
- there is an option to load the debugger, but not run the debuggee (check this in the settings -> debugger for the option),
- make an infinite loop in the program and use the pause button
- add the breakpoint command as an initial command in the settings
You could also test this is a separate external debugger session.
Hi.
Inside CodeBlocks I used "debug -> step into" to break at beginning of main.
Then I set two breakpoints, both without quotes:
I also did the same on an external gdb session, and I also tried some other combinations with and without quotes and shortnames.
For both requested tests, the first command succeded and the second one failed, see attatchment.
It seems gdb also fails to set breakpoints in full non-ASCII pathname files.
As CodeBlocks sets the working directory to gdb with shortname, as shown in first attatchment (C:/Example/LATIN1~1/PROJET~1/), could it issue breaks with filename only or with shortname paths to resolve this problem?
Last edit: Denis Melo 2020-02-26
I don't know who asigned me to this, but anyway, i tried to convert the paths to short, but for me gdb fails also with short names :
The path is correct because:
opens the path...
So this seems to be a problem in codeblocks and/or gdb
It seems this is a problem with gdb, but anyway, since CodeBlocks issues the "directory" command to gdb, it's not necessary to set full or short name path to file, at least in these test cases.
bluehazzard: Can you try with a separate non-cb gdb session? Does it work there? I'm not going to
switch to windows soons, so I cannot test this. :(
Denis Melo: C::B has to handle putting breakpoints in random files, this is the reason it uses absolute paths. It could be smarter and use relative paths for files in the project, but it isn't. And we need to handle the generic case after all, so this won't fix it.
Last edit: Teodor Petrov 2020-03-01
I did some research on gdb open bugs.
There I found two tickets that can be related to this problem, btw one of them is nine years old, from Teodor Petrov:
https://sourceware.org/bugzilla/show_bug.cgi?id=13870
https://sourceware.org/bugzilla/show_bug.cgi?id=12706
The issue related on ticket 13870 "resolved" the problem. If we issue "list" command before, these breaks with fullname non-ASCII path without quotes work.
After this first test with ticket 13870 I could not test ticket 12706, since gdb is now behaving strange, as if it have some sort of caching. Sometimes gdb set a break, sometimes it set a break only after second try.
Anyway, even though I can't tell if this is right, as you can see in attachment, after a new session, gdb now set breaks if I put commands in this order: target exec (relative no quotes path), file (relative path with quotes), break (full path with quotes).
Inside CodeBlocks, none of the tries that worked direct inside a gdb session worked. I guess the best solution is to use relative paths for files in the project, as suggested Petrov.
Denis,
What GNU GCC compiler package are you using on Windows and the version and where did you get it from?
For example:
MSSY2 or MINGW64 or Cygwin or TDM-GCC etc
Downloaded from: http://siteABC
Thanks,
Andrew
The compiler package I was using was MSYS2, downloaded from the original website: https://www.msys2.org/, 64 bits.
Since I'm always using the latest gcc available, and according to https://gcc.gnu.org/releases.html, I believe at the time GCC was in version 7.5.
Thanks for the info. My main GNU GCC compiler I use on Windows is the same . The current GCC version is 10.3.0 (package version 10.3.0-2) and GDB 10.2 (package 10.2-1).
Have you tried these versions to see if the problem still exists?
BTW after doing a bunch of pacman upgrades the pacman cache can take up allot of space. For info on cleaning out the cache have a look at the https://ostechnix.com/recommended-way-clean-package-cache-arch-linux/ page.
Thank you for the tip about cleaning the cache.
About the problem, no, I haven't tried with new versions. Since I reported the bug I changed all my project directories to contain only ASCII chars.
Last edit: Denis Melo 2021-07-01