I wrote a simple program for eCos in stm32f4discovery Cortex-M4, which following steps below.
$ecosconfig new stm32f4discovery
$configtool
#include <stdio.h>
int main(){
printf("hello ecos!\r\n");
return 0;
}
$arm-none-eabi-gcc -o hello.elf hello.c -Lecos_install/lib -I ecos_install/include -mcpu=cortex-m4 -mthumb -g -O2 -ffunction-sections -fdata-sections -Ttarget.ld -nostdlib
$arm-none-eabi-objcopy -O binary -R .sram hello.elf hello.bin
Actually, it is success. But, I don't know how to see the "hello ecos!".
I guess I need to setup baud rate and tty. So, I use minicom to do this. Unfortunately, I failed.
I use this stlink util to debug STM32F4 apps. After you compile and invoke this util, you can connect to stm32 target with gdb:
(gdb) tar ext :4242
(gdb) load hello.elf
Then you should be able to debug your app.
Related
I've been trying to convert a cpp file to wasm without emscripten recently and I've been running with some errors, for example, when I run these commands:
clang++ --target=wasm32 -nostdlib -O3 -o public/main.o -c src/*.cpp
wasm-ld --no-entry --export-all --lto-O3 --allow-undefined --import-memory public/main.o -o public/main.wasm
it gives me this error:
wasm-ld: error: unknown file type public/main.o
Here are the versions of clang and lld that I currently have:
clang version 12.0.1
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/jp4r5v8pla63qam5w34jvfyfmq8p74am-clang-12.0.1/bin
LLD 12.0.1
Also, I'm running the code on replit
Thank you
Ok, with this commands it works :D
clang++ --target=wasm32 -emit-llvm -c -S -o public/files/main.ll src/main.cpp
llc -march=wasm32 -filetype=obj -o public/files/main.o public/files/main.ll
wasm-ld --no-entry --export-all -o public/main.wasm public/files/main.o
The only thing is that you need to create some new files (main.ll and main.o) but it doesn't matter.
The place where I obtained the solution is here: https://surma.dev/things/c-to-webassembly/index.html
It was really useful
According to official documentation, Clang 13 supports C++20 Modules thru the use of a -fmodules command-line parameter.
I cannot even get a basic module to compile using Clang 13 (macOS Monterey) either on an Intel or M1 based macs.
Assuming the following text contents of file module.cpp:
export module a;
export int f(int a, int b) {
return a + b;
}
Running the following:
$ clang++ --version
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: x86_64-apple-darwin21.1.0
$ clang++ -std=c++20 -stdlib=libc++ -fmodules -fbuiltin-module-map -c module.cpp
module.cpp:1:8: error: expected template
export module a;
^
module.cpp:1:8: error: unknown type name 'module'
module.cpp:3:8: error: expected template
export int f(int a, int b) {
^
3 errors generated.
Tested with identical results on an ARM M1 chip:
$ clang++ --version
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: arm64-apple-darwin21.1.0
Is there another way to get modules working OR is there some undocumented C++20 modules limitation with Apple Clang 13?
Note: compiling with the experimental -fmodules-ts flag works.
Cause
Thanks for the comments - the errors above are an indication of a Clang version that was built without module support. This is what Xcode comes with, i.e. by running xcode-select --install in a terminal.
Solution
As suggested the solution has been to install Clang thru HomeBrew which is done as follows (tested on macOS Monterey):
brew install llvm
Clang gets installed to /opt/homebrew/opt/llvm/bin/clang++. Confirm the running version as shown below:
% /opt/homebrew/opt/llvm/bin/clang++ --version
Homebrew clang version 13.0.0
Target: arm64-apple-darwin21.1.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
Which is a different build from the Xcode system-wide default version:
% clang++ --version
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: arm64-apple-darwin21.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Working Example
Steps to see working example loosely based on repo posted by #alexpanter:
main.cpp
import <iostream>;
import mathlib;
using namespace std;
int main() {
cout << "Modules, baby!" << endl;
cout << "2 plus 3 makes " << add(2, 3) << " says module 'mathlib'" << endl;
}
mathlib.cpp
export module mathlib;
export int add(int a, int b)
{
return a + b;
}
Build by runnning in a terminal in same directory as files above:
/opt/homebrew/opt/llvm/bin/clang++ -std=c++20 -c -Xclang -emit-module-interface mathlib.cpp -o mathlib.pcm
/opt/homebrew/opt/llvm/bin/clang++ -std=c++20 -fmodules -c -fprebuilt-module-path=. main.cpp -o main.o
/opt/homebrew/opt/llvm/bin/clang++ -std=c++2a -fmodules -o main main.o *.pcm
Test module-based executable:
./main
Expected output:
Modules, baby!
2 plus 3 makes 5 says module 'mathlib'
Consider the following CUDA program, in a file named foo.cu:
#include <cooperative_groups.h>
#include <stdio.h>
__global__ void my_kernel() {
auto g = cooperative_groups::this_grid();
g.sync();
}
int main(int, char **) {
cudaLaunchCooperativeKernel( (const void*) my_kernel, 2, 2, nullptr, 0, nullptr);
cudaDeviceSynchronize();
}
This program needs to be compiled with -rdc=true (see this question); and needs to be explicitly linked against libcudadevrt. Ok, no problem... or is it?
$ nvcc -rdc=true -o foo -gencode arch=compute_61,code=sm_61 foo.cu -lcudadevrt
nvlink error : Undefined reference to 'cudaCGGetIntrinsicHandle' in '/tmp/tmpxft_000036ec_00000000-10_foo.o'
nvlink error : Undefined reference to 'cudaCGSynchronizeGrid' in '/tmp/tmpxft_000036ec_00000000-10_foo.o'
Only if I explicitly add the library's folder with -L/usr/lib/x86_64-linux-gnu, is it willing to build my program.
This is strange, because all of the CUDA libraries on my system are in that folder. Why isn't NVCC/nvlink looking in there?
Notes:
I'm using Devuan GNU/Linux 3.0.
CUDA 10.1 is installed as a distribution package.
An x86_64 machine with a GeForce 1050 Ti card.
NVCC, or perhaps nvlink, looks for paths in an environment variable named LIBRARIES. But - before doing so, the shell script /etc/nvcc.profile is executed (at least, it is on Devuan).
On Devuan 3.0, that file has a line saying:
LIBRARIES =+ $(_SPACE_) -L/usr/lib/x86_64-linux-gnu/stubs
so that's where your NVCC looks to by default.
You can therefore do one of two things:
Set the environment variable outside NVCC, e.g. in your ~/.profile or ~/.bashrc file:
export LIBRARIES=-L/usr/lib/x86_64-linux-gnu/
Change that nvcc.profile line to say:
LIBRARIES =+ $(_SPACE_) -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/stubs
and NVCC will successfully build your binary.
I'm trying my hand at using the relocatable-device-code flag. I have a large project that would be easier to maintain with small blocks of code.
I was able to get the project to compile. When trying to run it, I get a hard crash. When using the debugger:
(gdb) where
#0 0x0000000000000001 in ?? ()
#1 0x00007fffffffe39c in ?? ()
#2 0x0000000000000000 in ?? ()
I've never seen a stack trace like that! I then reduced the amount of code until I came down to a singularity: main.cu file contains only
#include <iostream>
int main(void) {
std::cout << "hello, world" << std::endl;
return 0;
}
Which still fails. I'm using the following flags to compile my main.cu file.
nvcc -shared -rdc=true -arch=sm_20 -Xcompiler -fPIC -g -G
Do these make sense? Why the segmentation fault for such a simple progam?
Remove the -shared switch. That option is not applicable when you are trying to generate an executable.
From the documentation:
Generate a shared library during linking. Note: when other linker options are required for controlling dll generation, use option -Xlinker.
#include <stdio.h>
#include <pcap.h>
int main(int argc,char* argv[])
{
char* dev=argv[1];
char errbuf[PCAP_ERRBUF_SIZE];
dev=pcap_lookupdev(errbuf);
if(dev==NULL) {
fprintf(stderr,"Couldn't find default device: %s\n",errbuf);
return 0;
}
printf("Device: %s\n",dev);
return 0;
}
On compiling:
$ cc pcap1.c
/tmp/ccZLrRlF.o: In function `main':
pcap1.c:(.text+0x37): undefined reference to `pcap_lookupdev'
collect2: ld returned 1 exit status
This is happening with other functions of the libpcap library as well. Can you please explain the problem to me and a way to correct it? Thanks in advance...
Because you're not linking the pcap library when you're compiling, therefore none of the functions you're trying to use are available.
cc pcap1.c -lpcap
If you haven't installed libpcap somewhere in the standard library path, you would need to add that as well
cc pcap1.c -lpcap -L/directory/libpcap/is/in
I had this Error and I have just solved it.
I am working on Debian 7 so here is what I have done:
1 - insaled the libpcap you find how in this link install libpcap
!!!!!! installed flex (sudo apt-get install bison) because I had some problems while
installing libpcap
2 - gcc test.c -lpcap that returned this error " collect2: ld returned 1 exit status "
3 - installed libpcap-devel (sudo apt-get install libpcap-dev)
and it went through the next time
I hope this is going to be of help to you.
good luck