I have small question. Is it possible in C/C++ to put bit of codes that would interact a bit more with GDB ?
Let say I have a function like
void gdb_print(const char*);
This would print information in gdb while it executes! If it's not possible it would be awesome. Would be simple to track some information, and faster in some way!
I need something like this, because we're writing some plugins, and info from cout or cerr are not going to the console at all. So it would be something discrete. Also, could add some stuff like:
#ifdef __DEBUG__
#define debug_msg(x) gdb_print(x)
#else
#define debug_msg(x)
#endif
If it doesn't exist, let me know what you think about this!
I need something like this, because we're writing some plugins, and info from cout or cerr are not going to the console at all.
You can always write to console with:
FILE *console = fopen("/dev/tty", "w");
if (console != NULL) fprintf(console, "Your debug message\n");
I don't know of a method to write specifically to the terminal where GDB is running (which could well be different terminal from which the program itself was invoked).
try redirecting the stderr and stdout to a file using freopen. see this
This is a sample code to redirect stdout to a file in runtime:
/* freopen example: redirecting stdout */
#include <stdio.h>
int main ()
{
freopen ("myfile.txt","w",stdout);
printf ("This sentence is redirected to a file.");
fclose (stdout);
return 0;
}
static int gdb = 0;
void gdb_print(char const * msg) {
if(gdb) printf("\tGDB: %s\n", msg);
}
When you load your program up in gdb, set a breakpoint in main, then set gdb to a non-zero value. This isn't the cleanest solution (and certainly not automated) but I think it'll give you what you're looking for. Be sure to use the per-processor to remove the calls in non-debug builds (no sense in having all those extra compares that'll never evaluate to true).
Related
I am fairly new to using gdb debugger and so coming across the code being displayed when I ran gdb left me having no use for the debugger. I am unfamiliar with the code being displayed but a did a little research and I assume I accidentally opened up a "thread"? It's hard to explain something I do not understand but I will link a picture explaining what I am talking about. Basically I want to revert back to the "basic" display of my actual code and not this: displayed by the debugger
Your program called one of scanf family of functions, with a NULL stream.
Usually this happens when you don't check for errors. For example:
FILE *fp = fopen("/file/which/does/not/exist", "r");
char ch;
fscanf(fp, "%c", &ch); /* BUG: should check fp!=NULL first. */
You should always check return value from any function that may fail.
You can see which code called into the fscanf with GDB where command.
Is there c++ or c code anywhere that will help me use printf in keil uvision 5 for the stm32f4-eval2 board? I know you have to retarget the uarts and usarts but I have not been able to do this without errors even with help from the sites I have found online.
I would like to be able to use the debug printf viewer.
I tried the following link but it did not work: http://www.keil.com/support/man/docs/ulinkpro/ulinkpro_trace_itm_viewer.htm
You are not very specific if you want to print via UART or if you want to print via ITM debug channel. For ITM it is pretty simple. Create a file with the following content and make sure SWO trace is enabled on your debug connection:
#include <stdio.h>
/* Replace next line: Include the device system header file here */
#error "device include file missing"
/* e.g.: #include "STM32F4xx.h" */
#pragma import(__use_no_semihosting_swi)
volatile int ITM_RxBuffer = ITM_RXBUFFER_EMPTY; /* CMSIS Debug Input */
int fputc(int c, FILE *f) {
return (ITM_SendChar(c));
}
int fgetc(FILE *f) {
while (ITM_CheckChar() != 1) __NOP();
return (ITM_ReceiveChar());
}
Make sure you tick the "Use MicroLib" option in Options for Target->Target
I am trying to get my program to log the output of a console application to a text file before it quits. This is a GUI program which launches the console application (tool.exe). The problem is that I am using CTRL + C to quit the console application. This console application cant be altered either. I have tried a few ways of doing this but none have seemed to work ( tool.exe > output.txt ).
Can anyone point me in the right direction of which approach to take ? It would be greatly appreciated.
EDIT:
The file is created but it is empty and does not receive any data. The thing I am after noticing though is if I run the tool from the command line myself, it will work. Eg. c:\>tool.exe > output.txt However this is not working when its executed from my GUI application.
Here is the code I am using to execute the tool:
strcpy (tool, "\" start /D \"");
strcat (tool, toolLocation);
strcat (tool, "\" tool.exe > output.txt\"");
system (tool);
This will run tool.exe and create output.txt fine but will not output anything to the file.
EDIT2:
I think what is actually happening is that because I am using start , the >output.txt is outputing start instead of tool.exe. This would explain why it creates the empty file. Start is just running a fresh command line which is then running tool.exe. The problem is, how do I get around this issue now ?
Try:
#include <signal.h>
void signal_handlerkill(int sig)
{
//Do Soemthing
exit(1);
}
int main()
{
signal(SIGINT, signal_handlerkill); //Connect the interrupt signal (^C) to the function
//Do your code here
return 0;
}
And if that doesn't work, I'd suggest looking here. Specifically:
// crt_signal.c
// compile with: /c
// Use signal to attach a signal handler to the abort routine
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <tchar.h>
void SignalHandler(int signal)
{
printf("Application aborting...\n");
}
int main()
{
typedef void (*SignalHandlerPointer)(int);
SignalHandlerPointer previousHandler;
previousHandler = signal(SIGABRT, SignalHandler);
abort();
}
If you run the application without redirecting to a file, do you see the output you need on the console when you press ctrl+c?
If you don't then there is nothing you can do since you cannot change the application.
Update
What you need is to redirect stdout and stderr to the file. I have never done that but jamesdlin seems to have done that. Take a look at his comment.
What you could try is instead of using start try using cmd.exe directly.
This is the code which managed to solve the problem for me:
char path[500]; //Create character array
strcpy (path, "cd "); //Copy 'cd' into the array
strcat (path, toolLocation); //Copy the path of the tool into the array
strcat (path, " & ip.exe > output.txt"); //Append on the name of the exe and output to a file
system (path); //Run the built array
I am creating a character array and then appending to it. The vital bit here was the & being used in the system call. This is working as an and and first cd'ing to the firectory before executing the .exe.
I have just upgraded to Xcode 4 and am working in C++ project. I am finding that printf() intermittently fails to complete printing (mid-line) to the Xcode console, and from there on printf() ceases to print anything - even though the application continues to run in debugger.
I suspect Xcode 4's console window is at fault because if I redirect stdout to a file, then logging seems to continue without any problems. That said, if I use following on command line:
tail -f log-out.txt
then there are times when incomplete lines are shown. But this is probably due to some sort of buffering (incomplete flush) because ultimately the lines are complete in the file.
So, I am wondering if anyone has experienced something like this and has an understanding of what's causing freeze in Xcode's console output.
Never actually worked with Xcode, BUT:
Can you show us how your printf calls look like?
The reason why I'm asking is that, if you don't flush your stream, some of the output might not reach the console (as you actually pointed out in the question). The simplest way to do that is to add a newline character at the end of each printf call.
This behavior seems to be intermittent and reportedly pre-exists Xcode 4. As a work-around I did something like this to the main() function. There are some advantages to this approach when Xcode's Debug Console is misbehaving.
#define REDIRECT_STDOUT_TO_FILE 1
int main(int argc, char ** argv)
{
#if REDIRECT_STDOUT_TO_FILE //## redirect stdout to "log-out.txt"
freopen("log-out.txt", "w", stdout);
#endif // REDIRECT_STDOUT_TO_FILE
MyApp app(argc, argv);
int result = app.Run();
#if REDIRECT_STDOUT_TO_FILE //## redirect stdout to "log-out.txt"
fflush(stdout);
fclose(stdout);
#endif // REDIRECT_STDOUT_TO_FILE
return result;
}
Using tail -f log-out.txt in Terminal allows one to view stdout output. Or, if you use BBEdit, bbedit --new-window log-out.txt is also an workable solution.
For now, I am considering this a bug in Xcode - and I will continue trying to understand under what conditions it occurs.
I have this c++ program that is doing a simple ping on a specified ip address. I am not into networking so i'm just using the system() command in c++ to execute the ping from a shell and store the results in a file, that's easy.
The problem is that i want some dots to be printed on the screen while the system() command is being executed. i tried with:
while(system(cmd))
{
//execute the task here
}
but no success. I think that i should create threads or something.
Can you help me ? What exactly i am supposed to do in order to get this done as i want to ?
The problem with system is that it suspends execution until completion. On unix systems you will need to use a sequence of fork, execv, dup2 and pipe. This will allow you to do something more useful. See http://docs.linux.cz/programming/c/unix_examples/execill.html for an example.
You need to create a forked process using fork, like this, and using popen to read the input from the output of the command ping google.com and process it accordingly. There is an interesting guide by Beej on understanding the IPC mechanisms which is included in the code sample below...
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(void)
{
pid_t pid;
int rv;
FILE *ping;
char buf[2000];
switch(pid = fork()) {
case -1:
perror("fork"); /* something went wrong */
exit(1); /* parent exits */
case 0:
// We're the child
ping = popen("ping google.com", "r");
if (ping != NULL){
fgets(buf, sizeof(buf), ping);
pclose(ping);
rv = 0;
}else{
perror("popen failed");
rv = -1;
}
exit(rv);
default:
// We're the parent...
wait(&rv);
}
// Now process the buffer
return 0;
}
Hope this helps,
Best regards,
Tom.
Edit On consideration, I believe that popen is the way to go with or without output from cmd.
Older
You are probably looking for something in the wait (2) family of commands plus a fork and exec.
From the manual page
The wait() function suspends execution of its calling process until
stat_loc information is available for a terminated child process, or a
signal is received. On return from a successful wait() call, the
stat_loc area contains termination information about the process that
exited as defined below.
Or if cmd returns some progress information you want popen (3) which is discussed in a number of existing SO questions; for instance How can I run an external program from C and parse its output?.
If you are on a unix system, you can start a command with an & to indicate that it runs in the background like this: myscript &
This will start a new process separate from the current program. You need to pick up the process number (hopefully from system, my c posix api knowledge is rusty) and then check up on it probably with a call to something like wait or waitpid with non-blocking turned on.
This is complicated for a beginner -- I'll let someone else post details if still interested.