newlib sscanf() throw hardfault exception in stm32 - scanf

i use gcc compile my project, use the function sscanf() in main, the stack size is 4k, i debug the program in gdb, show VPUSH instruction throw the exception.
and i test the function sprintf(), it work nice. why the function sscanf() is not work in newlib for stm32?

Apart from STM32 F4 series, those controllers do not support floating point instructions, vpush being one of them.
The problem should be solved by compiling newlib with -mfloat-abi=soft (and not softfp or hard).

Related

What happens to a program that contains certain instructions that are not supported by the cpu in question?

Say for example in the case of x86-64 you have a program that makes use of avx-512 instructions or any other special purpose instruction, and the cpu in question does not support the instruction at the low level such as a haswell based cpu, how does this situation get resolved?
Is the program simply just not able to run (my first thought) or is there a way for the cpu to still run the program using the instructions it does support, however it will simply not receive the performance advantage offered by the instruction in question?
If the program checks CPU features and avoids actually run unsupported instructions, you just miss out on performance. Libraries like x264 and x265 do this, setting function pointers when they start to versions of functions that are the best supported version for this CPU.
If you do run an unsupported instruction (e.g. because you compiled with gcc -O3 -march=skylake-avx512 to tell the compiler it could assume AVX-512 support) there are 2 possibilities:
It happens to decode as something else (which won't be the case for AVX-512, but does happen for example with lzcnt decoding as bsr).
The CPU raises a #UD exception (UnDefined instruction). The OS handles it and delivers a SIGILL (Illegal Instruction) to the process, or equivalent on non-POSIX OSes like Windows.

How to load symbol files to BCC profiler

With bcc tools' profile, I am getting mostly "[unknown]" in the profile output on my C program. This is, of course, expected because the program symbol are not loaded. However, I am not sure how to properly load the symbols so that "profile" program can pick it up. I have built my program with debug enabled "-g", but how do I load the debug symbols to "profile"?
Please see the DEBUGGING section in bcc profile's manpage:
See "[unknown]" frames with bogus addresses? This can happen for different
reasons. Your best approach is to get Linux perf to work first, and then to
try this tool. Eg, "perf record -F 49 -a -g -- sleep 1; perf script", and
to check for unknown frames there.
The most common reason for "[unknown]" frames is that the target software has
not been compiled
with frame pointers, and so we can't use that simple method for walking the
stack. The fix in that case is to use software that does have frame pointers,
eg, gcc -fno-omit-frame-pointer, or Java's -XX:+PreserveFramePointer.
Another reason for "[unknown]" frames is JIT compilers, which don't use a
traditional symbol table. The fix in that case is to populate a
/tmp/perf-PID.map file with the symbols, which this tool should read. How you
do this depends on the runtime (Java, Node.js).
If you seem to have unrelated samples in the output, check for other
sampling or tracing tools that may be running. The current version of this
tool can include their events if profiling happened concurrently. Those
samples may be filtered in a future version.
In your case, since it's a C program, I would recommend compiling with -fno-omit-frame-pointer.

Instrumenting ROI in gem5 SE mode

My goal is to instrument the region-of-interest of a program in syscall emulation mode. I have already implemented pseudo instructions for full system mode based on this tutorial. It is time consuming though to test everything in FS after I make even a small change. Is there any way to implement the same functionality for syscall mode?
So I found what the problem was. You need to remove all mentions of mmap. So in my case it would be removing the include of m5_mmap.h in the microbenchmark and not calling map_m5_mem() first thing in main(). Just call m5_roi_begin() and m5_roi_end() (or however you call your instrumentation functions).
Also in the gem5 x86 makefile (gem5/util/m5/Makefile.x86) remove the
-DM5OP_ADDR=0xFFFF0000
flag and compile again (make -f Makefile.x86). Now when I run the microbenchmark with gem5, I can see when the ROI starts and ends. Everyting else remains the same, as I've posted in a comment above to the question.
Thanks Ciro.

way to handle to write CUDA+MEX code in linux?

I try to write matlab mex code with Cuda integrated but it is just hard enough to compile and debug all around. Is there any better approach to code and test? I am on Matlab 2012b.
Currently I am writing code in sublime then compile it on matlab but I am also newbie at CUDA as well thus it is just hard to code it without seeing the result instantly.
The comment by Robert Crovella is interesting.
I just wanted to mention the way I was used to compile mex file with CUDA instructions (and which works also on different versions of MATLAB).
1) Compile by nvcc and transform the source code in C++ code by the command
system(sprintf('nvcc -I"%s/extern/include" -cuda "mex-fun.cu" -output-file "mexfun.cpp"', matlabroot));
2) Link it to Matlab by
mex -I/opt/cuda/include -L/opt/cuda/lib -lcudart mex-fun.cpp
This was originally suggested at the MATLAB Newsreader page.
I have both a matlab entry point (i.e. a file with the function "mexFunction") and a C++ entry point (a file with "main"), and the rest of my actual CUDA code is independant of what entry point was used.
This way, I can debug the code used for my MEX files using the standard set of CUDA tools (i.e. nvprof, cuda-memcheck, etc) without having to deal with the MEX file. Then once I'm sure I have no bugs or memory leaks, I just compile it to a MEX file. Alternately you can always just attach cuda-gdb to your MEX file, although your mileage may vary with this.

How does Perl react during compile time and run time?

What my understanding over this would be:
During compile time, an error is one that keeps Perl from being able to parse the file; such as a missing semi-colon.
And a run time error is an error that can not be detected until the code is run; such as a divide by zero error or a call to an undefined subroutine.
As Perl is an interpreted language, will the entire code or script be complied once and then run or will it compile for each and every line and then go for run?
What is the explanation?
The program will be compiled once into an optree. The optree is traversed and executed.
At runtime, it can happen that additional compile phases become necessary. The usual culprits are string eval and delayed/dynamic loading of code units, e.g. require, do.
Perl is an interpreted language, which means that both the compile phase and the run phase happen in sequence every time you attempt to start a script.
Compiled languages on the other hand (C, Pascal, etc) separate out those two phases, and typically have an intermediate phase called linking, which joins together object files and libraries into the final executable file.
In compiled languages, detecting an undefined function can happen in either the compile phase, or the linking phase, depending on how strict the language specification is. In original C calling an undefined function would be found by the linker, but in C++ it would be found by the compiler.
To further complicated matters, some languages such as Java have separate compile and execution phases, but the compilation is actually to an intermediate "byte code", which is then interpreted by a run time system (i.e. the Java Virtual Machine).
Strictly speaking, Perl also uses an intermediate byte code, but the separation of the phases is mostly invisible.