I am trying to debug a OpenCL kernel for a Arria 10 FPGA board.
First I am compiling for emulation with:
$ aoc -march=emulator device/kernel.cl -v -o bin/kernel.aocx
And then I can execute the host with the recommended command and works fine:
$ env CL_CONTEXT_EMULATOR_DEVICE_ALTERA=1 ./host
But when I want to debug I do:
$ gdb host
$ (gdb) run
which gives me the error:
Context callback: Program was compiled for a different board.
aocx is for board EmulatorDevice whereas device is alaric_v3_prod_hpc
I suppose this error is because I am not including the information in "env CL_CONTEXT_EMULATOR_DEVICE_ALTERA=1". How should I execute the host program for debugging? Thanks
Prepend gdb call with env flag, same like you did without debugging:
env CL_CONTEXT_EMULATOR_DEVICE_ALTERA=1 gdb ./host
Related
I'm developing on an ubuntu x86 machine, trying to run the u-boot hello_world standalone application which resides on an image sd.img which contains a partition.
I've compiled u-boot (v2022.10) with qemu-x86_64_defconfig
I run qemu with qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom -drive format=raw,file=sd.img
u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits a command. If I type ext4ls ide 0:1, I can clearly see hello_world.bin (3932704 hello_world.bin).
When I do a ext4load ide 0:1 0x40000 hello_world.bin (in preparation for go 40000 This is another test), qemu/u-boot restarts.
0x40000 is the CONFIG_STANDALONE_LOAD_ADDR for x86.
I have even tried making an image of hello_world mkimage -n "Hello stand alone" -A x86_64 -O u-boot -T standalone -C none -a 0x40000 -d hello_world.bin -v hello_world.img and tried to load the image into 0x40000 with the intention of using bootm in case of cache issues - qemu/u-boot still resets.
Could anyone possibly point out the basic mistake I'm making.
Cheers
The memory area 0xa0000-0xffffff is reserved and you are overwriting it when loading your 4 MiB file to 040000 due to the excessive size of the file.
If you build hello_world.bin correctly, it will be a few kilobytes.
I'm having trouble using the CLion integration environment under linux.
When I execute a script using the system terminal, it is possible to run.
compile_test.sh:
#!/bin/bash
if [ ${USER} == "mzflrx" ]
then
LLVM_PATH="/home/mzflrx/Downloads/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04"
else
LLVM_PATH="/home/devin812/文档/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04"
fi
# 生成待保护的字节码
${LLVM_PATH}/bin/clang -o3 -emit-llvm test.c -c -o test.bc
# 生成可执行文件（保护前）
${LLVM_PATH}/bin/clang test.bc -o test -lpthread
But when I execute with CLion's built-in terminal, I get the following error:
[mzflrx#mzflrx test]$ ls
compile_out_cpp.sh compile_test.sh out1 out.bc test test-37.cpp test.c test.i64
compile_out.sh data.txt out1.bc out.i64 test-377.cpp test-37.ll testcase test.ll
compile_test_cpp.sh generate_cpp.sh out1.ll result.txt test-37.bc test.bc test.cpp test_time.py
[mzflrx#mzflrx test]$ ./compile_test.sh
/home/mzflrx/Downloads/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04/bin/clang: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
/home/mzflrx/Downloads/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04/bin/clang: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
/home/mzflrx/Downloads/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04/bin/llvm-dis: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
I don't know why I can't find the library.
In the CLion built-in terminal, I go into the /usr/lib directory to execute the ls command.
[mzflrx#mzflrx test]$ cd /usr/lib
[mzflrx#mzflrx lib]$ ls
aarch64-linux-gnu extensions ld-linux-aarch64.so.1 locale perl5 systemd udev
arm-linux-gnueabihf gcc ld-linux-armhf.so.3 os-release python3.8 tcl8.6 x86_64-linux-gnu
debug i386-linux-gnu ld-linux.so.2 perf sdk terminfo
In the linux terminal, I go into the /usr/lib directory to execute the ls command.
$: cd /usr/lib
$: ls | head -n20
accounts-daemon
alsa-lib
ao
apparmor
appimagelauncher
appstreamcli-compose
asb-plugins-5
at-spi2-registryd
at-spi-bus-launcher
audit
avahi
awk
baloo_file
baloo_file_extractor
baloorunner
bash
bellagio
bfd-plugins
binfmt.d
bluetooth
Twice the same command gets completely different results on different consoles.
I don't know why, is it because the CLion built-in console is using a virtual environment?
But it's no use removing active-virtualenv option from the file->setting->Tool->Terminal
I know why there is such a reason. Because I use flatpak to install, it has its own virtual environment. It's fine after I use the source code to install
I need to write a program on bare-metal PowerPC system. As a newbie to bare-metal programming without OS/bootloarder, I decide to write a hello world program to start. I googled some post about this, and found out something about ARM like Beagleboard bare metal programming or Hello world, bare metal Beagleboard.
I don't very clear if they are suitable for porting to PowerPC platform. I cannot find PowerPC's hello world example for beginner. Anyone have experience of bare-metal development for PowerPC, without bootloader or OS?
Thanks.
Random notes/links I collected for trying to get a bare metal PPC system to boot in Qemu There are plenty of examples all around for doing embedded, bare-metal programming on ARM platforms, but the PowerPC examples seem to be sparse.
Some ARM links:
http://opensourceforu.com/2011/07/qemu-for-embedded-systems-development-part-2/
https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/
Building GNU GCC cross compiler
1) Packages Needed
binutils https://ftp.gnu.org/gnu/binutils/
GCC https://ftp.gnu.org/gnu/gcc/gcc-4.1.1/
newlib ftp://sourceware.org/pub/newlib/index.html
GDB http://www.gnu.org/software/gdb/gdb.html
2) Set environment variables
$ export TARGET=powerpc-eabi
$ export PREFIX=/usr/local/$TARGET
$ export PATH=$PATH:$PREFIX/bin
3) Build binutils
$ tar xjfv binutils-2.17.tar.bz2
$ mkdir build-binutils
$ cd build-binutils
$ ../binutils-2.17/configure --target=$TARGET --prefix=$PREFIX
$ make all
$ make install
4) Build bootstrap GCC
$ tar xjfv gcc-4.1.1.tar.bz2
$ mkdir build-gcc
$ cd build-gcc
$ ../gcc-4.1.1/configure --target=$TARGET --prefix=$PREFIX --without-headers --with-newlib --with-gnu-as --with-gnu-ld
$ make all-gcc
$ make install-gcc
5) Build newlib
$ tar xzfv newlib-1.14.0.tar.gz
$ mkdir build-newlib
$ cd build-newlib
$ ../newlib-1.14.0/configure --target=$TARGET --prefix=$PREFIX
$ make all
$ make install
6) Build GCC again with newlib
$ cd build-gcc
$ ../gcc-4.1.1/configure --target=$TARGET --prefix=$PREFIX --with-newlib --with-gnu-as --with-gnu-ld --disable-shared --disable-libssp
$ make all
$ make install
7) Build GDB
$ tar xjfv gdb-6.3.tar.bz2
$ mkdir build-gdb
$ cd build-gdb
$ ../gdb-6.3/configure --target=$TARGET --prefix=$PREFIX --enable-sim-powerpc --enable-sim-stdio
$ make all
$ make install
Example bare metal hello world!!!
https://github.com/ara4711/ppc_hw
In makefile change, PREFIX=$(PROC)-$(TYPE)- to
PREFIX=/usr/local/powerpc-eabi/bin/$(PROC)-$(TYPE)-
In makefile give path of qemu-system-ppc to QEMU variable.
Command make will generate the test.bin.
Command make run will load the binary and the print “Test Hello
world!“ is displayed on the console
Command make debug to debug test program.
Press Ctrl+a and x to terminate QEMU
QEMU implements a gdb connector using a TCP connection. To do so, run make debug
this command freezes the system before executing any guest code and waits for a connection on the TCP port 1234. From another terminal, run powerpc-eabi-gdb and enter the commands:
target remote localhost:1234
file test.elf
This connects to the QEMU system and loads the debugging symbols of the test program, whose binary image is already loaded in the system memory. From there, it is possible to run the program with the continue command, single-step the program and debug it in general. The exit command in gdb closes both the debugger and the emulator.
First of all, which CPU is this? Secondly, the CPU is not everything.
If you have no starting point, you can study up the BIOS of the architecture you want to write this code for. Then you can write a boot sector which gives you the output you want. Check this page for some examples: Rough guide to assembly
I need to lean on you for some help on stracing android apps in the sdk emulator
here is my setup
android sdk emulator running android api 4.03
adb shell connected to emulator.
I am able to install an apk usng adb install filename.apk
I am able to run the app using
adb shell
am start -a android.intent.action.Main -n com.akproduction.notepad/com.akproduction.notepad.NoteList
I try to strace using (adb shell)
strace am start -a android.intent.action.Main -n com.akproduction.notepad/com.akproduction.notepad.NoteList
but I get nothing!
how do you trace the runtime behavior of android apps and their installation ?
thanks,
Jose.
p.s. the test app is located here: http://www.appbrain.com/app/ak-notepad/com.akproduction.notepad
am is a batch file and cannot be used in strace.
You need to run it like this:
strace -v -fF -tt -s 65535 -o /data/local/tmp/opengl.strace /system/bin/app_process /system/bin com.android.commands.am.Am start -a android.intent.action.MAIN -n demo.opengl.android/.OpenGLDemo
BTW don't use the strace statically compiled binary available for download from:
http://benno.id.au/blog/2007/11/18/android-runtime-strace
It will output nothing.
Instead use the one which comes with the ROM.
I want to debug my kernel module. For that I am trying to put a breakpoint at do_one_initcall in kernel/module.c just before my init_module gets called but it's displaying
Cannot access memory at address
0x802010a0
Below is the Makefile which I am using:
obj-m := hello.o
KDIR=/lib/modules/$(shell uname -r)/build
PWD=$(shell pwd)
EXTRA_CFLAGS += -g
all:
make -C $(KDIR) M=$(PWD) modules
clean:
make -C $(KDIR) M=$(PWD) clean
Please suggest me what could be the problem.
A loadable kernel module's location in the memory is set only upon insertion of the module.
When you set a breakpoint on a module function, gdb consults the module file (.ko) for the address, which is wrong. You need to inform gdb of the actual location of the module.
You can consult this book (chapter 4, Debuggers and related tools section) for more information, but here's a short procedure that I devised for doing that.
machine1 is the debugged machine.
machine2 is the machine running the debugger.
On machine1, run modpbrobe your_module_name
On machine1, run the following shell commands:
MODULE_NAME=your_module_name
MODULE_FILE=$(modinfo $MODULE_NAME| awk '/filename/{print $2}')
DIR="/sys/module/${MODULE_NAME}/sections/"
echo add-symbol-file $MODULE_FILE $(cat "$DIR/.text") -s .bss $(cat "$DIR/.bss") -s .data $(cat "$DIR/.data") you should get an output similar to the following: add-symbol-file /lib/modules/.../your_module_name.ko 0xffffffffa0110000 -s .bss 0xffffffffa011b948 -s .data 0xffffffffa011b6a0
On machine2, run gdb vmlinux.
On machine2, on the gdb console, run the output of the final command in stage 2.
On machine2, on the gdb console, connect to machine1 by running target remote /dev/ttyS0 (assuming your serial port is at ttyS0)
On machine1, run echo g > /proc/sysrq-trigger. The machine will freeze
On machine2, on the gdb console, set the breakpoint as you wish.
Continue debugging. The breakpoint should be triggered when it needs to.
There could be other issues that prevent you from setting the breakpoint, but this is the main hurdle to cross.