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.
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'm building a project for Wintel-32 with Visual Studio's MASM (it's called ML). I request map file generation in linker options. I'm specifying the /Zf option for the assembler (make all symbols global). Yet not all functions appear in the generated map file. Looks like only ones that are imported by other modules appear.
EDIT: there's a bunch of functions that are used only statically (i. e. within the same source file). They are not eliminated from the executable and they shouldn't be. But they don't appear in the MAP file. I want them there.
Those names can be seen if I call dumpbin /symbols on the object file (but only with the /Zf). Yet linker strips it from the final executable's map for some reason. The linker options /MAP and /MAPINFO:EXPORTS are there. What am I missing?
EDIT: and /OPT:NOREF too.
Probably the following options are enabled in your project.
- COMDAT generation i.e. Function-Level Linking during compilation.
- /OPT=NOREF linker optimization during linking.
Both the above options tell the compiler/linker to discard unused functions.
For example, update the command invoking the MASM linker ML, with the /OPT linker option as follows to retain even unused functions in the final executable:
ML [you-options] <your-file-name>/link /OPT:REF
I am compiling a program in which a header file is defined in multiple places. Contents of each of the header file is different, though the variable names are the same internal members within the structures are different .
Now at the linking time it is picking up from a library file which belongs to a different header not the one which is used during compilation. Due to this I get an error at link time.
Since there are so many libraries with the same name I don't know which library is being picked up. I have lot of oems and other customized libraries which are part of this build.
I checked out the options in gcc which talks about selecting different library files to be included. But no where I am able to see an option which talks about which libraries are being picked up the linker.
If the linker is able to find more than one library file name, then which does the linker pick up is something which I am not able to understand. I don't want to specify any path, rather I want to understand how the linker is resolving the multiple libraries that it is able to locate. I tried putting -v option, but that doesn't list out the path from which the gcc picks up the library.
I am using gcc on linux.
Any help in this regard is highly appreciated.
Regards,
Chitra
Passing -Wl,-t to gcc will tell ld to dump which files it's reading.
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!