I compiled the Qt Framework with debugging enabled, but the script stripped the debugging symbols from the libraries and saved them as *.debug files -- just like here.
Sadly I need these symbols inside the .so files, so I can continue working with them. There seems no way to teach my debugger to load external (non-PDB) symbols. So another way of solving my problem might be converting the .debug files to PDB format, which might also be a problem.
Thank you very much!
Related
LLVM debugger (lldb) uses a source file for debugging (e.g. for breakpoint). I want to use lldb without having source files, only with intermediate representation files (.ll files).
Is it possible? If not, can I do that with gdb debugger? Is there another idea?
I'm not sure you can debug using the IR, but in the worst case, you can always just debug the bare assembly without symbols of any kind. Having at least function labels is nice, though.
I am working with a project that was handed off to me and some of the building and linking concepts are new to me. I have a makefile, several assembly and C source files, an ELF file and binary file. When I load the ELF file onto my target, I am only able to step-through the C files, not the assembly files.
When I do a readelf on the ELF file, I see that the assembly (.S) files are missing from the symbol table. Likewise, my debugger (RealView Debugger 4.1) doesn't list those .S files in the "sources from image" tree. I can see that some of the symbols from those files are included (i.e. label names) in my readelf output, but not the file type symbols themselves. I've been going over the makefile to try to spot what may be failing to include them, but I'm not sure what I'm looking for. Can anyone please point me in the right direction? Thanks!
You mentioned using the RealView debugger so I'm making an educated guess that you have RVDS. If so, have you tried using the readelf equivalent that ships with RVDS, fromelf. I have no way to confirm this now but I recall there were subtle differences between assembly code generated by the ARM compiler and gcc.
I am porting a program to MS Windows. This program uses dynamically loaded plugins. The plugins reference symbols in the main program. I cannot even get the DLLs past the linker without all symbols being resolved. Is there a way to solve this?
(Sorry, I'd like to ask for clarification in a comment but I'm too much of a newbie to be allowed.)
When you say the plugins "reference symbols in the main program", is it about referencing functions or data? Also, what language/compiler are you using?
Assuming it's only about functions, and in C/C++: it's possible to export a function from a .EXE as if it were a DLL. Just specify __declspec(dllexport) in front of the function definition in the .EXE . When compiling the .EXE, a .LIB file should get generated, which you can then use as input when linking each plugin.
I am developing a project in VC++2008. The project uses the OpenCV library (but I guess this applies to any other library). I am working with the Debug configuration, the linker properties include the debug versions of the library .lib's as additional dependencies. In VC++ Directories under Tools|Options i set up the include directory, the .lib directory, the source directories for the library as well. I get an error while calling one of the functions from the library and I'd like to see exactly what that function is doing. The line that produces the error is:
double error = cvStereoCalibrate(&calObjPointsM, &img1PointsM, &img2PointsM,
&pointCountsM,
&cam1M, &dist1M, &cam2M, &dist2M, imgSize, &rotM, &transM, NULL, NULL,
cvTermCriteria(CV_TERMCRIT_ITER + CV_TERMCRIT_EPS, 100, 1e-5));
I set up a breakpoint at this line to see how the cvStereoCalibrate() function fails. Unfortunately the debugger won't show the source code for this function when I hit "Step into". It skips immediately to the cvTermCriteria() (which is a simple inline, macro-kinda function) and show its contents. Is there anything else I need to do to be able to enter the external library functions in the debugger?
EDIT: I think the cvTermCriteria() function shows in the debugger, because it's defined in a header file, therefore immediately accesible to the project.
EDIT2: The .pdb files were missing for the library files, now I recompiled the OpenCV library in Visual C++ in Debug configuration, the .pdb files exist but are still somehow invisible to the debugger:
Loaded 'C:\Users\DarekSz\Documents\Visual Studio 2008\Projects\libcci\Debug\ccisample.exe', Symbols loaded.
'ccisample.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll'
'ccisample.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll'
'ccisample.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll'
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cv210d.dll'
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cxcore210d.dll'
The symbols aren't loaded apparently for the opencv dlls. Still, the .pdb files exist in the \bin directory.
To sum up all the activity in the comments: the key to the solution was to rebuild the library in VC++ to obtain the .pdb (Program Debug Database) files for debugging, the precompiled "-d" suffix libraries weren't enough. Still, the import libs for the library dlls made the program load precompiled dlls from the OpenCV package tree, not the ones from my build with the .pdb information (the paths were similar so I didn't notice at first). The path to the .pdb files was provided in Tools|Options, but these files weren't loaded because of module version mismatch (obviously). Once I copied the correct dlls and their respective .pdb files to the application directory, the debugger started working inside the library functions.
Confirm: are you actually compiling the OpenCV library from source, or are you just linking against it?
A couple of possibilities come to mind:
It sounds like the debug info for the OpenCV library is not available (the PDB files). You may have to extend PATH to reference the directory containing these files. It seems to me that there is a way of doing this from VC++ but I'm a few years out from using the tool...
Is cvStererCalibrate also a "macro function"? If so, find out what real function it refers to and set the breakpoint in the library.
Finally, although you have already said so, it never hurts to go back and confirm that full debugging has been activated for everything in the project, including external libraries.
I don't know if this helps, but its a good place to start.
i got the same problems, which is:
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cv210d.dll'
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cxcore210d.dll'
I solved it by:
Linker -> Input -> Additional Dependencies add: 'cv210.lib; cxcore210.lib; highgui210.lib;'
instead of adding : 'cv210d.lib; cxcore210d.lib; highgui210d.lib;'
I'm trying to analyze a mini crash dump and need symbol files in order to get more details about the crash. Im currently just seeing:
"034eff74 0086eee9 00000000 0089d58d 034eff94 app_integrator!ZNK14ACE_Data_Block4baseEv+0x6"
Is it possible to extract debugging information from a msys/mingw gcc built dll into a windbg readable format? If not, is there any other way of getting more detailed information, like loading a MAP file in some way?
The dll and all it's contained .o files are built with the -g flag.
Windbg can't cope with the debugging information that will be generated by -g on a mingw installation. However, it can allegedly cope with COFF symbols.
If the source files for your DLL are small enough, you can probably get COFF debug information to build (-gcoff rather than -g).
So, Windbg can (allegedly) handle COFF symbols and GCC can generate them. So it should be easy from there, right? I was trying to do exactly this with a Win32 executable generated by Visual Studio 2008 that was loading a gcc-compiled DLL. Unfortunately for me, compiling with -gcoff didn't work. Mingw's gcc won't generate COFF symbols for projects with more than 64k lines of code. The DLL I was using was distincly larger then 64K code lines. Sadly I have to admit, I gave up and fell back on the trusty OutputDebugString. Otherwise I'd be able to give more complete instructions. I didn't fancy investigating the option of making gcc do COFF symbols for larger source files, or the alternative option of writing a debugging extension to parse DWARF or STABS data into windbg's internal symbol tables.
I fixed the issue, by the way!
Further suggestions can be found in this forum post at windbg.info.