I'd like to ask if there is any option to gcc for Linux which allows debugging stack frames of given procedure of program written in C?
I know I can compile my program with -ggdb3 gcc parameter and it allows me to find out what are the symbols in this program. But is there any method to find out how the procedures arguments are passed (via stack or registers)?
I've got program which overwrites stack causing SEGV and I'd like to analyse it from the same program. First I'd like to find the problematic procedure and then I'm planning to find the place of the error.
You have a few options. One I prefer is to look at the actual generated code as it tells me exactly what is being executed. You can get this when compiling with gcc or g++. This will create a file with a .S suffix.
For example, gcc -S helloworld.c will also create a file called helloworld.S which contains the assembly code.
If you don't have source you can use tools like objdump to turn the binary code into a disassembly.
Lots of examples if you search for gcc assembly output
Related
To debug my C code I compile it with the -g flag and use lldb to see where my seg fault is for example.
I use the -g flag so the output of lldb is in C not Assembly.
but now I have a multiple files project and lldb shows only Assembly even tho I'm using the -g flag, it's like the -g flag applies only to one file.
Example:
gcc -g example.c
lldb a.out
>run
I get c code here
gcc -g example1.c example2.c main.c
lldb a.out
>run
I get assembly code here
Can anyone tell me what I'm I missing here?
and how can I get c code in lldb.
Thanks in advance.
When you just run the program you shouldn't be getting code at all.
You will be getting code if the program stops running. Then you need to look at the call stack to make sure you're actually in your own code.
If you're in library code then it will likely not have source available and you'll get assembler code. Go up the call-stack until you reach your own code.
GNU’s documentation for the ‘gcc -g’ says
Produce debugging information in the operating system’s native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.
Notice that it makes no mention of either C or assembler.
I imagine that in your first example the error was in your C code; in your second example the error was in a library, such as stdio, for which the debugger doesn’t have C source.
A segmentation fault corresponds to an invalid address. This might mean that you passed invalid data to a library that was expecting a pointer, or you passed a pointer to a buffer but an incorrect length.
A typical error that might cause this is passing a value (v) to a library that is expecting a pointer (&v).
I have this program called parser I compiled with -g flag this is my makefile
parser: header.h parser.c
gcc -g header.h parser.c -o parser
clean:
rm -f parser a.out
code for one function in parser.c is
int _find(char *html , struct html_tag **obj)
{
char temp[strlen("<end")+1];
memcpy(temp,"<end",strlen("<end")+1);
...
...
.
return 0;
}
What I like to see when I debug the parser or something can I also have the capability to change the lines of code after hitting breakpoint and while n through the code of above function. If its not the job of gdb then is there any opensource solution to actually changing code and possible saving so when I run through the next statement in code then changed statement before doing n (possible different index of array) will execute, is there any opensource tool or can it be done in gdb do I need to do some compiling options.
I know I can assign values to variables at runtime in gdb but is this it? like is there any thing like actually also being capable of changing soure
Most C implementations are compiled. The source code is analyzed and translated to processor instructions. This translation would be difficult to do on a piecewise basis. That is, given some small change in the source code, it would be practically impossible to update the executable file to represent those changes. As part of the translation, the compiler transforms and intertwines statements, assigns processor registers to be used for computing parts of expressions, designates places in memory to hold data, and more. When source code is changed slightly, this may result in a new compilation happening to use a different register in one place or needing more or less memory in a particular function, which results in data moving back or forth. Merging these changes into the running program would require figuring out all the differences, moving things in memory, rearranging what is in what processor register, and so on. For practical purposes, these changes are impossible.
GDB does not support this.
(Apple’s developer tools may have some feature like this. I saw it demonstrated for the Swift programming language but have not used it.)
I'm currently trying to figure out the way to produce equivalent assembly code from corresponding C source file.
I've been using the C language for several years, but have little experience with assembly language.
I was able to output the assembly code using the -S option in gcc. However, the resulting assembly code contained call instructions which in turn make a jump to another function like _exp. This is not what I wanted, I needed a fully functional assembly code in a single file, with no dependency to other code.
Is it possible to achieve what I'm looking for?
To better describe the problem, I'm showing you my code here:
#include <math.h>
float sigmoid(float i){
return 1/(1+exp(-i));
}
The platform I am working on is Windows 10 64-bit, the compiler I'm using is cl.exe from MSbuild.
My initial objective was to see, at a lowest level possible, how computers calculate mathematical functions. The level where I decided to observe the calculation process is assembly code, and the mathematical function I've chosen was sigmoid defined as above.
_exp is the standard math library function double exp(double); apparently you're on a platform that prepends a leading underscore to C symbol names.
Given a .s that calls some library functions, build it the same way you would a .c file that calls library functions:
gcc foo.S -o foo -lm
You'll get a dynamic executable by default.
But if you really want all the code in one file with no external dependencies, you can link your .c into a static executable and disassemble that.
gcc -O3 -march=native foo.c -o foo -static -lm
objdump -drwC -Mintel foo > foo.s
There's no guarantee that the _exp implementation in libm.a (static library) is identical to the one you'd get in libm.so or libm.dll or whatever, because it's a different file. This is especially true for a function like memcpy where dynamic-linker tricks are often used to select an optimal version (for your CPU) at run-time.
It is not possible in general, there are exceptions sure, I could craft one so that means other folks can too, but it isnt an interesting program.
Normally your C program, your main() entry point is only a percentage of the code. There is a bootstrap that contains the actual entry point for the operating system to launch your program, this does some things that prepare your virtual memory space so that your program can run. Zeros .bss and other such things. that is often and or should be written in assembly language (otherwise you get a chicken and egg problem) but not an assembly language file you will see unless you go find the sources for the C library, you will often get an object as part of the toolchain along with other compiler libraries, etc.
Then if you make any C calls or create code that results in a compiler library call (perform a divide on a platform that doesnt support divide, perform floating point on a platform that doesnt have floating point, etc) that is another object that came from some other C or assembly that is part of the library or compiler sources and is not something you will see during the compile/assemble/link (the chain in toolchain) process.
So except for specifically crafted trivial programs or specifically crafted tools for this purpose (for specific likely baremetal platforms), you will not see your whole program turn into one big assembly source file before it gets assembled then linked.
If not baremetal then there is of course the operating system layer which you certainly would not get to see as part of your source code, ultimately the C library calls that need the system will have a place where they do that, all compiled to object/lib before you use them, and the assembly sources for the operating system side is part of some other source and build process somewhere else.
Is there anywhere I can find side-by-side examples of dead simple C and x86 programs? The examples I've found so far on the Internet seem to jump straight from "here's Hello World in x86" to "write your own operating system!" I'm having trouble internalizing what has to happen when you do things like call a function.
I would recommend a look at GCC's intermediate assembly output, for example call
gcc -S a.c
then look at a.s
Most of the time, smaller and easier to understand assembly is generated by optimizing, so you would rather use
gcc -O -S a.c
If you mean x86 assembly language, use objdump --disassemble myprog (on any GNU system) to show the assembly language generated by your C program. If your system doesn't have objdump, you can use ndisasm.
Assuming you mean x86 assembler then with gcc you can use gcc -S yourhelloworldprogram.c to get assembler output. For Visual Studio you can get assembler output by following this: How do I get the assembler output from a C file in VS2005
I reccommend ddd. You can have the both C sources (if you built with debug symbols) and the machine code showing. You can also step over the code interactively probing register and memory values. A great learning tool.
On gcc you can use the -save-temps -fverbose-asm options which is better than the -S option because it still generates the object file and you get also the preprocessor file. The verbose-asm is also important because it adds comments to the assembly output that make the link between the function and variable names of your program and the generated assembly code. Especially when generating with optimization it often is difficult to make the link between the source C and the assembly.
I have an embedded hardware system which contains a bootloader based on ARMboot (which is very similar to Uboot and PPCboot).
This bootloader normally serves to load uClinux image from the flash. However, now I am trying to use this bootloader to run a standalone helloworld application, which does not require any linked library. Actually, it contains only while(1){} code in the main function.
My problem is that I cannot find out what GCC settings should I use in order to build a standalone properly formatted binary.
I do use following build command:
cr16-elf-gcc -o helloworld helloworld.c -nostdlib
which produces warning message:
warning: cannot find entry symbol _start; defaulting to 00000004
Thereafter, within the bootloader, I upload a produced application and start it at some address:
tftpboot 0xa00000 helloworld
go 0xa00004
But it doesn't work :(
The system reboots.
Normally it should just hang (because of while(1)).
I don't know that loader, but I think you should use objcopy like this to dump your executable data to a raw binary file. Don't jump to ELF headers, people :)
objcopy -O binary ./a.out o.bin
Also try to compile position independent code and to read ld and gcc manuals.
The linker is complaining about missing startup code.
You need to provide two things: startup code and a linker command file that defines the address map of your target processor.
In your case the startup code is as "bl main", but usually the startup code will initialize the stack pointer at least before branching to main.
If you know you are loading your example into RAM, you can start your program at main directly. You'll need to determine main()'s address ate use that for your "go" command.
I operate on the ARM non-os non-lib all day every day. This is my current gcc options:
arm-whatever-gcc -Wall -O2 -nostdlib -nostartfiles -ffreestanding -c hello.c -o hello.o
then I use the linker to combine the C code with the vector tables and such, even if it is not an image that needs a vector table using a vector table makes it easy to put your entry point on the first instruction.
Any reason you can't statically link at least the standard libraries in? You should have a working program and the benefits of the standard libraries without external dependencies.
Also, does your toolchain/IDE provide differentiate between "standalone application" and "linux application"? The IDE for the AVR32 has that distinction and is able to generate either a program that runs within the embedded linux environment or a standalone program that basically becomes the OS.