In my loader section missing PE, how to fix it?
Only two options dos.ldw and Binary file.
Have nice day.
Related
I'm trying to create some debug scripts with compiled programs, for this I'm trying to create something where I prepare my variables in some code I generate and then jump into another program.
Is there a way to do that ? For example by having some C code and then jumping to a label or place in the executable. For now I'm focusing on ELF programs, but if something exists on Windows I'm also interested !
Thanks !
I've tried to bring back the ELF file into a .s for GCC and recompile, however this doesn't seem to work well for all ELF files (e.g non-PIE binaries). And I've looked to see if there were tools that would create a .s but they are either buggy, incomplete or both.
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.
As far as I have understood, COFF symbol table in the Microsoft's Portable Executable format is used to store the export, import and the debug symbols. But as we already have a .edata, .idata and .debug section for the purpose why do we need another such structure for it?
See here: http://msdn.microsoft.com/en-us/library/ms809762.aspx
"[the COFF symbol table] is only used in OBJ files and PE files with COFF debug information."
"The .rdata section is used for at least two things. [...] (In TLINK32 EXEs, the debug directory is in a section named .debug.) [...] Three main types of debug information appear: CodeView®, COFF, and FPO."
"Why would anyone need COFF debug information when the much more complete CodeView information is available? If you intend to use the Windows NT system debugger (NTSD) or the Windows NT kernel debugger (KD), COFF is the only game in town."
In other words, the COFF symbol table is used only for debugging, only for the more primitive debuggers, and is typically placed inside the .debug (or .rdata) section.
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.
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!