I'm doing formal verification with SymbiYosys, Yosys and GHDL. I was wondering if it is possible to generate the trace file with the previous cycle to the one which is UNSAT. I haven't found any info in the Yosys and SymbiYosys docs.
Related
I'm using IntelliJ IDEA 2021.1 to debug the processing difference between two very similar executions of a Legacy Java6EE app. I want to capture the full call and/or stack trace of an application, maybe a thread dump as well since it may be offloading some work to another thread. I'm trying to test only one difference in parameters to determine why it fails with one more explicit parameter set. I'm primarily concerned with the difference in logic followed and maybe see if the query executions are different.
However, I can't find a resource for this process. I'm only able to find the importation of external traces and thread dumps for comparison in the Analysis tab from the JetBrains forum and guides, but nothing showing how to get the initial trace aside from hitting a breakpoint and exporting that small chunk.
I'm doing some firmware analysis for an embedded system and I've got a trace of the program counter (for every cycle, I know what the program counter is set to). I've additionally got the elf, map file, and the source code.
I'm wondering if there are any open source tools that would allow me to convert this program counter trace into something like a stack trace. From the map file I can determine which function is executing at any given time, but this doesn't allow me to determine if/where function calls/returns occur.
I'm using a cortex m4 with freertos and i receive the following error
Err: -110595: Hardfault occurred!
I have no idea what to check.
The meaning is CRIT_ERR_HARD_FAULT but how do i trace it back?
It's always tricky and there is no common checklist what should be checked to give you 100% chance for quick success here.
Anyway checking several registers' values should give you enough information to proceed. To do it, you have to know what's the procedure of entering an exception - especially what's happening with core registers and the stack: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html
If you can use online debugging, put a breakpoint in hard fault handler and check the following:
stacked PC - as written in the article above, on exception entry ARM core automatically pushes registers r0,r1,r2,r3,sp,lr,pc and psr on stack. Look it up to check where the program was before execution
current LR - to verify if you came from Thread mode (normal program execution) or another interrupt compare current LR with the table in the article
ISR_NUMBER in IPSR being part of current PSR - to verify whether in fact hard fault exception occurred or your hard fault handler is used as a sink for all types of faults
CFSR and other fault related registers in SCB - it should give you more information what's exactly caused the problem. Since SCB is a peripheral block, it's not visible in most IDEs by default. Install peripheral plugin or simply access addresses via memory inspection window http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Cihcfefj.html
If you're unable to do online debugging, you'll need a feature which will dump these registers somehow.
Good luck!
Are your HardFault handlers strongly defined? If you have the ability to connect a debugger and the fault is reproducible you can set a breakpoint in your fault handler and check the stack trace for possible areas of interest.
Alternatively, this guide provides a highly portable and useful method of diagnosing hard faults and gathering information post fault for the ARM processor.
If there is a problem in the source code, usually a programmer goes through the log manually and tries to identify the problem in the source code.
But is it possible to automate this process? Can we automate the process that would give the potential lines in the source code that was responsible for generating the fault.
So, for example:
If there is some problem in the log file. Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
Thanks!!
It depends on the language you are using.
In Java (and probably other JVM languages) this feature is built-in: Every exception that is thrown has a reference to the stack trace, including class, method and line number of every method involved. All you need to do is something like
exception.printStackTrace();
In C and C++, you can use preprocessor macros like __FUNCTION__ or __LINE__ when throwing an exception or writing a log message, for example:
throw "Error in " + __FUNCTION__ + ", line " + std::to_string(__LINE__);
The macros will be replaced by the current function and the current line.
If you are looking for a method that works with any language and any type of logging, there is no good solution. You could run a tool like grep over all source files, that will try to find matches. However this will only work if the log messages appear as string literals in source code at the position where the message is written. This is unlikely because the messages are likely to contain variable values or constants defined somewhere else.
Assuming we are not talking about (unit) testing, because this is what they do - show you where is the problem exactly.
Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
In my team we had similar discussion and what we've come with is a Top5 most likely issues document (PlayBook). After reading logs every time on failure, we've noticed that in most of the times there is a requiring pattern. So 8 out of 10 cases the issues were following one of those patterns. So it is possible to trace the latest changes (with the help from Git). If your changes are small and frequent - this approach works quite well.
I am curious to find how does the pstack command prints the stack trace of all the threads running under the PID?
It has to be someway different than the way gdb does since the process runs inside the gdb environment, but pstack is executed after the execution of the process.
It's the same general idea as gdb. pstack uses ptrace, which allows an external process to attach to a known pid and print out the information (stack is known via the current registers).
If you want to know exactly how it's done, look for information about ptrace.
Also, processes don't really run "inside the gdb". You can attach gdb to a running process without much trouble by running gdb executable pid.
pstack print similar output as cat /proc/"pid"/tasks/*/stack so it most likely that it read the procfs rather than using the ptrace.