This generally occurs because gdb cannot load symbols for this library. To check this, open the Modules view. If your library appears in the view without a bug icon, its symbols are not loaded.
First, it needs to find this library in your shared library path on the host. You usually have to explicitly specify this in the Shared Libraries tab in the Debug tab of the launch configuration. Second, the library file name must be the same as the so name with "lib" prefix. You can check the so name if you open Properties view for the library (.so file) or open it in the Binary editor. For example, if your so name is aaa.so.1 and your library name is libaaa.so, gdb will be unable to match the two, because of the extra version number. To avoid this problem when debugging, do not use so version number when you generate the so name for your library. Third, the library has to be compiled with debug information.
Most likely when you created an image for the target board you did not include pdebug program in /usr/bin. This binary is required to be on the target for remote debugging. Also make sure that the qconn process has permissions to run it.
If you have a lot of sources in your project this may cause some gdb misbehavior while IDE trying to set search paths. If you compile on the same machine as you run it (same host) you can use this workaround: in launch configuration open Source tab, delete "Default" source lookup entry and add "Absolute Path". That should solve it.
Yes, gdb console is provided and will redirect user input to the gdb command interpreter during a debugging session. To access the console, open Console view from Windows->Show View... and click on "gdb target" of current debugging session in Debug view. Optionally, you may click on Display Selected Console button (looks like a blue monitor) on a Console view and pick gdb console from the drop down list. To execute gdb commands, simply type the command in the console. For example, show version. An example of such functionality would be setting address breakpoints and catchpoints.
First you need to create a launch configuration, select Run->Debug..., then select Attach to Process and click New button (top left). Fill in the configuration with project and binary, select target and press Debug. It will prompt you to pick a process running on selected target. Pick a process and click Ok to create the Debug session. Now you can use regular debugger commands: resume, suspend, step, etc... You can reuse same launch configuration for future runs, just re-select process id (of course the binary also has to match).
Most likely you are trying to debug optimized code. This variable has been optimized as a register and the actual memory region never changes. To fix this, turn off optimization when debugging by passing option -O0 to the gcc compiler.
The console is buffered. If you are using stderr or stdout and you want to see your output immediately you have to add "\n" or flush the output. Input is always buffered, you have to press enter from console for the application to get any of the data, even if you are reading one byte.
When you debug on Windows, IDE cannot allocate another console for your program output so it gets mixed in with debugger data. Since it uses a specific debugger protocol, some lines of your program output can be parsed as debugger commands and won't be printed back. You can mitigate this issue by enabling verbose console for gdb in the Debug tab of the launch configuration.
By default, when a program forks, gdb will continue to debug the parent process and the child process will run unimpeded. If you want to follow the child process instead of the parent process, use the command set follow-fork-mode child from gdb console. If you want to follow both processes, you can use the following workaround. Put a call to sleep (or send SIGSTOP to itself) in the code which the child process executes after the fork. It may be useful to sleep only if a certain environment variable is set, or a certain file exists, so that the delay need not occur when you don't want to run gdb on the child. While the child is sleeping, launch another debugger session that attaches to a running process and pick the child process from the list.
When using remote debugging it often happens that the binary and its libraries on the host side do not match with the binary and its target side. When using version 6.7 or greater, gdb will warn you if it thinks that some libraries don't match by printing a warning to the console. If you don't use IDE to upload your binaries and libraries, you have to take care to keep then in synch on every launch. You can check the exact files gdb is using on the host side by exploring your libraries in the Modules view.
This is again a symptom of binary/library mismatch. See "How to fix library mismatch".
If it is libc this is a lot more difficult a) You cannot debug with 6.4 tools on 6.3.2 target for example - this would be obvious mismatch b) correct libc should be included in the target image. Just copying it over would not solve the problem because default libc is usually in read-only section, like /proc/boot, c) if (b) is not possible worse case scenario you can link libc statically -Bstatic -lc