embedded-linux

I followed this post to print stack trace How to generate a stacktrace when my gcc C++ app crashes . It works well in x86 linux. Can anyone teach me how to make it work on arm-linux? I am using arm-linux-gcc 4.4.3. [root@FriendlyARM /]# ./test1 Error: signal 11: [0x0] in x86 mickey@mickeyvm:~/Desktop/workspace/test/testCatchSeg/src$ ./test1 Error: signal 11: ./test1(_Z7handleri+0x19)[0x804876d] [0xedd400] ./test1(_Z3bazv+0x10)[0x80487c2] ./test1(_Z3barv+0xb)[0x80487e1] ./test1(_Z3foov+0xb)[0x80487ee] ./test1(main+0x22)[0x8048812] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x84de37]

Update, 4/10 2012: Fixed by libc patch I have a problem canceling threads in pthread_cond_wait , that use mutexes with the PTHREAD_PRIO_INHERIT attribute set. This only happens on certain platforms though. The following minimal example demonstrates this: (compile with g++ <filename>.cpp -lpthread ) #include <pthread.h> #include <iostream> pthread_mutex_t mutex; pthread_cond_t cond; void clean(void *arg) { std::cout << "clean: Unlocking mutex..." << std::endl; pthread_mutex_unlock((pthread_mutex_t*)arg); std::cout << "clean: Mutex unlocked..." << std::endl; } void *threadFunc(void *arg) { int

I am running an embedded application on ARM9 board, where total flash size is 180MB only. I am able to run gdb , but when I do (gdb) generate-core-dump I get an error warning: Memory read failed for corefile section, 1048576 bytes at 0x4156c000. warning: Memory read failed for corefile section, 1048576 bytes at 0x50c00000. Saved corefile core.5546 The program is running. Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal] Tamper Detected **********OUTSIDE ifelse 0********* length validation is failed I also set ulimit -c 50000 but still the core dump exceeds this limit.

I would like to have more clarification on the functionality of sync(8) and fsync functions in Linux (2.6.31). Does it make sure the files are written to the respective storage? Oliver http://linux.die.net/man/8/sync It does not make sure that files are written to respective storage. It only makes sure that cached/buffered data is flushed to the disk device. It doesn't matter if this is an SD Card or whatever. 来源： https://stackoverflow.com/questions/12262454/fsync-sync-does-it-really-do-what-its-supposed-to

I am trying to understand how vectors page is mapped to 0xffff0000. I am referring 3.14 kernel. As per the comment in early_trap_init() traps.c the vectors are copied from entry-armv.S to vector page. It seems early_trap_init() is called from devicemaps_init() mmu.c . Before calling early_trap_init() , it is creating vectors page using early_alloc() and I couldn't see any mapping here. Can you please help to understand how vectors page mapping is done? artless noise The answer is in your devicemaps_init() link (about line 1250 in 3.14). /* * Create a mapping for the machine vectors at the high