- This topic has 7 replies, 2 voices, and was last updated 10 years, 9 months ago by
.
-
Posts
-
Guys,
first of all fantastic work, developing with visualGDB is fantastic. I will recommend the product to a larger company!
But nontheless I do have some remarks.My sistem uses custom toolchain for ARM926 and I develop on windows, build on custom linux with installed toolchain and deploy to target SOC.
So what I have found problematic is:
1. CLEAN + BUILD or REBUILD all does not work, after issuing the command nothing happens.ΕΎ
2. Detection that sources havent changed is ok(copying only changed ones), but why not implement also detection if build did not happen, then probably is no need to copy the executable
3. Possible rsync copy should be faster…
4. Breakpoints on my GDB 7.2 during execution hang GDB and cannot continue
5. When deploying to target, why it is not checked if the process is already running and kill it.Thats for now…
Any thoughts?
Hi,
Thank you for for the kind words.
Below are the answers to your points:
1. What exactly do you mean by nothing happens? What does the Output window say after executing those commands? Please check that the build and clean commands are set in VisualGDB Project Properties. If they look fine, then check the Properties of the project to see if the NMake commands are calling VisualGDB.2. That was recently suggested and has been added to the feature roadmap.
3. If you need to copy many files, then consider switching to using shared directories instead. You can also disable the file synchronization and use your own synchronization command in pre-build commands.
4. We would need to see the full gdb log to be able to tell what the cause is here. Please enable gdb logging on the GDB settings page in VisualGDB Project Properties. Then start debugging, replicate your scenario, stop debugging and give us the gdb log from your project directory.
5. This is because sometimes you may want to attach to the running instance instead. Normally when gdb is detached, gdbserver should die together with the app. If this does not happen, add a pre-debug or post-debug command to kill the gdbserver or modify in GDB settings which command should be executed when debugging is stopped.
Dear,
Please see my answers below:
1. What exactly do you mean by nothing happens? What does the Output window say after executing those commands? Please check that the build and clean commands are set in VisualGDB Project Properties. If they look fine, then check the Properties of the project to see if the NMake commands are calling VisualGDB.
Sorry i was mistaken, clean works it deletes the directory where executable is put, but rebuild does not work, this is the output:
1>Rebuild All started: Project: Pay, Configuration: Debug Win32
1> VisualGDB: Attempting inline build…
1> VisualGDB: Executing preclean actions
1> VisualGDB: Run “make CONFIG=Debug clean” in directory “/tmp/VisualGDB/d/_Work/e/Devices/Pay/Pay” on user@192.168.3.207 (SSH)
1> rm -rf Debug
1> VisualGDB: Executing postclean actions
1> VisualGDB: Attempting inline build…
1> VisualGDB: Executing preclean actions
1> VisualGDB: Run “make CONFIG=Debug clean” in directory “/tmp/VisualGDB/d/_Work/e/Devices/Pay/Pay” on user@192.168.3.207 (SSH)
1> rm -rf Debug
1> VisualGDB: Executing postclean actions
1> VisualGDB: No file changes detected. If you believe it’s a mistake, please clean the project and build it again.
1> No relevant source files have been changed. Skipping build commands.
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========Notice this: No relevant source files have been changed. Skipping build commands. This is if i have Transfer only changed files option! When you do a clean it does not rebuild the executable :S
And after this even if i try to start debugging it says LIBSSH2_ERROR_SCP_PROTOCOL because it cannot find the executable. And the only way to solve this is to go to project options and tick Always transfer all files and then it will build…(only changed option also does not detect if we move the files around, from one dir to another, that would mean changing all include statements in other files, so it should when any file is moved request a full transfer of all files, so that you can see that there is in some source file a problem because some header file has moved.)
So you VGDB should remember that there was a clean issued or rebuild and transfer all the files again and rebuild!
3. If you need to copy many files, then consider switching to using shared directories instead. You can also disable the file synchronization and use your own synchronization command in pre-build commands.
Not that much than copy many files, than that rsync is a in many cases a lot faster. Like now i’m building a project where executable, because it cannot be striped is around 12mb big, and deployment target is on wifi… Copying is a nightmare π So yes i could mount and run from there, but i tried rsync also… its alot faster. What for the future would be a great thing to do is to put another dialog, what to copy to target and user could enter files/paths that are copied with the deployment4. We would need to see the full gdb log to be able to tell what the cause is here. Please enable gdb logging on the GDB settings page in VisualGDB Project Properties. Then start debugging, replicate your scenario, stop debugging and give us the gdb log from your project directory.
When app is running and i got to the a source file and press to set the break point in few seconds GDB Command Timeout appears saying it takes too long to complete and from this there is no way back. I usually press abort command which causes SIGINT and the stop the debugging. I will send the log to support email. Thank you
5. This is because sometimes you may want to attach to the running instance instead. Normally when gdb is detached, gdbserver should die together with the app. If this does not happen, add a pre-debug or post-debug command to kill the gdbserver or modify in GDB settings which command should be executed when debugging is stopped.
Ok the script i can write my self, but in the future… it would help to have an option if we don’t attach kill π
Hi,
1. It is strange that cleaning happens twice on rebuilding, it should only happen once. We would need to replicate the issue to see where the problem is. Are you using the latest version of VisualGDB? Which exact project type do you have (e.g. is it a Linux project with two machines, one for building, other for deployment)? Are you using a VisualGDB generated makefiles or your own?
3. We use on-the-fly TAR generation that is quite fast compared to file-by-file transfers. Do you have benchmark results showing that rsync is better? Do you believe it’s due to compression or something else? How does it scale with the amount of files (e.g. 1 huge file vs 10000 small files)? How does it scale with file compressibility (e.g. huge source file vs a ZIP archive)? Note that you can setup rsync-based file transfer via custom actions.
4. As noted in the email answer, enable the relative source paths option in GDB settings to avoid the timeout caused by the “-file-list-exec-source-files” command.
5. In the majority of cases killing the gdbserver separately is not needed. Have you tried changing the action for the stop debugging command in GDB settings? For your toolchain gdb may expect to be stopped in a different way for gdbserver to be killed.Dear,
found the problem, it probably clashes with rebuild or clean + build option. In the VGDB project settings I had option “Skip build commands if no source file changes have been detected” ticked, and this is the cause of the problems. The option it self is correct, but the implementation behind should be worked on… What I mean is if no files transferred no build is needed, build is needed ONLY if rebuild or clean + build or clean + rebuild happened.
So doing a build with the thingy checked: (REBUILD, CLEAN+BUILD, CLEAN+REBUILD does not work), below example shows what happens if I do a build on already built solution, where in fact was no changes.
It detects that no files changed = OK, because no files changed skipping build command = OK!
1> VisualGDB: Attempting inline build…
1> VisualGDB: No file changes detected. If you believe it’s a mistake, please clean the project and build it again.
1> No relevant source files have been changed. Skipping build commands.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========With the thingy NOT-checked: (REBUILD, CLEAN+BUILD, CLEAN+REBUILD do work as expected), below example shows what happens if I do a build on already built solution, where in fact was no changes.
It detects that no files changed = OK, because no files changed skipping build command = NOK! so it did a build on the build system even if no change occurred.
1> VisualGDB: Attempting inline build…
1> VisualGDB: No file changes detected. If you believe it’s a mistake, please clean the project and build it again.
1> VisualGDB: Executing prebuild actions
1> VisualGDB: Run “make CONFIG=Debug” in directory “/tmp/VisualGDB/d/_Work/e/Devices/Pay/Pay” on user@192.168.3.207 (SSH) should not happen
1> make: Nothing to be done for `all’.
1> VisualGDB: Executing postbuild actions
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========Hope I have cleared it, it is easily reproducible.
3. When I’ll have the time i’ll check the benchmarks and post it. The option to leave the executable on the build system and mount the filesystem of the target is also very good, is it possible to integrate that option into the VGDB, something like auto-mount target and run executable from there ?
Don’t get me wrong I know how to do it, but i think your product is very appealing to Windows users that like to get into the c++ + embedded world but lack Linux knowledge of scripts, mounts,… i know because i came across some people with same characteristics π4. The suggested option does not help, it has the same result, please see the logs on you email.
As you said in the email large number of sources are making this, we were planning with another company to re-do the project in VGDB, but that is kind of a stopper as the project has over 100 files, and few 100k lines of code….5. This happens mainly when something has gone wrong, like the timeout for setting a breakpoint or not killing the debugged program correctly or…. number of things… And again don’t get me wrong π like i said in point 3. it would be very much more user friendly to have a tick, kill existing gdb server with my debugged program before starting, as you have all the parameters to identify the gdbserver and executable π
Not a request, but a nice feature πThank you guys, hope I’m not nagging, but I want show also the windows user side π
Once again fantastic product!
Best regards,Hi,
1. Thanks for the description, we will look into it.
3. Thanks for the idea, we will definitely consider it.
4. Please try specifying the sysroot location to gdb with “set sysroot” as suggested. Only the -file-list-exec-source-files command is slow with very many source files, that is why we allow disabling the use of it in GDB settings. VisualGDB itself does not have any source file amount limitations.
5. Yes, we can add an option to kill the gdbserver as well when debugging exits. We will just not enable it by default as it is normally not needed. Unless you have several debug sessions open on the same device killing the gdbserver is easy, just add a post-debug command “killall gdbserver” to be executed on the target. Killing the gdbserver will kill also the executable as gdbserver starts it.Hi,
is it possible to set intellisense source cache on local machine with relative paths?
Best regards,
- You must be logged in to reply to this topic.