I want to monitor a process and everything it does (every signal it gives SIGINT what ever).
Is there anyway to do this?
I'm using Linux (Ubuntu 11 to be exact)
The strace unix command will do all that and more if you're looking for command-line monitoring.
It uses the ptrace system call infrastructure for monitoring which is in itself even more powerful: additionally allowing control of and interaction with the process. To quote from Wikipedia:
ptrace is used by debuggers (such as gdb and dbx), by tracing tools like strace and ltrace, and by code coverage tools. ptrace is also used by specialised programs to patch running programs, to avoid unfixed bugs or to overcome security features. It can further be used as a sandbox and as a runtime environment simulator (like emulating root access for non-root software).
If you want to do this monitoring programatically rather than from the command line, then ptrace is the solution for you.
strace ought to work, or something listed in the "Other Tools" section on that page.
Related
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
I'm working on safety-critical software that requires extensive testing. The target processor, a Cortex-M4, has rich resources for the application but the unit and integration tests, if aggregated, would be much larger than the on-board FLASH/RAM. They are designed to be run from gdb while using semi-hosting to off-load the test results. What's needed is a way to automate the testing so it can be run without per-test human intervention.
The test programs run fine from Eclipse using both OpenOCD and Segger debugger front-ends. These require per-test configurations and then manual starting of the tests. There will be 30-50 test programs so this isn't really viable for continuous integration or simple batch runs.
I've been looking around for possible ways to do this. There are a few tricky bits to consider. The first is supporting the semihosting of the output. That uses the breakpoint system to have the I/O from the host. In this use, a couple of files get opened on the host computer for logs. Another issue is ending the program being tested and loading the next. The programs can take a long time to run and drop into an infinite loop when the main() is exited. And the development platform is Windows 10.
The two basic ideas I've had are to use the gdb client library from cygwin to create a custom program or to use OpenOCD. Running through multiple tests could be done inside the application or from a Makefile.
Question: is the semihosting done in the gdb client or server?
So... Looking for some suggestions or experiences in creating what I picture as a custom gdb client in Win10.
There are tools that enable one to run a console command or a console application as a daemon. To "daemonize" it, so to say.
Is there a way to run a daemon as a regular console application?
I'm coding in KDevelop and don't see any options for daemon debugging.
Thanks !
It's reasonably normal to add a special debugging mode to daemons to enable this. That is, add in a command-line option to disable the daemonizing step, having the program run in the foreground. Then it is is simple to run the daemon under gdb.
I'm not aware of any generic way to do this. Maybe it could be done somehow with LD_PRELOAD interception, which would be cool -- but it's simpler to just modify the source.
For debugging a running daemon you can use the gdb attach command. However this is not very good for debugging daemon startup, as you'll have to race to attach in time.
The linux kernel doesn't support any way to "pre-attach" to the next instance of a program, but I wrote a hack to do it via SystemTap that you can find here.
Currently the gdb console of Eclipse just connects the stdin/stdout between the java gui and the underlying gdb process, hence many gdb shell features are missing, e.g. tab-autocomplete, command history etc.
I want to know if there is an enhanced console for fast gdb interacting. I really like the frequently used gdb commands like "print" and "call" etc. IMHO, "print" command is superiors sometimes than Eclipse "Expression watcher" because it only execute once and the later will be evaluated any time and be crash-prone.
If you think there is no need to use gdb console, then what's you best-practise in terms of gdb UI to eclipse UI transfer.
There doesn't seem to be any gdb-specific plugin, beside the initial gdb integration initiated with Eclipse3.4.
And the current list of gdb bugs doesn't include your missing features.
If you're writing c/++, why not just find the eclipse-generated elf and use gdb via the shell?
How can I configure windows to generate a core dump from an application?
I'm using Win xp, and the application is build with Visual Studio 2003.
Microsoft has a free tool called Userdump.exe which will do this.
It's pretty simple to use that tool to create a dump (.dmp) file for a process that shuts down with an exception or to create a dump file for a hanging process
Just to throw in some other suggestions:
ProcDump that is part of the MS SysInternals suite (it captures crashes but also does a load more, can take dumps if CPU usage spikes for an amount of time, etc)
You can put code into your exe using MiniDumpWriteDump to save out dumps youself (which I've done in a few tools). You have control over the name and location (i.e. network path). There's some sample code here
You can open Task Manager (by right clicking the task bar), find your process in the processes tab, right-click it and select Create Dump File.
You might try using WinDbg as described here.
You can use adplus to produce a crash dump for a running application. The command may look something like this:
C:\Program Files\Debugging Tools for Windows\adplus.vbs -hang -do -o c:\ -quiet -pn theprocess.exe
You can also attach to a process with windbg and run this command:
.dump /ma c:\somepath\filename.dmp
I refer you to the follows MS KB article on the subject. You would typically debug the dump file using one of the Windows debugging tools, e.g. WinDbg. There are many articles on the web describing how to do this.