As I have learnt that a Perl debugger can be controlled dynamically using the file .perldb in your home directory, I was wondering if there is a C debugger also which can be manipulated in the same way. So I could set breakpoints at a certain point and print some variables and so on.
You can set breakpoints and print values in GDB via commands in ~/.gdbinit, yes.
Related
This is related to u-boot.
I looked at this link (How to test the return of a command in U-Boot CLI) but it doesn't cover what I need. I also checked some other pages related to the 'test' command in u-boot but I can't figure out how to do what I would like. So there it is.
I have a u-boot command on a SBC which returns a set of information as text printed on the screen, where some part are strings representing versions. What I would like is to check whether the command return contains some specific strings to choose automatically what to do.
I have seen a few 'test' command help, but I couldn't figure out how to do this type of check on the text returned by this command. My goal is to have a set of nested ifs to choose in the different cases, or anything equivalent. If regex can be used, they perhaps could be helpful.
Does anybody know how to do this?
Thank you.
In U-Boot's hush shell there is no support for pipes. There is also no command like grep. So there are no means to succeed via U-Boot's built-in shell commands.
If you have access to the source of the command that you are executing, you could change it and use function env_set() to write the relevant data to environment variables and then use test for your purposes.
When I run gdb, there seems to be a notion of a main file, as if I set a breakpoint with just a number, it will get set for the source file that contains the main function.
How can I reconfigure gdb to set this to the file containing a function named my_main? (My actual main is provided by my library, in 99.9% of cases I want to focus on the the wrapped and prefixed main that the actual, library-provided, main calls).
GDB isn't doing what you say. When you say break LINE it sets a breakpoint in the "current" file, as per the docs:
The current source file is the last file whose source text was printed.
So perhaps what you want is to always set a breakpoint in my_main. If it helps you can make GDB let you up-arrow or Ctrl-R search backward through commands entered in previous sessions by following the instructions here: How can I make gdb save the command history?
You can set a breakpoint using directly function name: break my_main or you can specify filename and line: break file.c:100
I am not an experienced programmer but I recently have to check C code translated from Matlab, in order to ensure that with the same data set, C and Matlab are giving the identical results.
Watches are what I am able to use until now but that requires me to sit in front of the screen and watch the values of a variable change at each loop. Is there a way to trace and log the values of a variable into a .txt file so that I can plot it later to compare with the results from Matlab?
I have already tried to write the values into some .txt file with 'fwrite' but there is not the ideal solution as I have to do that in the C code that I want to check. Embarrassed I am currently reading about tracepoint of gdb and will try to use that but I am still unsure if that is what I need. If you have some tips about what else I try.
I´m using Windows 7 and work with CodeBlocks.
Thanks!
Christina
You can set a breakpoint command to run when your watchpoint hits; have it log and execute a continue command to let the program keep running.
How do you extract data from gdb so you can examine it in another program?
I am using gdb to debug a program. To see what is in array udata, I have created a source file called printudata with the following contents:
print udata[0]
print udata[1]
print udata[2]
...
print udata[143]
From within gdb I can execute that using source command and get output like this:
(gdb) source printudata
$399 = 1
$400 = 2.5
$401 = .3-10
...
$542 = <number>
So far, that is the best I can do for examining memory.
The only thing I can think of to do with this is (learn regular expressions and) strip off everything up to the equal sign so I can paste this into a spreadsheet which will tell me whether it's correct.
Is this the really the best way to get output from gdb? I am learning all this on my own and only have the basic, free tools that come with Linux (and am a beginner with all the above listed technologies)
You can print an array if it is really an array like this:
p udata
But, if udata is really a pointer, then you can use a cast to make gdb print it like an array.
p *(double(*)[144])udata
If you really want the line at a time output of your current "script", you can define a function and use a loop:
define print_udata
set $i=0
while ($i < 144)
p udata[$i]
set $i=$i+1
end
end
To log the output to a file, you can enable/disable logging:
set logging on
...gdb commands...
set logging off
The output will be in a file called gdb.txt.
In addition to the above, gdb has the "output" and "printf" commands. These don't enter the value into the value history, and they let you control the output much more precisely.
gdb has built-in scripting in both its own scripting language and in python. You can even script GDB from within a python program. You can use any of those options to write the data to a file.
More information about python & gdb here.
I created a little mini shell and it let's the user enter a command like 'ls' and it will list the contents of the directory like it's supposed to using execv() in my code, but that doesn't seem to work for when the user enters something like 'set name="bob"'. I've been looking all over the place for what I should use in my code to execute a set command when the user enters it and the best I can find is system(), but that still isn't working for me. Any ideas?
set is a shell-builtin command, not an external command (indeed it needs to be to have the intended effect, which is to modify a shell variable within the shell process itself).
This means that you need to look for and handle set within your shell itself, by adding the named variable to some internal data structure that tracks shell variables (or updating it if it already exists there).
Since you're doing a fork-and-exec or a system(), the command is really being run in a separate process. What happens in that process (like setting an environment variable) does not affect the parent's environment. (A separate issue is that set doesn't actually create an environment variable. You'd need export in [ba]sh or setenv in [t]csh to do that.)
So you need to code your mini-shell to handle the set command explicitly, rather than passing it off to another program.
You might want to look at setenv(3) and getenv(3). These are functions for changing and reading environment variables from within a C program.