I am developing 8051 firmware in a project and have to use IAR as the toolchain. The build system is CMake. I cannot use the IAR IDE.
In order to optimize my source code I want to look at the disassembly of the resulting binary, preferably with labels. Is there any way to make xlink output something that I can analyse? I know that the IAR IDE debugger has a debug view, but I cannot use the IDE. It seems xlink can output a lot of file formats, but which ones allow to extract debug information on command line?
The linker is commonly not the tool to produce assembly listings. It generally only knows of bytes, sections, references to be resolved, addresses to be located, output formats to generate, and so on. Only few linkers know how to patch compiler/assembler generated listings with the final addresses.
So you would need to look at the tool that knows about machine code, the compiler or the assembler. Unfortunately IAR does not seem to provide a disassembler.
A quick web research on "iar 8051 compiler option" revealed this compiler guide. And another quick look in the table of contents led to the chapter "Descriptions of compiler options", which describes among others the option -l. The guide says:
Use this option to generate an assembler or C/C++ listing to a file. Note that this option can be used one or more times on the command line.
This should be enough to see the generated assembly. If you want the allocated addresses after linking, the linker can provide that.
Anyway, as a last resort you would like to check out decent disassemblers like Ghidra.
Related
When I debug my C++ program, I set a breakpoint on the main function. When the program starts running, it seems to have skipped several lines of source before the line at which it stops. What's the problem?
Your program is probably compiled with optimisation enabled, which means that the lines of source are not necessarily sequentially translated into machine code. Under optimisation, the execution of different parts of the source code can be re-ordered and interleaved - this is likely what you're seeing.
If you want to step through your source code in a simple, sequential line-by-line manner you will need to compile with no optimisation (-O0).
Alternatively, if you understand machine code you can use:
set disassemble-next-line on
which will show you the disassembly of the code that the debugger is stopped on alongside the source code line it belongs to.
You seem to have symbols for your program, as GDB happily reads them. However, do you have the source in the original place or are you perhaps debugging on a different machine?
What does:
info source
give you when you enter it on the command prompt? It should give you something along the lines of:
(gdb) info source
Current source file is hello.c
Compilation directory is /home/username/source
Located in /home/username/source/hello.c
Contains 7 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.
if GDB has debug symbols and source available.
From the output, however, it looks like this part should be fine, so caf is likely right that this is about the optimization level of your compiler.
Keep in mind that this is the very reason for debug versus release settings. During development you'll perhaps want -O0 or -O1 combined with -ggdb -g3 if you're using GCC to compile. For other compilers the settings may be different. For a release you'll probably want to use the highest safe optimization value (see this link), -O2 for gcc or -O3 if you are using one of the widely used architectures and aren't afraid of nasty surprises.
Either way if you are serious about software development and consequently debugging, you should learn the very basics of the assembly language for your target CPUs. Why? Because sometimes the optimizer, especially in GCC, goes haywire and does stupid things even when you tell it to not trust your code, such as with -fno-strict-aliasing. I've encountered cases where it would happily use instructions on a SPARC which are supposed to be used only on aligned data, but there was no guarantee that the data we gave it was aligned. Anyway, it's the very reason Gentoo recommends -O2 instead of any higher value for optimization. If you don't know why an assembly instruction does what it does or why your program does something silly and you can't take the magnifying glass and step down to the assembly level, you'll be lost.
How to see the assembly code in GDB
As pointed out by caf you can use set disassemble-next-line on to see the disassembly at the current program counter if you are using GDB 7.0 or newer. On older GDB versions you may resort to the trusty old display command:
disp/i $pc
which sets an automatic display for the program counter ($pc). Perhaps a better and visually more appealing alternative, especially if you have a lot of screen estate, is to use layout asm and layout regs combined in GDB. See the following screen shot:
I have some questions regarding debugging symbols and what can be done with them, besides, well, debugging. I'm mostly interested in answers regarding GCC, but I'd also be happy to know how it looks like under other compilers, including MSVC.
First of all:
What are the common formats/types of debugging symbols?
How do they relate to compilers and platforms? Is it always the same format on GCC and MinGW among platforms?
Can I check in runtime whether the build has them and what format are they in?
And some more practical questions... How can I:
Check the current file and line number?
Obtain the (qualified) function name being executed?
Obtain a full current stack trace?
Let me emphasize that I'm talking about run-time checks. All of those can be read and pretty-printed by GDB, but I don't know how much info comes from the debugging symbols themselves and how much from the source code which GDB also has access to.
Maybe there's a library which is able to parse the debugging symbols and yield such information?
Are the debugging symbols standardised well enough that I can expect some degree of portability for such solutions?
What are the common formats/types of debugging symbols?
DWARF and STABS (those are embedded inside executable, in special sections), Program Database (PDB; external file, used by MSVC).
How do they relate to compilers and platforms? Is it always the same format on GCC and MinGW among platforms?
GCC uses DWARF/STABS (I think it's a GCC compile-time option) both on Linux (ELF) and Windows (PE), don't know about others. MSVC always uses PDB.
Can I check in runtime whether the build has them and what format are they in?
You can parse the executable image and see if there are sections with debugging info (see STABS documentation and DWARF specs). PDB files are distributed either with executables or via symbol servers (so if you don't want to go online, check if there is X.pdb for X.exe/X.dll).
About how to read and use those symbols — I don't know about DWARF/STABS (there's probably something around GNU binutils that can locate and extract those), but for PDB your best bet is to use dbghelp — its usage is pretty well documented and there are a lot of examples available on the net. There's also DIA SDK that can be used to query PDB files.
Are the debugging symbols standardised well enough that I can expect some degree of portability for such solutions?
DWARF has a formal specification, and it's complicated as hell. PDB AFAIK is not documented, but dbghelp/DIA are, and are the recommended way.
From a compiled file, can I see which compiler has been used to generate the file?
There's also the good old 'strings' utility. Dumps all ascii-ish looking strings it finds in the binary. Different compilers embed different amounts of information in the binaries they produce, but many will actually include obviously identifying strings.
Many compilers/linkers insert a .comment section in the output file which identifies them. There are also a number of more subtle behaviors you could create compiler fingerprints off of, but I know of no existing tools for this.
If you have the source, the easiest solution would be to try compiling with each compiler in question until you get a binary that matches byte-for-byte (or even closely).
In some cases you can run ldd on the binary and find out which standard library it's linked against. For example on Solaris gcc vs Sun CC vs whatever.
For C++ code, you can also dump some of the symbols, find a mangled function name, and then figure out which demangler generates the correct original name.
Try, IDA Pro which identifies the libraries and tools used to build up executable file.
I was answering a quiz in a Blue Team website, and this was a question. I found the solution using a tool called PE Detective, he looks for signatures on the EXE, works really fine
https://www.softpedia.com/get/System/File-Management/PE-Detective.shtml
My definition of powerful is ability to customize.
I'm familiar with gcc I wanted to try MSVC. So, I was searching for gcc equivalent options in msvc. I'm unable to find many of them.
controlling kind of output
Stop after the preprocessing stage; do not run the compiler proper.
gcc: -E
msvc: ???
Stop after the stage of compilation proper; do not assemble.
gcc: -S
msvc: ???
Compile or assemble the source files, but do not link.
gcc: -c
msvc:/c
Useful for debugging
Print (on standard error output) the commands executed to run the stages of compilation.
gcc: -v
msvc: ???
Store the usual “temporary” intermediate files permanently;
gcc: -save-temps
msvc: ???
Is there some kind of gcc <--> msvc compiler option mapping guide?
gcc Option Summary lists more options in each section than Compiler Options Listed by Category. There are hell lot of important and interesting things missing in msvc. Am I missing something or msvc is really less powerful than gcc.
MSVC is an IDE, gcc is just a compiler. CL (the MSVC compiler) can do most of the steps that you are describing from gcc's point of view. CL /? gives help.
E.g.
Pre-process to stdout:
CL /E
Compile without linking:
CL /c
Generate assembly (unlike gcc, though, this doesn't prevent compiling):
CL /Fa
CL is really just a compiler, if you want to see what commands the IDE generates for compiling and linking the easiest thing to look at the the command line section of the property pages for an item in the IDE. CL doesn't call a separate preprocessor or assembler, though, so there are no separate commands to see.
For -save-temps, the IDE performs separate compiling and linking so object files are preserved anyway. To preserve pre-processor output and assembler output you can enable the /P and /Fa through the IDE.
gcc and CL are different but I wouldn't say that the MSVC lacks "a hell lot" of things, certainly not the outputs that you are looking for.
For the equivalent of -E, cl.exe has /P (it doesn't "stop after preprocessing stage" but it outputs the preprocessor output to a file, which is largely the same thing).
For -S, it's a little murkier, since the "compilation" and "assembling" steps happen in multiple places depending on what other options you have specified (for example, if you have whole program optimization turned on, then machine code is not generated until the link stage).
For -v, Visual C++ is not the same as GCC. It executes all stages of compilation directly in cl.exe (and link.exe) so there are no "commands executed" to display. Similarly for -save-temps: because everything happens inside cl.exe and link.exe directly, the only "temporary" files are the .obj files that cl.exe produces and they're always saved anyway.
At the end of the day, though, GCC is an open source project. That means anybody with an itch to scratch can add whatever command-line options they like with relatively little resistance. For Visual C++, a commercial closed-source product, every option needs to have a business case, design meetings, test plans and so on. Every new feature starts with minus 100 points.
Both compilers have a plethora of options for modifying... everything. I suspect that any option not present in either is an option for something not worth doing in the first place. Most "normal" users don't find a use for most of those options anyway.
If you're looking purely at the number of available options as a measure of "power" or "flexibility" then you'll probably find gcc to be the winner, simply because gcc handles many platforms other than Windows and has specific options for many of those platforms that you obviously won't find in MSVC. gcc (well, the gcc toolchain) also compiles a whole lot of languages beyond C and C++; I recently used it for Objective-C, for example.
EDIT: I'm with Dean in questioning the validity of your question. Yes, MSVC (cl) has options for the equivalent of many of gcc's options, but no, the number of options doesn't really mean much.
In short: Unless you're doing something very special, you'll find MSVC easily "powerful enough" on the Windows platform that you will likely not be missing any gcc options.
We have recently downloaded, installed and compiled gcc-3.0.4 code. gcc compiler has built successfully and we where able to compile some same test cpp file. I would like to know how we can modify gcc source code so that we add additional run time debugging statements like the binary in execution compiled by my gcc should print below statement in a log file:
filename.cpp::FunctionName#linenumber-statement
or any additional information that I can insert via this tailored compiler code.
Have you looked at the macros __FILE__ and __LINE__? They do that for you without modifying the compiler. See here for more information.
My general understand of the GCC architecture is, that it is divided into front-end (parser), middle (optimization in a special intermediate language), and a back-end (generating platform dependent output). So, for your purposes you would have to look into the back-end part.
Don't do that with an ancient compiler like GCC 3.0.
With a recent GCC 4.9 (in end of 2014 or january 2015) you could customize the compiler, e.g. with a MELT extension, which would add a new optimization pass working on Gimple. That pass would insert a Gimple statement (hopefully a call to some debugging print) before each Gimple call statement.
This is a non-trivial work (perhaps weeks of work). You need to understand all of Gimple