I'm developing an application that runs on a small Linux-based SBC (~32MB RAM). Sadly, my app recently became too large to run under GDB anymore. Does anyone know of any good, lightweight debugging methods that I can use in embedded Linux? Even being able to view a thread's stack trace would be extremely helpful.
I should mention that this application is written in C++ and runs multiple threads, so gdbserver is a no-go as it doesn't work with multithreaded apps.
Thanks in advance,
Maha
gdbserver definitely works with multi-threaded applications, I'm working on an embedded project right now with >25 threads and we use gdbserver all the time.
info threads
lists all the threads in the system
thread <thread number from info threads>
switches to that thread of execution.
thread apply XXX <command>
Runs on the thread designated by XXX, which can also be 'all'. So if you want the back trace from all running threads do
thread apply all bt
Once you're in the execution flow of a given threads all your typical commands work as they would in a single threaded process.
I've heard of people doing hacks like running the application in an emulator like QEMU and then running GDB (or things like valgrind) on that. It sounds painful, but if it works....
Would you get anywhere with libunwind (to get stack traces) and printf-style logging?
Serial port printing is the most light weight I can think of ~~~
Easily seen in a Host PC, and simple and light weight code inside your app~~
If you do not have a serial port, once we used an GPIO port and simulated a serial port using it. It worked perfectly well, but was a bit slow :-( ~~~
Is there a reason why you have built your own debugger? I am developing a Linux system using an ARM processor (AT91SAM926x) and we are using both compiler and debugger from CodeSourcery. I do not think that they have released a version with GDB 7 yet but I am debugging multithreaded C++ applications using the gdbserver tool without any problems.
Gdbserver does indeed work with multithreaded applications. However you do need to compile a cross target debugger for your host to get it to work with your target gdb.
See this article for a detailed description of how to do it:
Remote cross-target debugging with GDB and GDBserver
Related
We have an unmanaged C++ application (MFC framework, Windows CE) that closes on us at seemingly random moments.
There is no error message and no C++ exception, it just vanishes.
I presume something bad must have happened and the C run-time or OS decided to kill the program. But I'm not sure where to continue searching.
Question: is it possible to see somewhere in Windows CE why the application terminated in the first place?
Does Windows CE collect basic crash information? Perhaps then one can at least see if it was an Access Violation, an Out of Memory situation, kernel/driver panic or perhaps some other kind of internal or external event that forced the application to close?
On a regular x86 PC one would break out the debugger, application verifier, Windows Error Reporting tools, WinDbg etc. But how to (start) analyze a Windows CE application crash?
What I've tried so far:
Creating global C++ exception handlers at tactical locations in the application. These build and transmit a simple UDP packet containing minimal exception info. these are then viewed on another machine running Wireshark.
Adding the SEH exception compiler switch (/EHa), to be able to catch even those non C++ exceptions, like Access Violation and such.
Connecting the Visual Studio 2008 debugger via TCP/IP with the Smart Device (connects to smart device successfully MSVS says, but debugger doesn't see any remote processes. The Attach to process VS window gives the following error: Unable to Connect to ''.)
Retarget the application so it runs on a regular x86 PC (but then it runs fine, so no "luxury" of debugging the issue there either)
I've tested the exception handler by forcing an Access Violation.
The expected UDP message the arrives at the machine running Wireshark perfectly. But when the real issue occurs, it stays completely silent.
The platform: MS Windows Embedded Compact 7.02 running on a Texas Instruments processor (ARM A8).
The application itself implements a rudimentary VNC viewer. It uses sockets and relies on a third party binary called zlib CE (ZLIBCE.DLL) for decompressing VNC data.
It hasn't been verified if the zlib binary has been built against the exact same compiler (and/or compiler settings).
Settled for a poor man's debugging solution. Now sending application state values to a memory mapped file. The idea is that a specially crafted helper program runs along the main application. This program opens the memory mapped file, displays values it reads from it. And the main program writes to it. If anything fatal happens to the main app, the helper program has the latest state info. Since it is shared memory it doesn't impact performance much. This way found the section of the program where the fault occurs.
How can I execute the shell commands like dump memory (d()), xbdCreatePartition, dosFsVolFormat, dosFsShow from an RTP application program?
Linux provides system commands to do this job, how is this achieved in VxWorks6.9?
If you are looking for an equivalent of system(), to allow you to execute an arbitrary command, you are out of luck.
However, the "Shell" that you are used to interacting with is actually a C interpreter, and any command you are running is available to be called from code. So you could call dosFsVolFormat for example from your own code.
There is a caveat here, which is that most functionality is implemented in the kernel, and so these functions may not be available in your RTP. The functions available vary from release to release, and may also be dependant on your kernel configuration. You can compare the user versions of headers to the kernel version to see what might be available.
You can always write your own system calls, however, to expose kernel functionality to a RTP application.
You cannot call kernel functions directly from RTP. You can create a kernel module project that can take commands from TCP and execute kernel functions for you. And from your RTP project you'd be sending these commands from TCP. You can use serial channel protocols or message channel, etc instead of TCP.
The main reason for this is to seperate kernel space from application space so that your application won't cause a crash on kernel.
I assume that you have a host pc and a target running on vxworks. That means you are using a Cross-compiler IDE such as Windriver Workbench or Tornado.
At this moment, you have 2 possibilities.
1) Your target has an VGA or HDMI port on it so you can easyly plug in a monitor and you can see the vxworks shell operating on a blue screen.
There you can run your shell commands.
https://userweb.jlab.org/~brads/Manuals/VxWorks/vxWorks_commands.html
2) You can use the windriver debugging tool. But you need to add components to your vxworks kernel image such as INCLUDE_DEBUG_AGENT. You can configure it yourself. When you connect your remote device, you can open a shell window and start typing system calls.
https://borkhuis.home.xs4all.nl/vxworks/vxw_pt2.html
Good luck...
I'm looking for some help with an implementation problem I'm facing. I'm an experienced C/C++ programmer in embedded environments and RTOSs, but when it comes to linux I'm a newbie.
I have a beaglebone black running Debian. I need to log and process data from sensors connected to the I2C bus and the ADC. I have written the handler functions for collecting the data from the sensors connected, no problem there, they work fine. I want to implement (similar to a RTOS) a timer interrupt that can throw the process to my handler functions so they can do their things and I want this to run in the background. i.e. I don't want to tie up the shell or whatever so the user can do other things. I was reading that timer_create is a way do this within Debian, or using fork()-exec() but I thought I'd ask people experienced in Linux first before going down any particular path! Also, not 100% sure how to use either of these functions.
side-note: I know that timers etc. are not highly accurate in Linux unless you are implementing pre-emptive kernels or whatever, which is a whole other problem in itself, but the time constraints of this problem are somewhere near 10-50ms which is not extremely tight.
Thanks
to make a daemon process , just take this as a reference:
https://github.com/memcached/memcached/blob/master/daemon.c
I'm looking for a tool for performance analysis and debugging that plots threads context switches, and maybe semaphore states, events, ...
I've used tools like that in the embedded world but I'm now looking for the same in the windows or Linux platforms.
The application I want to profile is a c++ multithreaded application.
Does anyone has a tool to recommend for this ?
For Linux and Solaris the Oracle Thread Analyzer from the Oracle Solaris Studio (it also runs on Linux despite its name) can provide a lot of insight into the performance problems of multithreaded applications. Besides Oracle Solaris Studio is still free.
Intel VTune Amplifier XE (previously called Intel Thread Analyzer) is available on both Linux and Windows.
On Windows you can use xperf tool to collect and plot context switches. It's a free tool, which is a part of Windows Performance Analysis Developer Center. Worked fine for me, see screenshot.
Windows Performance Monitor?
perfmon.exe
I think it's standard on most Windows Platforms and provides information on context switches and much much more.
Windows only I'm afraid though.
Probably this is not the tool you are thinking about, but it is simple, fast and can be useful.
When using GDB, you can type:
info threads
to see information about threads being run. Next you can switch to the chosen thread and print the backtrace to see, where it was:
thread <thread-id>
bt
i need to find away to turn on the pc from c++ application ,
is there any way to do this?
Thanks
If the computer is off, it can't be executing code, and therefore can't turn itself on programmatically.
ACPI changes that somewhat, but for us to be able to help, you have to be more specific about your exact requirements.
If you need to turn on a different computer, take a look at Wake-on-LAN.
You will not be able to write a program to turn a computer on that the program itself is installed on.
If you need to write an application that will turn on a different computer, Wake-on-LAN is the tool for you. Modern desktops have NICs that is always receiving power - even if the computer is in an S5 state. Assuming the BIOS supports it and it is enabled.
Wake-On-LAN works by sending a Magic Packet to the NIC. The details of what the payload consists of is outlined in the article.
This is possibly a duplicate of C#: How to wake up system which has been shutdown? (although that is C#).
One way to do it under windows is to create a timer with CreateWaitableTimer(), set the time with SetWaitableTimer() and then do a WaitForSingleObject(). Your code will pause, and you can put the computer into standby (maybe also hibernation, but not shutdown). When the timer is reached, the PC will resume and so will your program.
See here for a complete example in C. The example shows how to calculate the time difference for the timer, and how to do the waiting in a thread (if you are writing a graphical application).
I have to add, you can also schedule the computer to wake up using the Windows Task Scheduler ('Wake the computer to run this task'). This possibly also works when the computer is shut down. There is also an option in some computers BIOS to set a wake time.
Under Linux, you can set the computer to wake up by writing to a special file:
echo 2006-02-09 23:05:00 > /proc/acpi/alarm
Note that I haven't tested all of this, and it is highly dependent on the hardware (mainboard), but some kind of wake-up should be available on all modern PCs.
See also: http://en.wikipedia.org/wiki/Real-time_clock_alarm ,
and here is a program that claims to do it on windows: http://www.dennisbabkin.com/wosb/
Use strip. If you require a Windows computer to be turned on, the cross-tools i686-w64-mingw32-strip or x86_64-w64-mingw32-strip should be used. These command-line programs modify an executable, and the result is able to turn on a computer.
How could you turn on a computer from an application, when no processes are running on it when it's shut down ? You can turn on another computer (Wake on Lan), but not the one you are running.
It is possible.
First thing to do is configure Wake On Lan. Check out this post on Lifehacker on how to do it: http://lifehacker.com/348197/access-your-computer-anytime-and-save-energy-with-wake+on+lan.
(Or this link: http://hblg.info/2011/08/21/Wake-on-LAN-and-remote-login.html)
Then you need to send a magic packet from your C++ application. There are several web services that already do this from javascript (wakeonlan.me) , but it can be done from within a C++ application as well.
Chances are, that if you want to do this, you are working with servers.
In such case, your mainboard may should an IMPI baseboard management controller.
IPMI may be used to cycle the chassis power remotely.
Generally, the BMC will have its own IP address, to which you may connect to send control messages.