I used GDB (DSF) in order to debug DLL builds in eclipse.
Can someone tell me what "DSF" means? I need a reference for my thesis.
Related
I compiled my application with debug symbols using clang. When attaching to the application using lldb and stepping into, for example, __cxa_throw, I don't see the source code of libc++abi.dylib. What am I doing wrong?
You do get some debug information for the STL, because a lot of the STL code is in header files that get compiled into your application. But you don't have debug information for the code that is actually compiled into libc++abi.dylib, since Apple doesn't distribute dSYM's for system libraries. __cxa_throw is actually a function in the library.
As a separate issue, because most people don't actually want to step into STL code, lldb has a setting:
(lldb) set show target.process.thread.step-avoid-regexp
target.process.thread.step-avoid-regexp (regex) = ^[^ ]+ std::|^std::
that will cause stepping to artificially step over code from the STL. You can undo this by setting that value to "". That will get you into the inlined code when stepping.
I've been using the JetBrains IDE AppCode for a few years now, but I've never had the need to pass command line arguments to the debugger before. As you probably know, in order to link the compiler with the necessary curses files, you have to include -lcurses in the command line to compile the program. The issue I'm having is that I'm not exactly sure how to correctly pass this parameter to the debugger. Thanks in advance.
A debugger should not need the list of libraries since all of the relevant information about linked libraries exists in the executable which is being debugged.
I have the following problem:
I have a Matlab program in form of some set of *.m files. It is later compiled into executable and used. The problem is that occasionally the resulted executable just hangs and this behavior cannot be reproduced when debugging/running *.m files from IDE (even using the same input data).
To figure out what hapens I intended to:
compile (somehow) *.m files into C/C++
compile C/C++ as debug to get .exe and .pdb
And later when .exe hangs just 'attach' visual studio debugger to hanged .exe to check where it 'loops/waits'.
Unfortunaley Matlab Compiler (as I was told today) does not produce C/C++ code before creating executable. I was misleaded by -g option of mcc which according to the documenttion is supposed to do the following:
-g Generate Debugging Information
Include debugging symbol information for the C/C++ code generated by MATLAB Compiler.
It looks exacly like the thing I want to archive.
I would appreciate if someone could explain me that discapency or suggest how to archive what I am trying to do (if it can be done at all).
It is not possible to create a debuggable code in Matlab compiler, because the deployed code uses MCR. (Matlab virtual machine) .
See this question : Is there any way to debug compiled components using Matlab Debugger?
Since you don't have errors, but rather an infinite loop, the best solution in that case would be screen outputs, and hopefully you will trace the bug.
Firstly, I come from Windows-VisualStudio-C++ background. Now I am developing in a Ubuntu environment.
With the help of a Makefile, I built a mymodule.so and copied it to the modules folder within apache. Now, it appears that the module is working fine. But I would like to debug into this module to understand it better.
So, first, is there any way I can get something similar to the Visual Studio debugger type of feel while debugging this module?
Now, i read that i can use gdb to debug into apache modules, can somebody tell me in detail how this is done or point me to some resource that does it.
Ideally, i would like to single step and stuff. I am trying Code::Blocks IDE which has some debugging support. Using the IDE and custom make file, I build the module. Copied it to module location, but how do i debug.
How do i hook to the apache process. Should I use Attach to Process. I tried that with the pid of httpd, but with no success.
Also, while building is there some flag that i should set so that the .so file is debuggable?
I am pretty basic with Linux because i come from windows programming background. Kindly suggest how I go about this.
Thanks in advance,
Arjun
I think you can attach to an apache process using gdb (at 1111, where 1111 is the PID of the process, or in Code::Blocks) and set breakpoints in your module functions, if the module was compiled with debug. You will need to be root or the same user as the apache process.
gcc -g flag is used to build binaries with the debug info.
I'm trying to debug a C DLL that I'm using with a Delphi program. I built the DLL with Visual C++, with debug information enabled. I built the Delphi program with Delphi 2009, with debug information enabled. But apparently they use different formats, because when I try to attach the VC++ debugger to my program, it says "binary was not built with debug information" and won't even accept as valid the breakpoints I put in the C code, which was built with debug info in the format VC++ understands.
Does anyone know how I can get this to work?
When you say "won't accept as valid" the debug breakpoints in the C code what do you mean exactly? Does it not enable them? If so has the DLL been loaded yet when you set the breakpoints? I find it can simplify matters if I wait to set the breakpoints until after I'm sure the DLL in question has been loaded. If this is not what is happening, please elaborate on what you mean by "valid" breakpoints.
Other options are to set function breakpoints, or the compile the DLL with strategically placed DebugBreak() calls.
Are you sure it's the right DLL that's being loaded (i.e. the debug version)?. Again, even the right DLL is being loaded I'm not sure the error is necessarily applying to the DLL and not just the main executable. Or it could be having problems loading the symbol database as suggested by jdigital, assuming you extract them out for debug builds of your DLL. Even with no debugging symbols, debugging should still be feasible, especially since it's a DLL, you can work from the exported symbols.
This isn't a COM component is it? If it is, I'd double check that the debug version was the one registered before you start up your process.
Again I'd still be interested in hearing exactly what happens when you try to set a break point. If you go to the breakpoints window in VS it should clarify why the breakpoint couldn't be set, if that's what is happening.
Hmm. I don't have much experience with /Z7, do you still have the .obj file for the DLL? The docs seem to imply that's necessary for debugging. Alternatively I'd try building with /Zi instead and getting a .pdb for that sucker.
Not sure about Visual C++ (don't have it installed at all anymore), but maybe this will help...
If you were writing a DLL in Delphi and using it from C++, and you wanted to debug the DLL, you'd open the source for the DLL in Delphi and set a breakpoint. You'd then use Run|Parameters and set the C++ application as the host executable and hit run in the Delphi IDE. The IDE would then launch the C++ application and run it as usual until the breakpoint in the DLL was hit, and then would break as you'd expect.
Is something similar available in VC++? (You didn't say which version of VC++, or which version of Visual Studio or the earlier IDE you were using.)
If not, the only alternative I could think of is to do a quick VC++ app that uses the DLL and debug via that instead.
Debug formats are not standardised - basically you can't use Delphi to debug MS compiled code or vice versa.
You can debug Delphi DLLs in Delphi and you can use those DLLs with other apps not compiled with Delphi, provided you mark the Delphi functions for export. What you can't do is debug those DLLs symbolically in a 3rd party debugger, which would have to understand Object Pascal name mangling at the very least.
Have you pointed the debugger at the symbols for your DLL? If there's any doubt, try running with Filemon to see if the debugger is failing when it tries to load the symbols.
Insure that is opening the DLL in the Debug Folder, not another one in some other folder.
Ten years later and this is happening to me, while debugging a custom DLL used in Team Developer, setting debugging command to start the Team Developer IDE. The objective is to step through the 3rd party code to the point of invocation of an exported function from the DLL.
Starting the debugger launches the IDE without error, but running the TD project within the TD IDE causes an exception in VS on a DLL used by the TD IDE.
How do I ignore the exceptions from outside the project? Has anyone been able to get around this since '09?