I have a script to setup different stuff before I start debugging the target with Trace32. Sometimes I debug also on simulator where some steps are not relevant for.
I want to check in a script if I run on simulator or I am attached to live system. Is there any cmd or way to achieve it in .cmm?
Thanks,
You can check if you're using the simulator with the PRACTICE function SIMULATOR().
E.g.:
SYStem.CPU STM32F407VG
IF !SIMULATOR()
(
// Commands only executed if you're not in simulator mode
SYStem.JtagClock 10.MHz
SYStem.CONFIG DEBUGPORTTYPE SWD
SYStem.MemAccess DAP
)
ELSE
(
// Commands only executed if you're in simulator mode
SYStem.MemAccess CPU
)
Related
I'd like to to debug a multiprocess C++ project with GDB, specifically I'd like to know if there is a way to achieve the following
Attach multiple processes to a single instance of GDB while letting all the processes run
Setting up a breakpoint in the source code of one of the processes stops all the attached processes
The ideal solution would be something similar to what is offered by the Visual Studio debugger as described here.
At the moment I'm able to attach multiple processes to a GDB instance but then only the current selected inferior is executed while the others are stopped and waiting for a continue command.
In order to be able to run inferiors in the background, one needs to issue this gdb command
set target-async on
after start up and before running anything. With this option in effect, one ca issue
continue&
(or just c&) and this will send the inferior to the background, giving an opportunity to switch to run another one.
Stopping all inferiors at once is a bit more difficult. There is no built-in command for that. Fortunately gdb is scriptable and it is possible to attach a script to a breakpoint. Once the breakpoint is hit, the commands are executed. Put inferior n and interrupt commands in the script for each inferior. It is probably more convenient to do that from a Python script, something like
(gdb) python
>inf = gdb.inferiors()
>for i in inf:
> gdb.execute("inferior %d" % i.num)
> gdb.execute("interrupt")
Functions like endpointvolume and waveoutSetVolume only works for the application itself, and not the entire computer. Im looking for help, at finding options for code that will:
Control the master volume (The whole pc volume not only one application)
When opened (exe file) the code will place it self in the startup folder on the pc. I have thought of setPathway, but couldn't get it to work.
You can use SetMasterVolume(). As for making it start every time, see here: Add Application to Startup (Registry)
I am using gdbserver to debug a remote process. I am able to attach gdbserver to the process after it has launched and is waiting for input.
However, I want to attach gdbserver to the process while it is being launched. The process is launched via a shell script and I cannot change how this process is being launched i.e. I cannot modify the shell script to launch the process via a call to gdbserver.
How do I attach gdbserver to this process as soon as it launches?
Edit: I am able to create a wait loop at the start of main(). For example a loop which waits till it finds a file at a predetermined location :
#include <unistd.h>
int main() {
while( access("/home/username/CONTINUE", F_OK) == -1)
sleep(1);
/*
...all the rest of main()
*/
return 0;
}
We can attach gdbserver while the process is busy with this loop, set breakpoints as required and say touch /home/username/CONTINUE to exit the loop. But this requires us to be able to access the source code, compile the binary and place it on the target machine. I am looking for a better, easier way than this.
But this requires us to be able to access the source code1, compile the binary and place it on the target machine. I am looking for a better, easier way than this.
It looks like you are working on a linux / unix like remote operating system.
If you have admin access to the remote system, the simplest way I could think of is to rename the original executable, and replace that with a shell script named like the original executable, that starts the now renamed under control of gdbserver.
Something like (assumed executable /usr/bin/foo) at the target machine:
root:# cd /usr/bin
root:# mv foo foo_
root:# echo "#!/bin/sh\ngdbserver /dev/com1 foo_ foo.txt" > foo
root:# chmod a+x foo
As it says in the gdbserver man(1) page:
This tells gdbserver to debug foo_ with an argument of foo.txt, and
to communicate with GDB via /dev/com1. gdbserver now waits patiently
for the host GDB to communicate with it.
Another way I could think of without modifying the original process at all, could be a little program that monitors changes in the /dev/proc directory(ies), and attaches gdbserver at such event with the associated pid.
Though it's kind of luck then, if gdbserver is attached, before that process already schedules to main().
1You should have acces to the source code anyways for reasonable debugging with gdb. Though there are cases where you can just get with the (dis-)assembly code as well.
What I'd like to know is if it is possible, inside a debugging session in Linux, (read: gdb :)) to stop the execution of a single thread, leaving the other threads to run.
If someone is curious to know why keep reading:
I wrote a software watchdog C++ class (using Qt). I tested it with a simple multithreaded program, but I'd like to test the code once I integrate it inside the real application as well. If I could stop a thread from the debugger, that will simplify this testing phase. :)
Cheers
Sergio
Use this sequence of commands before you run or attach to your program:
Enable the async interface:
set target-async 1
If using the CLI, pagination breaks non-stop:
set pagination off
Turn it on:
set non-stop on
Use these commands to manipulate the non-stop mode setting:
Enable selection of non-stop mode:
set non-stop on
Disable selection of non-stop mode:
set non-stop off
Show the current non-stop enabled setting:
show non-stop
References:
http://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html#Non_002dStop-Mode
You may use totalview debugger to do that
If that little variation is OK, you could send the thread a STOP signal (not as a gdb command the gdb - that the variation) and debug everything else running. Signal CONT lets the thread continue.
How can i programatically check if the windows shell (explorer) has loaded all startup programs & the user login process is over ?
There is a somewhat documented event you can wait for, but it is signaled when explorer has started loading. On XP this event is called "msgina: ShellReadyEvent" and "ShellDesktopSwitchEvent" on Vista. I linked to the sources of some alternative shells in a post related to this event.
Another alternative would be to listen for the Taskbar Creation Notification message. It can fire more than once so you would need to keep track of that.
On Vista+ there is one last alternative that might just work: Programs set to run at startup are part of a job object so they cannot run at high priority. If your program runs at startup you could maybe check for this, either by using IsProcessInJob or SetPriorityClass+GetPriorityClass in a loop. (SetPriorityClass will lie about its return value IIRC)