I am compiling C++ on *nix and I would like to generate a stack dump
a) at an arbitrary point in the program,
b) during any signal, particularly during SIGSEGV.
Google tells me that ptrace is probably the tool for the job, but I can't find any comprehensible examples of walking the stack. Getting the return address, yeah, but what about the NEXT return address? And what about extracting the symbolic name of the function at that point? Something to do with DWARF?
Many thanks if you can tell me where to go from here.
If you are using glibc, then the GNU functions backtrace() and backtrace_symbols() are the best way to do this. Walking the stack is going to be environment-specific anyway, so there's no downside to using the non-portable native functions on each platform to do it.
Related
I need to profile the values passed as arguments to the standard C library function sqrt() in my program.
The trivial way is to insert code to dump these values to a file before the actual call to sqrt() (e.g. a simple fprintf()). However, if sqrt() is called from inside a library, or if it is called from multiple locations, the task can become hard.
Is there a way to automatically do this in GDB or in some other debugging tool?
Thanks in advance for your help.
Best Regards.
Sure, it can be done. There is an easy way and a hard way.
The easy way is if you have debuginfo for sqrt. Most distros make this available; e.g., for Fedora you can use debuginfo-install to install it.
In this case, find the function in question, set a breakpoint on it, and have the breakpoint commands print the arguments:
break sqrt
commands
silent
info args
cont
end
If you have a new enough gdb, and you know the names of the arguments, you can use the dprintf command instead. This will give you nicer formatting and not interact badly with other debugging commands like next.
The hard way is if you don't have debug info. In this case you need to know the platform ABI. Then you can still set the breakpoint, and then print the appropriate registers or dump the appropriate memory, depending on how the arguments are passed.
Yet another way is to use SystemTap. This is a pretty good tool for this kind of tracing.
I am porting an application(in C language) from HP-UX to Linux(icc compiler). i have a problem with pstat.h. It's there only in HP-UX but not in Linux and im getting error "pstat_getproc is undeclared". Is there any alternate solution to this? Is there any substitute for sys/pstat.h? As of now I am planning to replace that whole code with something that will work on Linux. Looking forward to your solutions.
There is no direct equivalent; the whole family of pstat functions is extremely HP/UX specific. Probably the closest equivalent is the /proc interface -- to get information on the current process, for instance, one can examine the pseudofiles in /proc/self.
You will, indeed, probably need to replace most of the code which makes use of pstat.
I want to know how to write a text editor in assembler. But modern operating systems require C libraries, particularly for their windowing systems. I found this page, which has helped me a lot.
But I wonder if there are details I should know. I know enough assembler to write programs that will use windows in Linux using GTK+, but I want to be able to understand what I have to send to a function for it to be a valid input, so that it will be easier to make use of all C libraries. For interfacing between C and x86 assembler, I know what can be learned from this page, and little else.
One of the most instructive ways to learn how to call C from assembler is to:
Write a C program that calls the C function of interest
Compile it, and look at the assembly listing (gcc -S)
This approach makes it easy to experiment by starting with something that is already known to work. You can change the C source and see how the generated code changes, and you can start with the generated code and modify it yourself.
push parameter on the stack
call the function
clear the stack
The links you have in your question show all these steps.
The OS may define the calling standard (it pretty well must define the standard for invoking system calls), in which case you need only find where that is documents and read it closely.
i noticed that mingw adds alot of code before calling main(), i assumed its for parsing command line parameters since one of those functions is called __getmainargs(), and also lots of strings are added to the final executable, such as mingwm.dll and some error strings (incase the app crashed) says mingw runtime error or something like that.
my question is: is there a way to remove all this stuff? i dont need all these things, i tried tcc (tiny c compiler) it did the job. but not cross platform like gcc (solaris/mac)
any ideas?
thanks.
Yes, you really do need all those things. They're the startup and teardown code for the C environment that your code runs in.
Other than non-hosted environments such as low-level embedded solutions, you'll find pretty much all C environments have something like that. Things like /lib/crt0.o under some UNIX-like operating systems or crt0.obj under Windows.
They are vital to successful running of your code. You can freely omit library functions that you don't use (printf, abs and so on) but the startup code is needed.
Some of the things that it may perform are initialisation of atexit structures, argument parsing, initialisation of structures for the C runtime library, initialisation of C/C++ pre-main values and so forth.
It's highly OS-specific and, if there are things you don't want to do, you'll probably have to get the source code for it and take them out, in essence providing your own cut-down replacement for the object file.
You can safely assume that your toolchain does not include code that is not needed and could safely be left out.
Make sure you compiled without debug information, and run strip on the resulting executable. Anything more intrusive than that requires intimate knowledge of your toolchain, and can result in rather strange behaviour that will be hard to debug - i.e., if you have to ask how it could be done, you shouldn't try to do it.
I am currently porting our code from an alpha (Tru64) to an i386 processor (Linux) in C.
Everything has gone pretty smoothly up until I looked into porting our
exception handling routine. Currently we have a parent process which
spawns lots of sub processes, and when one of these sub-processes
fatal's (unfielded) I have routines to catch the process.
I am currently struggling to find the best method of implementing a traceback routine which can list the function addresses in the error log, currently my routine just prints the the signal which caused the exception and the exception qualifier code.
Any help would be greatly received, ideally I would write error handling for all processors, however at this stage I only really care about i386, and x86_64.
Thanks
Mark
The glibc functions backtrace() and backtrace_symbols(), from execinfo.h, might be of use.
You might look at http://tlug.up.ac.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV. It covers the functionality you need. However you must link against libgdb and libdl, compile with -rdynamic (includes more symbols in the executable), and forgo the use of some optimizations.
There are two GNU (non-POSIX) functions that can help you - backtrace() and backtrace_symbols() - first returns array of function addresses and second resolves addresses to names. Unfortunately names of static functions cannot be resolved.
To get it working you need to compile your binary with -rdynamic flag.
Unfortunately, there isn't a "best" method since the layout of the stack can vary depending on the CPU, the OS and the compiler used to compile your code. But this article may help.
Note that you must implement this in the child process; the parent process just gets a signal that something is wrong; you don't get a copy of the child stack.
If a comment, you state you are using gcc. This http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Return-Address.html#Return-Address could be useful.
If you're fine with only getting proper backtraces when running through valgrind, then this might be an option for you:
VALGRIND_PRINTF_BACKTRACE(format, ...):
It will give you the backtrace for all functions, including static ones.