I am trying to write an assembly function for an arm-v7-m cortex-m4 processor. I am using the eclipse IDE with the gnu arm compiler (arm-none-eabi). To compile the .S file, in my 'project properties', I have set the target processor arm family to cortex m4, appended '--specs=rdimon.specs' to the gnu arm linker and '-g -gstabs' to the gnu arm assembler. The code compiles successfully and generates an executable. Please note that I have used an empty C/C++ project rather than the STM32F4-Discovery template:
.syntax unified
.thumb
.text
.global main
.balign 4
.thumb_func
.type main, %function
main: MOV r0, #28 #1st argument;
MOV r1, #21 # 2nd argument;
ADD r2, r1, r0
stop: BAL stop
.end
To check the registers, I put a breakpoint on the ADD line.
I use gdb-qemu-armeclipse debugging in my debug configuration, with the xpacks/.bin path selected. I have selected the STM32F4-Discovery board with STM32F407VG as the device name. The qemu program starts successfully, but I cannot use the debugger: the stepping options and stuff are all grayed out. I would gladly appreciate any suggestions to rectify this issue. Thanks in advance
UPDATE: When I have the "Debug in RAM" RunTime Option selected in the startup options, I get to see the code running correctly and the registers updated. Things start going south once I hit the infinite 'stop' loop
Related
I am running:
Eclipse 3.8.1 (Build id: deb build).
On Ubuntu 16.04 LTS in a VM and UbuntuMATE 16.04 LTS on target Raspberry Pi 3.
gdb-multiarch(architecture set to arm in .gdbinit) locally andgdbserver` on the target.
Cross compilation and remote deployment is successful. However, there appears to be some library issue when I run on the remote target. Output from gdb-multiarch below (superfluous text removed):
GNU gdb (Ubuntu 7.11-0ubuntu1) 7.11 Copyright (C) 2016 Free Software
Foundation, Inc. License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html This GDB was configured as
"x86_64-linux-gnu".
Program stopped. 0x76fd7a40 in ?? () from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Execution stops at main. However, it doesn't appear to stop due to a breakpoint. The stop appears to be the result of some library issue possibly and unresolved symbol (or something more serious) resulting in the ??.
I have set sysroot in the .gdbinit file to indicate where the shared libraries can be found. The StepIn, StepOut icons are hi-lighted in Eclipse, and I can read ARM registers if I press pause and see which core is being used to run the process (with process ID)!
After further resume & pause operations a segmentation fault occurs:
Program stopped. 0x76fe2e92 in ?? () from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Program received signal SIGSEGV, Segmentation fault. 0x76fd905e in ??
() from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Program terminated with signal SIGSEGV, Segmentation fault. The
program no longer exists.
Any ideas? (I am very much new to Linux as it probably shows.)
Thanks for the questions which have resulted in further exploration below:
In Eclipse I started GDB by selecting Debug Configuration and then choosing the remote configuration that I had set up.
The code is very simple, consisting of a stream operator to output some text and then a loop, however it is never reached. I think I have just managed to reproduce the issue from the command line. Incidentally I started the target going first. (Again superfluous text was removed for clarity.)
gdb-multiarch Hello_Raspberry_Pi
Reading symbols from Hello_Raspberry_Pi...done.
The target architecture is assumed to be arm
(gdb) target remote ubuntumate-pi
(gdb) target remote 192.168.0.12:2345
Remote debugging using 192.168.0.12:2345
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
0x76fd7a40 in ?? ()
(gdb) set architecture arm
The target architecture is assumed to be arm
(gdb) set sysroot /home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
(gdb)
The target side behaved as would be expected:
fred#UbuntuMATE-Pi:~/Hello_Raspberry_Pi$ gdbserver 192.168.0.7:2345 Hello_Raspberry_Pi
Process Hello_Raspberry_Pi created; pid = 17363
Listening on port 2345
Remote debugging from host 192.168.0.7
So perhaps Unable to find dynamic linker breakpoint function. is a big clue?
It would appear that I had defined Shared Libraries incorrectly. When I deleted this setting something closer to expected behaviour occurred. As shown below, however I there is still a warning that I would like to remove:
For help, type "help".
Type "apropos word" to search for commands related to "word".
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
0x76fd7a40 in ?? ()
Breakpoint 2, main () at ../src/Hello_Raspberry_Pi.cpp:18
18 cout << "I'm in the While loop and the value of variable i is: " << i << endl;
Breakpoint 1, main () at ../src/Hello_Raspberry_Pi.cpp:20
20 usleep(1000000); //wait for 1 seconds
So now Eclipse does breakpoint at main and permit stepping - finally!
I also faced problems similar to this, getting segmentation fault from ld.so. Did the following steps to fix it.
Install libc6-dbg package in both sysroot and target.
create a folder /lib/.debug in both sysroot and target.
copy /usr/lib/debug/lib/arm-linux-gnueabihf/ld-2.23.so to /lib/.debug in both sysroot and target.
I want to build libunwind from Android source at eclipse using ndk r10d.
But I fail at compiling "Gresume.c" , and it fail at the asm code .
I can't understand asm code and I searched any place can't found people who has the same problem ,so I hope somebody can help me .
the error line of code is:
asm __volatile__ (
"ldmia %0, {r4-r12, lr}\n"
"mov sp, r12\n"
"bx lr\n"
: : "r" (regs) ,
"m" (*(struct regs_overlay *)regs)
);
the error output:
[armeabi] Compile thumb : MyBacktrace <= Gresume.c
/var/folders/g7/9gd3cwy96z12qt3vlf7sc5q80000gn/T//cc6jsBSj.s: Assembler messages:
/var/folders/g7/9gd3cwy96z12qt3vlf7sc5q80000gn/T//cc6jsBSj.s:88: Error: lo register required -- `ldmia r2,{r4-r12,lr}'
make: *** [obj/local/armeabi/objs/MyBacktrace/libunwind/src/arm/Gresume.o] Error 1
the full code can found at the link bellow.
It seems you're building Thumb code, so I'd guess you're seeing this because you're targeting the wrong architecture version. Traditionally most Thumb instructions can only use the "low registers" r0-r7 - a Thumb version of ldmia capable of moving "high registers" (i.e. r8-r12, r14 here) didn't exist until ARMv7*. As far as I'm aware Android's lowest-common-denominator is still ARMv5, so if you are targeting that by default then the assembler is going to refuse things which are impossible in that instruction set version.
Changing your build settings to either target ARMv7, or just to build as ARM code instead of Thumb, should pass the relevant options through to the assembler such that it can find an appropriate encoding for that instruction.
* Technically ARMv6T2, but I'm pretty sure ARM1156 isn't relevant in an Android context.
Short solution from here, put your code in a distinct .s file with this at the beginning :
.thumb
.syntax unified
But I still don't get why it works...
I'm trying to use CUDA code inside MATLAB mex, under linux. With the "whole program compilation" mode, it works good for me. I take the following two steps inside Nsight:
(1) Add "-fPIC" as a compiler option to each .cpp or .cu file, then compile them separately, each producing a .o file.
(2) Set the linker command to be "mex" and add "-cxx" to indicate that the type of all the .o input files are cpp files, and add the library path for cuda. Also add a cpp file that contains the mexFunction entry as an additional input.
This works good and the resulted mex file runs well under MATLAB. After that when I need to use dynamical parallelism, I have to switch to the "separate compilation mode" in Nsight. I tried the same thing above but the linker produces a lot of errors of missing reference, which I wasn't able to resolve.
Then I checked the compilation and linking steps of the "separate compilation" mode. I got confused by what it is doing. It seems that Nsight does two compilation steps for each .cpp or .cu file and produces a .o file as well as a .d file. Like this:
/usr/local/cuda-5.5/bin/nvcc -O3 -gencode arch=compute_35,code=sm_35 -odir "src" -M -o "src/tn_matrix.d" "../src/tn_matrix.cu"
/usr/local/cuda-5.5/bin/nvcc --device-c -O3 -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35 -x cu -o "src/tn_matrix.o" "../src/tn_matrix.cu"
The linking command is like this:
/usr/local/cuda-5.5/bin/nvcc --cudart static --relocatable-device-code=true -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35 -link -o "test7" ./src/cu_base.o ./src/exp_bp_wsj_dev_mex.o ./src/tn_main.o ./src/tn_matlab_helper.o ./src/tn_matrix.o ./src/tn_matrix_lib_dev.o ./src/tn_matrix_lib_host.o ./src/tn_model_wsj_dev.o ./src/tn_model_wsj_host.o ./src/tn_utility.o -lcudadevrt -lmx -lcusparse -lcurand -lcublas
What's interesting is that the linker does not take the .d file as input. So I'm not sure how it dealt with these files and how I should process them with the "mex" command when linking?
Another problem is that the linking stage has a lot of options I don't understand (--cudart static --relocatable-device-code=true), which I guess is the reason why I cannot make it work like in the "whole program compilation" mode. So I tried the following:
(1) Compile in the same way as in the beginning of the post.
(2) Preserve the linking command as provided by Nsight but change to use "-shared" option, so that the linker produces a lib file.
(3) Invoke mex with input the lib file and another cpp file containing the mexFunction entry.
This way mex compilation works and it produces a mex executable as output. However, running the resulted mex executable under MATLAB produces a segmentation fault immediately and crashes MATLAB.
I'm not sure if this way of linking would cause any problem. More strangely, I found that the mex linking step seems to finish trivially without even checking the completeness of the executable, because even if I miss a .cpp file for some function that the mexFunction will use, it still compiles.
EDIT:
I figured out how to manually link into a mex executable which can run correctly under MATLAB, but I haven't figured out how to do that automatically under Nsight, which I can in the "whole program compilation" mode. Here is my approach:
(1) Exclude from build the cpp file which contains the mexFunction entry. Manually compile it with the command "mex -c".
(2) Add "-fPIC" as a compiler option to each of the rest .cpp or .cu file, then compile them separately, each producing a .o file.
(3) Linking will fail because it cannot find the main function. We don't have it since we use mexFunction and it is excluded. This doesn't matter and I just leave it there.
(4) Follow the method in the post below to manually dlink the .o files into a device object file
cuda shared library linking: undefined reference to cudaRegisterLinkedBinary
For example, if step (2) produces a.o and b.o, here we do
nvcc -gencode arch=compute_35,code=sm_35 -Xcompiler '-fPIC' -dlink a.o b.o -o mex_dev.o -lcudadevrt
Note that here the output file mex_dev.o should not exist, otherwise the above command will fail.
(5) Use mex command to link all the .o files produced in step (2) and step (4), with all necessary libraries supplied.
This works and produces runnable mex executable. The reason I cannot automate step (1) inside Nsight is because if I change the compilation command to "mex", Nsight will also use this command to generate a dependency file (the .d file mentioned in the question text). And the reason I cannot automate step (4) and step (5) in Nsight is because it involves two commands, which I don't know how to put them in. Please let me know if you knows how to do these. Thanks!
OK, I figured out the solution. Here are the complete steps for compiling mex programs with "separate compilation mode" in Nsight:
Create a cuda project.
In the project level, change build option for the following:
Switch on -fPIC in the compiler option of "NVCC compiler" at the project level.
Add -dlink -Xcompiler '-fPIC' to "Expert Settings" "Command Line Pattern" of the linker "NVCC Linker"
Add letter o to "Build Artifact" -> "Artifact Extension", since by -dlink in the last step we are making the output a .o file.
Add mex -cxx -o path_to_mex_bin/mex_bin_filename ./*.o ./src/*.o -lcudadevrt to "Post Build Steps", (add other necessary libs)
UPDATE: In my actual project I moved the last step to a .m file in MATLAB, because otherwise if I do it while my mex program is running, it could cause MATLAB crash.
For files needs to be compiled with mex, change these build option for each of them:
Change the compiler to GCC C++ Compiler in Tool Chain Editor.
Go back to compiler setting of GCC C++ Compiler and change Command to mex
Change command line pattern to ${COMMAND} -c -outdir "src" ${INPUTS}
Several additional notes:
(1) Cuda specific details (such as kernel functions and calls to kernel functions) must be hidden from the mex compiler. So they should be put in the .cu files rather than the header files. Here is a trick to put templates involving cuda details into .cu files.
In the header file (e.g., f.h), you put only the declaration of the function like this:
template<typename ValueType>
void func(ValueType x);
Add a new file named f.inc, which holds the definition
template<>
void func(ValueType x) {
// possible kernel launches which should be hidden from mex
}
In the source code file (e.g., f.cu), you put this
#define ValueType float
#include "f.inc"
#undef ValueType
#define ValueType double
#include "f.inc"
#undef ValueType
// Add other types you want.
This trick can be easily generalized for templated classes to hide details.
(2) mex specific details should also be hidden from cuda source files, since the mex.h will alter the definitions of some system functions, such as printf. So including of "mex.h" should not appear in header files that can potentially be included in the cuda source files.
(3) In the mex source code file containing the entry mexFunction, one can use the compiler macro MATLAB_MEX_FILE to selectively compile code sections. This way th source code file can be compiled into both mex executable or ordinarily executable, allowing debugging under Nsight without matlab. Here is a trick for building multiple targets under Nsight: Building multiple binaries within one Eclipse project
First of all, it should be possible to set up Night to use a custom Makefile rather than generate it automatically. See Setting Nsight to run with existing Makefile project.
Once we have a custom Makefile, it may be possible to automate (1), (4), and (5). The advantage of a custom Makefile is that you know exactly what compilation commands will take place.
A bare-bones example:
all: mx.mexa64
mx.mexa64: mx.o
mex -o mx.mexa64 mx.o -L/usr/local/cuda/lib64 -lcudart -lcudadevrt
mx.o: mxfunc.o helper.o
nvcc -arch=sm_35 -Xcompiler -fPIC -o mx.o -dlink helper.o mxfunc.o -lcudadevrt
mxfunc.o: mxfunc.c
mex -c -o mxfunc.o mxfunc.c
helper.o: helper.c
nvcc -arch=sm_35 -Xcompiler -fPIC -c -o helper.o helper.c
clean:
rm -fv mx.mexa64 *.o
... where mxfunc.c contains the mxFunction but helper.c does not.
EDIT: You may be able achieve the same effect in the automatic compilation system. Right click on each source file and select Properties, and you'll get a window where you can add some compilation options for that individual file. For linking options, open Properties of the project. Do some experiments and pay attention to the actual compilation commands that show up in the console. In my experience, custom options sometimes interact with the automatic system in a weird way. If this method proves too troublesome for you, I suggest that you make a custom Makefile; this way, at least we are not caught by unexpected side-effects.
We have a project in KEIL IDE for LPC2148 which has RTX kernel programs along with other programs in it, which was compiled by ARM CC.Now we need to change the IDE from KEIL(ARM CC) to Eclipse(GCC). When we tried to compile it in Eclipse GCC Compiler, it is showing errors in RTX_Config.c and RTX_Config.h files. Other files are compiled successfully using GCC compiler. But RTXConfig.c file has compiler specific codes which are not getting compiled by GCC. Is there any solution to compile this project in Eclipse IDE using GCC compiler? Please help me out in this as am a beginner. Thanks in advance
We have some keil specific keywords like irq , __swi, __task , __asm which is compiled successfully by ARM CC (keil), but when we tried to port it to GCC Compiler (Eclipse), This compiler cannot compile these keywords and showing errors.
Is there any way to compile these keil specific keywords in GCC Compiler?
do_software_interrupt, do_irq and do_fiq are interrupt service routines for SWI, IRQ and FIQ respectively. These functions are implemented in c using gcc’s attribute feature. Here is the actual c code containing routines for irq, fiq and software interrupt.
entry.c
void __attribute__((interrupt("IRQ"))) do_irq()
{
//your irq service code goes here
}
void __attribute__((interrupt("FIQ"))) do_fiq()
{
//your fiq service code goes here
}
void __attribute__((interrupt("SWI"))) do_software_interrupt()
{
volatile unsigned int int_num;
asm("LDR r0, [lr, #-4]");
asm("BIC r0, #0xFF000000");
asm("MOV %0, r0":"=r"(int_num):);
//based on int_num, you can determine which system call is called
}
void c_start() {
asm volatile ("SVC 0x5");
while(1){}
}
I have written some gcc ARM inline assembly in iphone sdk 3.1.2
however the breakpoints don't get hit (infact anywhere in the c file that contains it). How can i debug it?
Thanks
In xcode 4.2:
Set a breakpoint on the inline _asm statement
Set Product->Debug Workflow->Show Assembly When Debugging = yes
Run
When stops at breakpoint open the 'Debugger Output' window (bottom right) - (default is 'Target output')
type si at the gdb prompt then press enter (for single step)
etcetera