Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Does anyone know some tools to create a call tree for C application that will run on a microcontroller (Cortex-M3)? It could be generated from source code (not ideal), object code (prefered solution), or at runtime (acceptable). I've looked at gprof, but there's still a lot missing to get it to work on an embedded system.
An added bonus would be that the tool also gives the maximum stack depth.
Update: solution is preferably free.
One good way to achieve this is by using the --callgraph option to the ARM linker (armlink) that is part of RVCT (not free).
For more details - callgraph documentation.
I realize from one of the comments that you are looking for a gcc-based solution, which this isn't. But it may still be helpful.
From source code, you can use Doxygen and GraphViz even if you don't already use Doxygen to document your code. It is possible to configure it so that it will include all functions and methods whether or not they have documentation comments. With AT&T Graphviz installed, Doxygen will include call and caller graphs for most functions and methods.
From object code, I don't have a ready answer. I would imagine that this would be highly target dependent since even with the debug information present, it would have to parse the object code to find calls and other stack users. In the worst case, that approach seems like it would require effectively simulating the target.
At runtime on the target hardware your choices are going to depend in part on what kind of embedded OS is present, and how it manages stacks for each thread.
A common approach is to initialize each stack to a known value that seems unlikely to be commonly stored in automatic variables. An interrupt handler or a thread can then inspect the stack(s) and measure an approximate high water mark.
Even without pre-filling the stack and later walking it to look for footprints, an interrupt could just sample the current value of the stack pointer (for each thread) and keep a record of its greatest observed extent. That would require storage for a copy of each threads SP, and the interrupt handler wouldn't have very much work to do to maintain the information. It would have to access the saved states of all the active threads, of course.
I don't know of a tool that does this explicitly.
If you happen to be using µC/OS-II from Micrium as your OS, you might take a look at their µC/Probe product. I haven't used it myself, but it claims to allow a connected PC to observe program and OS state information in near real time. I wouldn't be surprised if it is adaptable to another RTOS if needed.
Call graphs from source code is no problem as mentioned above your compiler or doxygen can generate this information from source code. Most modern compilers can generate a call graph as part of the compile process.
On a previous embedded projects I filled that stack with a pattern and ran a task. Check up to which point the stack destroyed my pattern. Reload stack with pattern and run the next task. This makes your code very ssslloowww .... but is free. It is not fully accurate because all the data is timing out the whole time and the code spends lots of time in error handlers.
On some processors you can get a trace pod so that you can monitor code cover and what not if your processor needs to run at full speed to test and you can also not use instrumented code. Unfortunately these types of tools are very expensive. Look at Green Hills Time machine if you have money. This make all types of debugging easier.
Check out StackAnalyzer.
I haven't used these, but are you aware of:
calltree
cflow
Since they analyse the source code, they don't calculate stack depth.
Note, Doxygen can do "call graphs" and "caller graphs" but I believe these are per-function and only show the tree up to a certain number of "hops" from each function.
Stack depth and/or call tree generation may be supported by compiler tools. For example, for Renesas micros there is a utility called Call Walker.
My calltree graph generator, implemented in bash, using cscope and dot.
Can generate graphs of upstream callers, downstream callees, and call-associations between functions. You can set it up to view graphs in a number of ways, including xfig, .png viewers, and the dynamic dot visualiztion tool "zgrviewer".
http://toolchainguru.blogspot.com/2011/03/c-calltrees-in-bash-revisited.html
Just a thought. Is it possible to run it in a virtual machine (like Valgrind) and take stack samples ?
Eclipse with CDT has C/C++ indexing and will show you a call graphs. As far as I know, you don't need to be able to build in Eclipse to get the indexer to work, just make sure all your source files are in the project.
It works pretty nicely.
Visual Studio will do similar (but it's not free). I use Visual Studio to work on embedded projects; using a makefile project I can do all the work except debugging in the VS IDE.
I have suggested this approach already in another discussion about embedded development, but if you really need a callgraph, as well as stack use info, and all this for free, I would personally consider using an open source emulator to simulate the whole thing, while instrumenting the object code by adding a handful hooks to the emulator itself to get this data.
I am not familiar with this particular target, but there is a whole number of open source ARM emulators available (freshmeat, sourceforge, google), and you are probably mostly interested in opcodes related to call/ret and push/pop?
For example check out skyeye.
So, even if you find that it's not straightforward to extend a compiler or an emulator to provide this information, it should still be possible to create a simple script in order to look for the entrypoint and all calls/rets, as well as opcodes related to stack usage.
Of course, the only reliable information on stack usage is going to come from runtime instrumentation, preferably exercising all important code paths.
A pretty light tool: Egypt
Use Understand: http://www.scitools.com/
It's not free, and runs on source (not runtime), but it works, it works well, and it's well supported.
It will tell you much more than could ever want to know about your code.
I know this is reponding to a very old question, but someone might stumble upon this with the same question...
I recently experimented with a Python script that analyses the assembler version of the application, extracts the stack usage and the call tree, and reports the maximum stack use. In my build system I then use this to create a stack of exactly that size.
I used it only on small applications, but it seems to work OK for AVR8, MSP430, and Cortex-M3. Obviously, there are strict limitations: no indirect calls (no function pointers, no virtual functions), no recursion, and stack-using assembler instruction patterns that are used are limited to what I found in GCC's output. If these limitations are not met, the script will report an error.
The Python source is 24k, free (boost license), not very fast, and still under development. Contact me if you are interested.
Related
I'm debugging a program written in plain C (no C++, MFC, .NET, etc.) to the WIN32API. It must compile in both VS2005 (to run under Win 2K/XP) and VS2010 (to run under Win7.) I've been unable to duplicate a bug that my customer seems able to duplicate fairly reliably, so I'm looking for ways to have my program "debug itself" as-it-were. It is monitoring all of the key values that are changing, but what I'd really like to see is a stack dump when a value changes. Oh, I cannot run a "true" debug build (using the debug libraries) without installing the compiler on the customer's machine and that is not an option, so this must be built into my release build.
Is there any way to do this other than just adding my own function entry/exit calls to my own stack monitor? I'd especially like to be able to set a hardware breakpoint when a specific memory address changes unexpectedly (so I'd need to be able to disable/enable it around the few EXPECTED change locations.) Is this possible? In a Windows program?
I'd prefer something that doesn't require changing several thousand lines of code, if possible. And yes, I'm very underprivileged when it comes to development tools -- I consider myself lucky to have a pro version of the Visual Studio IDEs.
--edit--
In addition to the excellent answers provided below, I've found some info about using hardware breakpoints in your own code at http://www.codereversing.com/blog/?p=76. I think it was written with the idea of hacking other programs, but it looks like it might work find for my needs, allowing me to create a mini dump when an unexpected location writes to a variable. That would be cool and really useful, especially if I can generalize it. Thanks for the answers, now I'm off to see what I can create using all this new information!
You can use MiniDumpWriteDump function which creates a dump, which can be used for post-mortem debugging. In the case application crashes, you can call MiniDumpWriteDump from unhandled exception handler set by SetUnhandledExceptionFilter. If the bug you are talking about is not crash, you can call MiniDumpWriteDump from any place of the program, when some unexpected situation is detected. More about crash dumps and post-mortem debugging here: http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu
The main idea in this technique is that mini dump files produced on a client site are sent to developer, they can be debugged - threads, stack and variables information is available (with obvious restrictions caused by code optimizations).
There are a bunch of Win32 functions in dbghelp32.dll that can be used to produce a stack trace for a given thread: for an example of this see this code.
You can also look up the StackWalk64() and related functions on MSDN.
To get useful information out, you should turn on PDB file generation in the compiler for your release build: if you set up your installer so that on the customer's computer the PDB files are in the same place as the DLL, then you can get an intelligible stack trace out with function names, etc. Without that, you'll just get DLL names and hex addresses for functions.
I'm not sure how practical it would be to set up hardware breakpoints: you could write some sort of debugger that uses the Win32 debugging API, but that's probably more trouble than its worth.
If you can add limited instrumentation to raise an identifiable exception when the symptom recurs, you can use Process Dumper to generate a full process dump on any instance of that exception.
I find I cite this tool very frequently, it's a real godsend for hard-to-debug production problems but seems little-known.
Can you decompile a c dll to use pinvoke on or use reflector?
How do I get the method names and signatures?
Simply put there is no trivial way to do what you want. You can use a disassembler library such as distorm to disassemble the code around the exported entry points, though. There are some heuristics one can use, but many of those will only work with 32bit calling conventions (__stdcall and __cdecl) in particular. Personally I find the Python bindings for it useful, but libdasm can do the same.
Any other tool with disassembler capabilities will be of great value, such as OllyDbg or Immunity Debugger.
Note: if you have a program that already calls the DLL in question, it is most of the time very worthwhile to run that under a debugger (of course only if the code can be trusted, but your question basically implies that) and set breakpoints at the exported functions. From that point on you can infer a lot more from the runtime behavior and the stack contents of the running target. However, this will still be tricky - particularly with __cdecl where a function may take an arbitrary amount of parameters. In such a case you'd have to sift through the calling program for xrefs to the respective function and infer from the stack cleanup following the call how many parameters/bytes it discards. Of course looking at the push instructions before the call will also have some value, though it requires a little experience especially when calls are nested and you have to discern which push belongs to which call.
Basically you will have to develop a minimal set of heuristics matching your case, unless you have already licensed one of the expensive tools (and know how to wield them) that come with their own heuristics that have usually been fine-tuned for a long time.
If you happen to own an IDA Pro (or Hex-Rays plugin) license already you should use that, of course. Also, the freeware versions of IDA, although lagging behind, can handle 32bit x86 PE files (which includes DLLs, of course), but the license may be an obstacle here depending on the project you're working on ("no commercial use allowed").
You can use dependency walker.
http://www.dependencywalker.com/
You can find the exported function names with dumpbin or Dependency Walker. But to know how to call the functions you really need a header file and some documentation. If you don't have those then you will have to reverse engineer the DLL and that is a very challenging task.
I'm looking for a quick guide to basic dll hooking in windows with C, but all the guides I can find are either not C, or not windows.
(The DLL is not part of windows, but a third party program)
I understand the principle, but I don't know how to go about it.
I have pre-existing source code in C++ that shows what I need to hook into, but I don't have any libraries for C, or know how to hook from scratch.
The detours license terms are quite restrictive.
If you merely want to hook certain functions of a DLL it is often cheaper to use a DLL-placement attack on the application whose DLL you want to hook. In order to do this, provide a DLL with the same set of exports and forward those that you don't care about and intercept the rest. Whether that's C or C++ doesn't really matter. This is often technically feasible even with a large number of exports but has its limitations with exported data and if you don't know or can't discern the calling convention used.
If you must use hooking there are numerous ways including to write a launcher and rewrite the prepopulated (by the loader) IAT to point to your code while the main thread of the launched application is still suspended (see the respective CreateProcess flag). Otherwise you are likely going to need at least a little assembly knowledge to get the jumps correct. There are plenty of liberally licensed disassembler engines out there that will allow you to calculate the proper offsets for patching (because you don't want to patch the middle of a multi-byte opcode, for example).
You may want to edit your question again to include what you wrote in the comments (keyword: "DLL hooking").
loading DLLs by LoadLibrary()
This is well known bad practice.
You might want to look up "witch" or "hctiw", the infamous malware dev. there's a reason he's so infamous - he loaded DLLs with LoadLibrary(). try to refrain from bad practice like that.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I am looking for a small libc for embedded use with freertos on a ARM7 microcontroller.
I have looked at newlib, but it is a bit too complex for my needs. Newlib calls malloc() in
a number of functions (e.g. printf()), which is not good for small embedded realtime systems.
Does anyone know of a small, portable, open source libc implementation that will fit my application?
PDCLib might fit your needs. It's still incomplete [broken link], though, and probably in need of a lot more real-world testing. Its author goes by DevSolar here on SO.
update 2012-11-01: As of 2012-08-14, development has been taken over by Owen Shepherd, complete with a new homepage and bitbucket repository [broken link, use this one].
update 2015-10-31: The dedicated website seems to be dead, but the code can still be found on bitbucket. The last commit to that repository happened 2014-11-24.
update 2016-07-12: The website is back up, and DevSolar started committing again on 2016-03-01.
I use newlib on my Cortex_M3 with 32kB RAM, and to eliminate the malloc() you can use siprintf() or sniprintf().
Pro: No more calls to malloc().
Con: It does not suport formatting float and double, and is not really portable this way.
If you use newlib and do not implement the sbrk syscall, then any function you use that requires malloc will generate a linker error, which will prevent you from inadvertently using a call that requires dynamic memory . So I would suggest that you do that, and then simply avoid those functions that cause the linker error. You can modify or override any library functions you do not wish to use.
printf() is not good for small embedded realtime systems!
Actually it is worse than malloc in many ways. Variable argument lists, very complex formatting, float number support when you don't need it etc etc. printf() comes with an enormous overhead, and the compiler will not be able to reduce it, as every parameter passed to it is evaluated in runtime.
printf() is perhaps ok for hobbyists and beginners still learning C. But if you are a professional programmer, you really ought to write your own serial monitor / LCD routines. You will dramatically improve the program performance and flash consumption.
I had similar needs and found that klibc fit it quite well. The only downside (for commercial use) is that the distribution includes a few GPL-licensed files, even though most of it is BSD-licensed. I have hacked a minimal version of it here.
This is even more limited than PDCLib, and suitable if you just need a few basic functions such as printf and strtok. Compiles to just 4kB with all functions included.
You might want to look into the Embedded Artistry libc, which promises to be minimal and well-tested. It includes a malloc-free printf(). Disclaimer: I have not used it, but it appears well-structured and actively developed.
You can check out the LGPL µClibc, which is supposed to be close to glibc but much more suited to embedded systems.
It also has a page referencing other open source C libraries, including newlib and eCos, which may be more suited for non-Linux environments.
Look into uClibc and EGLIBC, perhaps.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm working on a project where I'm coding in C in a UNIX environment. I've been using the lint tool to check my source code. Lint has been around a long time (since 1979), can anyone suggest a more recent code analysis tool I could use ? Preferably a tool that is free.
Don't overlook the compiler itself. Read the compiler's documentation and find all the warnings and errors it can provide, and then enable as many as make sense for you.
Also make sure to tell your compiler to treat warnings like errors so you're forced to fix them right away (-Werror on gcc).
By the way, don't be fooled -Wall on gcc does not enable all warnings.
You may want to check valgrind (free!) — it "automatically detect[s] many memory management and threading bugs, and profile[s] your programs in detail." It isn't a static checker, but it's a great tool!
For C code, you definitely should definitely use Flexelint. I used it for nearly 15 years and swear by it. One of the really great features it has is that warnings can be selectively turned off and on via comments in the code ("/* lint -e123*/"). This turned out to be a powerful documentation tool when you wanted to something out of the ordinary. "I am turning off warning X, therefore, there is some good reason I'm doing X."
For anybody into interesting C/C++ questions, look at some of their examples on their site and see if you can figure out the bugs without looking at the hints.
I've heard good things about clang static analyzer, which IIRC uses LLVM as it's backend. If that's implemented on your platform, that might be a good choice.
From what I understand, it does a bit more than just syntax analysis. "Automatic Bug Finding", for instance.
You can use cppcheck. It is an easy to use static code analysis tool.For example:
cppcheck --enable=all .
will check all C/C++ files under the current folder.
I recently compiled a list of all the static analysis tools I had at my disposal, I am still in the process of evaluating them all. Note, these are mostly security analysis tools.
splint
RATS
SMATCH
Uno
We've been using Coverity Prevent to check out C++ source code.
It's not a free tool (although I believe they offer free scanning for open source projects), but it's one of the best static analysis tools you'll find. I've heard it's even more impressive on C than on C++, but it's helped us avoid quite a number of bugs so far.
Lint-like tools generally suffer from a "false alarm" problem: they report a lot more issues than really exist. If the proportion of genuinely-useful warnings is too low, the user learns to just ignore the tool. More modern tools expend some effort to focus on the most likely/interesting warnings.
PC-lint/Flexelint are very powerful and useful static analysis tools, and highly configurable, though sadly not free.
When first using a tool like this, they can produce huge numbers of warnings, which can make it hard to differentiate between major and minor ones. Therefore, it is best to start using the tool on your code as early in the project as possible, and then to run it on your code as often as possible, so that you can deal with new warnings as they come up.
With continual use like this, you soon learn how to write your code in a way which confirms to the rules applied by the tool.
Because of this, I prefer tools like Lint which run relatively quickly, and so encourage continual use, rather than the more cumbersome tools which you may end up using less often, if at all.
You can try CppDepend, a pretty complete static analyzer available on windows and linux, throught VS Plugin, IDE or command line, and it's free for open source contributors
You might find the Uno tool useful. It's one of the few free non-toy options. It differs from lint, Flexelint, etc. in focusing on a small number of "semantic" errors (null pointer derefs, out-of-bounds array indices, and use of uninitialized variables). It also allows user-defined checks, like lock-unlock discipline.
I'm working towards a public release of a successor tool, Orion (CONTENT NOT AVAILABLE ANYMORE)
lint is constantly updated... so why would you want a more recent one.
BTW flexelint is lint
G'day,
I totally agree with the suggestions to read and digest what the compiler is telling you after setting -Wall.
A good static analysis tool for security is FlawFinder written by David Wheeler. It does a good job looking for various security exploits,
However, it doesn't replace having a knowledgable someone read through your code. As David says on his web page, "A fool with a tool is still a fool!"
cheers,
Rob
I've found that it's generally best to use multiple static analysis tools to find bugs. Every tool is designed differently, and they can find very different things from each other.
There are some good discussions in some of the talks here. It's from a conference held by the US Department of Homeland Security on static analysis.
Sparse is a computer software tool, already available on Linux, designed to find possible coding faults in the Linux kernel.
There are two active projects of Linux Verification Center aimed to improve quality of the loadable kernel modules.
Linux Driver Verification (LDV) - a comprehensive toolset for static source code verification of Linux device drivers.
KEDR Framework - an extensible framework for dynamic analysis and verification of kernel modules.
Another ongoing project is Linux File System Verification that aims to develop a dedicated toolset for verification of Linux file system implementations.
There is a "-Weffc++" option for gcc which according to the Mac OS X man page will:
Warn about violations of the following style guidelines from Scott Meyers' Effective C++ book:
[snip]
I know you asked about C, but this is the closest I know of..