If you cross-compile on the host and them move it to the target, you don't need to specify "Path mappings". Path mappings is the same as GDB substitute-path. In the first case (when you want the local copies of the libraries to be used), in the Sysroot field you need to specify the local directory that contains target libraries in the subdirectories corresponding to target paths. In the second case you don't need to specify anything in the Sysroot field. Sysroot ( ) : GDB needs to have access to the shared libraries that are used by your project this can be accomplished either by providing copies of the libraries on the host system, or by asking GDB to automatically retrieve the libraries from the target. If you have the stripped ELF on the target, you must have the Symbol File specified in CLion. If you have the binary with the DWARF debug info on the target, you don't need to specify anything in the Symbol File field. Symbol file is a file separate from the executable itself which contains program’s debugging information. > Should it be in one of the directories specified by the sysroot property?īy default the gdb in CLion uses default ~/.gdbinit.Ībout the settings for remote debug via GDB/gdbserver ( ) for a general case: See if you are not familiar with YouTrack. > CLion cannot attach to a running process with root privilegesįeel free to comment or upvote in order to get updates. I know I can run CLion as root, but I don't want to do that if I don't have too. Should it be in one of the directories specified by the sysroot property?Īny help would be appreciated. However, it is really not clear where this file should go, especially in the above configuration with as many different directories involved. I have tried the set solib-search-path to the path to the. I then start debugging and see that it connects. Path mappings: even added map from the remote /opt/PROJECT/lib to the local source location Sysroot: tried everything I can think of here so in the install directory (given above) so on the "local" machine to the "remote". Symbol file: tried several options here from pointing to the built. I setup a GDB Remote Debug configuration with I start gdbserver with this command: sudo gdbserver -attach :5432 PID so is located in /opt/PROJECT/lib (their install directories) The executable is run from /opt/PROJECT/bin. The main program is an executable that daemonizes itself and periodically calls the method to be debugged. To further complicate the situation, the method where I need to debug is located in a. This is running on the same machine, however, having the ability to attach to a node in a remote cluster would be extremely useful. Because of these two limitations, and the limitation that CLion cannot attach to a running process with root privileges unless CLion itself has root privileges, I decided to use gdbserver running via sudo and attaching to the running process. Second, it is started as a suite of other programs that together form a functional node, so it's not really possible in this scenario to start it by itself. First, the issue I have is that the program I am trying to debug must run with root privileges. I am having trouble getting remote debugging to work with CLion.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |