Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.
Related
I would like to see how Bash implements command line argument parsing and stepping through the code as it parses some trivial command should be a good way to do that. How do I set this up? Bash is normally run with
./configure
make
which creates a bash executable in the top level directory of the source code. I wanted to run that executable though GDB but it doesn't support M1 Macs so I was thinking to do it through VS Code but I don't know where to start.
To set up C/C++ debugging on VS Code, create a .vscode/launch.json file and fill in the arguments with whatever you need. See the docs here: https://code.visualstudio.com/docs/cpp/launch-json-reference.
That being said, VS Code's C/C++ debugger just hooks into an existing debugger like GDB or LLDB. If GDB can't debug your program, try LLDB (might require building Bash with LLVM instead of GCC- not 100% sure). If that's not an option, you might be out of luck with this exact question.
For setup with LLDB, see How to debug in VS Code using lldb?.
So, I am working with QEMU, and I have a system of plugins for it, that are using bunch of symbols from the main executable. Everything is working fine in Linux, but porting plugins to windows caused many inconveniences (expectedly).
At first, i struggled with linking against executable. In Linux all you need is an option -rdynamic, that is not presented in windows. Eventually, I found a solution to this problem here. So, I used --export-all-symbols linking option, and I was linking my plugins against an import library generated with -Wl,--out-implib. The result is a working qemu executable, and working plugins at the same time, all working as intended, except for gdb.
I am running gdb from MinGW64 shell like this: $ gdb --args ./qemu-system-i386w testdisk.qcow2 -monitor stdio
(gdb) break tcg-plugin.c:164
Breakpoint 1 at 0x410f1c: file C:/fromgit/plugins_test/qemu-work/tcg/tcg-plugin.c, line 164.
(gdb) run
But then i either get the following error: Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x410f1c
Command aborted.
Or it will start working, but none of breakpoints will be triggered, despite they definetely should.
I thought, that this may be caused by exporting all the symbols from qemu executable, so instead of using --export-all-symbols I qualified needed export symbols with __declspec(dllexport) attribute, but that didn't change anything. Furthermore, I discovered, that adding any export symbols at all to the executable will cause gdb to act faulty, the same way as described earlier.
It should be mentioned, that if I'm building just qemu, without any export symbols, I get an executable that works fine, and gdb is working fine with it.
So the question is - am I missing something? What can possibly cause gdb to not work?
I am using OSX 10.8.2 and gdb 6.3. I have to use both xcode 4.6.1 and xcode 3.
I have a simple c executable for which i am trying to attach gdb through command line. But i am not able to give break points. As soon as the gdb is attached i am getting the below lines.
unable to read unknown load command 0x2b
unable to read unknown load command 0x80000022
unable to read unknown load command 0x24
unable to read unknown load command 0x2a
I goggled it out and found that gdb 6.3 has few bugs for which above thing might be happening. so i thought of updating the gdb to 7.6. Even this is not happening.
Steps i did to install gdb 7.6
./congigure
make
make install
make is ending with below lines
make[8]: Nothing to be done for `all-am'.
make[1]: Nothing to be done for `all-target'.
make install with below lines
make[11]: Nothing to be done for `install-data-am'.
make[1]: Nothing to be done for `install-target'.
I want gdb which is supported by xcode 3,4.6 as well as in command line. Please help to resolve this.
They're just warnings, you're fine to ignore them. The gdb binary you're using didn't include the definitions of these load commands (LC_DYLD_INFO_ONLY, LC_VERSION_MIN_MACOSX, etc see /usr/include/mach-o/loader.h) and it's complaining about them when it parses the Mach-O binaries with them included. The gdb included in Xcode 4.6 will handle these without warning, fwiw.
As I can figure out with make command output your program is compiled and not changed. So you have to make clean your code and try again. Make sure that you are compiling the code with -g parameter of gcc to link the symbol table of C to the executable, in order to give to gdb the necessary parameters for debugging. So, you must to have a look at makefile.
I just installed Dev C++ and I am learning C programming.
the code i used was
#include <stdio.h>
int main()
{
printf("Hello world");
getch();
}
I saved it as a .c file. When I compile it works fine, but when I compile and run it says source file not compiled. So I googled buncha things and came across this video on youtube which shows you how to fix it. I also saw other forums on google which suggest the same thing... However, after doing whats asked, Now I can't even compile my code. I get this error
Compiler: Default compiler
Executing C:\Dev-Cpp\bin\gcc.exe...
C:\Dev-Cpp\bin\gcc.exe "C:\Users\ubaid\Documents\C\Untitled1.c" -o "C:\Users\ubaid\Documents\C\Untitled1.exe" -I"C:\Dev-Cpp\include" -L"C:\Dev-Cpp\lib"
gcc.exe: Internal error: Aborted (program collect2)
Please submit a full bug report.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
Execution terminated
I have also used what is asked on this link, and still no luck..
http://learntogeek.com/miscellaneous/solved-source-file-not-compiled-error-in-dev-cpp/
I am using windows 8
I was having this issue and fixed it by going to:
C:\Dev-Cpp\libexec\gcc\mingw32\3.4.2
, then deleting collect2.exe
Install new version of Dev c++. It works fine in Windows 8. It also supports 64 bit version.
Download link is http://sourceforge.net/projects/orwelldevcpp/ .
I guess you're using windows 7 with the Orwell Dev CPP
This version of Dev CPP is good for windows 8 only. However on Windows 7 you need the older version of it which is devcpp-4.9.9.2_setup.exe
Download it from the link and use it.
(Don't forget to uninstall any other version already installed on your pc)
Also note that the older version does not work with windows 8.
This maybe because the c compiler is designed to work in linux.I had this problem too and to fix it go to tools and select compiler options.In the box click on programs
Now you will see a tab with gcc and make and the respective path to it.Edit the gcc and make path to use mingw32-c++.exe and mingw32-make.exe respectively.Now it will work.
The reason was that you were using compilers built for linux.
You can always try doing it manually from the command prompt. Navigate to the path of the file and type:
gcc filename.c -o filename
I found a solution. Please follow the following steps:
Right Click the My comp. Icon
Click Advanced Setting.
CLick Environment Variable. On the top part of Environment Variable Click New
Set Variable name as: PATH then
Set Variable Value as: (" the location of g++ .exe" )
For ex. C:\Program Files (x86)\Dev-Cpp\MinGW64\bin
Click OK
This error occurred because your settings are not correct.
For example I receive
cannot open output file Project1.exe: Permission denied
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe: *** [Project1.exe] Error 1
Because I have no permission to write on my exe file.
After some investigation, and with Dr.Topaz's help, I have learned that you will want to confirm that the program set for g++ in the Compiler Options really does compile the source code. In my case, the C:\Dev-Cpp\bin\g++.exe program did not create an exe, but the C:\Dev-Cpp\bin\c++.exe program did. Either program appears to be intended to take the same arguments and options as GNU g++. I would love to find an actual doc on the Dev-C++ compiler programs, but I have not so far.
You can test the compiler program with a simple example like this:
C:\Dev-Cpp\bin\c++.exe hello.cpp -o hello.exe
Currently in 2021, the Dev-C++ site invites you to download either original Dev-C++ or a newer fork by a group named Embarcadero.
I decided to try the Embarcadero version and the experience was slightly better. The UI is still a tad dated, but the g++.exe program it came with was able to compile programs without issue. Again, take note of where the program is being installed, but in my case, the Embarcadero compiler programs were in C:\Program Files (x86)\Embarcadero\Dev-Cpp\TDM-GCC-64\bin.
Both original Dev-C++ and Embarcadero come with mingw-32 versions of the compiler programs that from what I see do work in a Git Bash console, with slight differences such as not recognizing a default locale when using the command std::cout.imbue(std::locale("")).
I faced this similar error, and none of the solutions worked.
so I tried to download the latest version from here, https://www.bloodshed.net/
I rerun the program.
and everything is now working correctly.
I was facing the same issue as described above.
It can be resolved by creating a new project and creating a new file in that project.
Save the file and then try to build and run.
Hope that helps. :)
I'm cross-compiling a project from Linux to target Windows (using mingw). The output is a DLL and p-invoking into it from C# works, but debugging is very difficult. The build outputs a .o file, which can provide symbols to gdb, but basically all I can do there is break on exceptions and find the name of the function that was executing when the exception happened; not even the full stack trace. I can't debug with WinDbg because I don't have .pdb files.
This is an open source project set up to build on Linux; I believe their build process relies on several installed Linux packages to work.
Do I have any options here? Is there a utility that can convert .o files into .pdb? Or some program that can give me more information than gdb when debugging?
Try a IDE that support mingw. For example the open source Code::blocks.
Another possibility is to do it manually: compile it with debug symbols, start you application and attach the GDB debugger to it. It is also part of the MingW32 distribution. Then you can set your breakpoints and debug your application
But I guess using Code::Block is more comfortable
By the way, the GCC compiler does not generate pdb files because it is a propietary format
What xpol means is maybe: if you have a complete mingw installation then Code::blocks can use gdb to visualize a debugging session like it is done in Visual Studio or Eclipse. See chapter "Debugger" at http://www.codeblocks.org/features
You can generate a .pdb file using cv2pdb.exe from Visual D. This works even for programs not written in D if they were compiled with mingw. Once you've downloaded and installed Visual D cv2pdb.exe can be found at C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe.
You can run cv2pdb.exe against an executable like this:
cv2pdb.exe -n target.exe
This will produce a file called target.pdb. Assuming both target.pdb and target.exe are in the current director, you can then use windbg like this:
windbg -sflags 0x80030377 -y . -z target.dmp
In this case I'm also passing a minidump file as target.dmp. This can be omitted. The -sflags 0x80030377 option tells windbg to load target.pdb even though it thinks it doesn't match target.exe.
Note, that it can take windbg a very long time to load target.pdb. Just wait until it no longer says *BUSY* to the left of the command entry box.
Alternatively you can try DrMinGW.