I am trying to print data as it is fetched from memory locations by Gem5 simulation. I am editing packet.hh for this purpose. The aim is to be able to edit data in transit.
But even adding cout statements to check the datapointer/data values lead to "internal compiler error".
Should I be using Debug flags instead ? Is this a cout/io-stream thing or does it have something to do with gem5 compilation ?
Circumvented this by using cprintf() statements available in Gem5 code.
Related
I have a piece of Verilog code here
$size(data);
where data is a 16-bit number.
But, it gives an error in Vivado.
error: system call size not allowed in this dialect use system Verilog mode
I have tried searching for a solution, but no luck, hence posting it here.
The error message means that the $size system function can only be used if SystemVerilog features are enabled in Vivado. One way to do so is to give your files a .sv extension.
I'm relatively new in ARM Cortex M4 series micro-controller.
When I'm trying to debug a simple project(blinky which easily just blinks a led on and off) using KEIL 5 simulator, I get an error like this:
* error 65: access violation at 0x400FE608 : no 'read' permission
* error 65: access violation at 0x400FE608 : no 'write' permission
I searched on internet for a solution, and I get this one:
http://www.keil.com/support/docs/814.htm
But actually it is not easy and not logical to mention all the addresses to which I want to access in my whole code like the method mentioned above.
could anybody suggest something else for me please?
(Actually I get this error with all projects which I intended to simulate so I can't simulate anything).
Here is the simple code which I have been using:
#define GCGPIOR (*((int*)0x400FE608))
int main(void)
{
GCGPIOR |= 0x20;
return 0;
}
and I am using this mc: TM4C1294NCPDT
I have a similar problem with KEIL V5, in a CMSIS project with LPC1768 microcontroller.
When debugging with real microcontroller as target, everything works fine. Debugging with simulator as target, when CMSIS tries to initialize the System core clock I get:
*** error 65: access violation at 0x400FC1A0 : no 'write' permission
Is this really sample code from the chip vendor? The definition of GCGPIOR should be volatile.
#define GCGPIOR (*((volatile int*)0x400FE608)))
Have you selected the correct device in the simulator/project configuration? Have you installed the Keil::TM4C_DFP device package and are you using the correct device configuration?
The problem appears to be that the memory map used by the simulator is automatically set up from the linker memory map. If you make direct memory mapped I/O accesses not known to the linker, then it will raise an exception (when this mechanism detects a bug in your code you may be glad of that - it is not a bug in uVision - it is intentional behaviour).
If the MAP command or dialogue did not work for you, Occam's razor suggest to me that you did not perform the operation correctly. You should map the entire I/O region given in your part's data sheet or user manual. It may work I suppose if you define the I/O region in the linker scatter file - but that may be getting a bit too complicated.
If I compile with -O0 in ifort, the program can run correctly. But as long as I open the optimization option, like -O, -O3, -fast, there will be a SIGSEGV segmentation fault come out.
This error occurred in a subroutine named maketable(). And the belows are the phenomenons:
(1) I call fftw library in this subroutine. If I comment the sentences about fftw, it'll be ok. But I think it's not the fault of fftw, because I also use fftw in some other places of this code, and they are good.
(2) the fftw is called in a loop, and the loop can run several times when the program crashed. The segfault does not happen at the first time of entering the loop.
(3) I considered the stack overflow, but I don't think so now. I have the executable file complied by others long time ago, it's can be executed in my computer. I think that suggests it's not due to the system stack overflow.
The version of ifort is 10.0, of fftw is fftw-2.1.5. The cpu type is intel xeon 5130. Thanks a lot.
There are two common causes of segmentation faults in Fortran programs:
Attempting to access an element outside the bounds of an array.
Mismatching actual and dummy arguments in a procedure call.
Both are relatively easy to find:
Your compiler will have an option to generate code which performs array bounds checking at run time. Check your compiler documentation, rebuild your code and rerun it. If this is the cause of the problem you will get an error message identifying where your code goes awry.
Program explicit interfaces for any subroutines and functions in your program, or use modules so that the compiler generates such interfaces for you, or use a compiler option (see the documentation) to check that argument types match at compile-time.
It's not unusual that such errors (seem to) arise only when optimisation is turned up high.
EDIT
Note that I'm not suggesting that optimisation causes the error you observe, but that it causes the error to affect the execution of your program and become evident.
It's not unknown for incorrect programs to run many times apparently without fault only for, say, recompilation with a new compiler version to create an executable which crashes every time.
Your wish to switch off optimisation only for the subroutine where the segmentation fault seems to arise is, I suggest, completely wrong-headed. I expect my programs to execute correctly at any level of optimisation (save for clear evidence of a compiler bug, such things are not unknown). I think that by turning off optimisation you are sweeping a real problem with your program under the carpet, as it were.
Here are my two lines of code:
NSString *frontFilePath = [[NSBundle mainBundle] pathForResource:[self.bookendFileNames objectAtIndex:self.randomIndex] ofType:#"caf"];
NSLog(#"frontFilePath = %#", frontFilePath );
I put a break point on the second line and when there, I try to print it:
(lldb) po frontFilePath
But I get the following error:
error: variable not available
I'm confused because if I step over the NSLog statement, the variable does indeed print to the console.
For what it's worth, I'm trying to debug the first line since sometimes it returns NULL, tho I can't, as of now, figure out why.
This is an artifact of debugging optimized code. When the compiler's optimization is enabled in your build settings, it moves variables between memory and registers as it decides is best. At the point where you're examining the variable in lldb, it may not exist in registers or memory at all -- even though it looks like it should still be available for display.
It's possible it is a shortcoming of the debug information output by the compiler. Sometimes the compiler will copy a variable into a register for its use and only list that register location in the debug information. Later the register is repurposed for other uses; value is still present on the stack but the compiler hasn't told the debugger that the value can be found there.
The only way to really tell whether it's insufficient debug info or if the value genuinely doesn't exist at that particular instruction is to examine the assembly code by hand. As soon as you turn on optimization with the compiler, the source code becomes a weak view into what's actually being executed in any particular order.
Instead of wandering too far into the wacky world of optimized code debugging, I strongly recommend turning off optimization (Optimization Level in your Build Settings) for your build and debugging it that way, if at all possible. If you do need to debug your app with optimization, make sure you're building with the latest Apple LLVM compiler supported by your Xcode -- there is always work being done to improve optimized code debugging and you want to avail yourself of the most up to date tools you can.
The "Address Sanitizer" in the diagnostics seems to make the values of variables unavailable, too.
Schemes > Run > Diagnostics > Address Sanitizer
In Swift, possibly starting with Xcode 9 and still an issue in Xcode 10, this could even come up when code optimization is turned off in the build settings. As #carlos_ms has pointed out here, a temporary solution is to define the variable as mutable, i.e.
Turn
let foo = Bar().string
into
var foo = Bar().string
in order to cause optimization to skip on this variable. Note that this might not work in all instances.
In this case, a good ol' debugPrint() might help you out.
I have successfully compiled a SystemC application that I use in order to simulate a CPU when running on a general architecture.
Well my problem is just that, when running the application in order to create the VCD file, the SystemC kernel plots me some warnings.
I get some warning, something like this:
Warning: (W206) vector contains
4-value logic In file:
....\cacheseqproc_vcpp20\systemc-2.2.0\src\sysc\datatypes\bit\sc_proxy.h:1385
In process: process.processname # x ns
Well... the message itself is not important... I put it here just to let you understand better tht this is a warning message thrown at RUNNING time.
Given that I print several important messages during the execution, I would really like not to have these verbose messages by SystemC. How to let this happen?
To disable all warnings:
sc_report_handler::set_actions (SC_WARNING, SC_DO_NOTHING);
To disable the "vector contains 4-value logic" warning, but leave other warnings enabled:
sc_report_handler::set_actions (SC_ID_VECTOR_CONTAINS_LOGIC_VALUE_,
SC_DO_NOTHING);