I would like to set multiple breakpoints at once in different files in GDB.
Is it possible to have a script or any other way which I can run once I enter GDB debugger and have all the breakpoints set instead of setting them one by one using traditional set break command.
All the resources I searched pointed to how to set breakpoints effectively. But, nothing seems to address my concern.
You can use the source command in gdb.
You can also put the commands in the .gdbinit file which will be sourced when you start gdb. Put the commands there and they will be run without doing anything more.
Related
So I've been writing a program in C and debugging to solve the problems I had. After I solved those problems, I could not watch the values of the variables since debugging session just quits because there are no errors or breakpoints after I solved the problems occurred previously.
My editor is Visual Studio Code, running it on macOS, GCC.
You should basicely put breakpoints at the end of your code, for example on the return line.
If you just want to know which values your variables have at the end of the execution, you can put printf("%x", your_variable); //DEBUG for the variables you want to see, and remove these lines when you finished debugging.
Moreover, if you're familiar with prompt commands, I recommand you to install gdb, this debugger is very powerful and easy to use ! Here is a little tutorial if you're interested ;)
Set your breakpoint on the code then press F5 to run the app in VSCode. Once the breakpoint hit, you can see local variables by selecting Run and Debug button (Red). You alse can add variables into Watch...
I am attempting to build a custom lookup in exim, I have followed the docs and good the groundwork in place so my additional code is being compiled and hooked in, as well as being called. I am using the Makefile included with Exim to perform the build and I have added in CFLAGS=-g -O0 to ensure I have debugging symbols.
Codeblocks, gcc, gdb and the source all live on my Linux box, which I am SSHing into and exporting the X session to my Windows desktop using XMing, I don't think this has any baring on the problem, but worth mentioning.
Now, my problem is that when I run debugger with breakpoints in, C::B seems to be not setting or gdb is ignoring breakpoints in my code, but is hitting ones I have in the main function (I added one at exit so I could read the execution output and to prove they were working).
I have confirmed my code is actually being called, it currently spits out an error message, which it is doing. If I add a breakpoint on that line, it doesn't fire, nor if it's on the function or first line of the function.
What is even stranger (to me), is that previously it was working! it only stopped working when I resized the bottom C::B pane which caused a portion of the screen to not render (I think this is a problem with C::B and XMing, sometimes I just get a grey blank window and need to stop and restart C::B). So I quit C::B, restarted it, reloaded my project and since then break points in my code simply do not work, even though I can prove the code is being executed.
Also if I manually add the breakpoint it works as expected. I set a breakpoint in C::B at the start of main. Hit debug and then sent b mddfind_open (name of my function) into gdb and hit continue.. C::B stops again at the start of that function. Possibly some weirdness with how C::B is passing the breakpoints to gdb?
UPDATE:
The project I am working on is Exim, which links the code into the build directory (due to some bug with gcc 2.92.x and extern's IIRC). If I open the file from that location in C::B and set a breakpoint it works as expected. I suspect that C::B is possibly passing incorrect references to gdb?
Any ideas?
It would seem that in this situation I need to specify the source path for the source file in question, even though it is within the root source path.
Originally I had my GDB source path set to:
/home/graeme/exim/src
The code in question lives in src/lookups, so adding that path too fixes the problem
/home/graeme/exim/src
/home/graeme/exim/src/lookups
I believe this situation has arisen as the code I am building is initially compiled into a static library, this library is then linked into the main program itself. As such symbols reference the source for the library source files located at the point the library was compiled. So in this case there are multiple packages being built, and I needed to reference each of them in the source paths.
I have a custom board running Yocto (Jethro) and would like to run a single u-boot command, preboot. Obviously, breaking the boot sequence with space and running it manually works. How do I get it to run automatically? More specifically, where is the startup command sequence, by default?
Edit: Also, I am aware I can edit the environment at runtime. However, I am trying to build this change into the image so I can distribute it.
When you are in the uboot environment. Enter printenv, it will list the environment variables that uboot uses.
There is a variable name bootcmd. Currently, mine contain a bunch of if else command. Similarly, add your prefer function there for boot.
And after it is finished and tested. Use saveenv to store the edit
Here is a syntax for uboot.
Edit:
U-Boot allows to store commands or command sequences in a plain text file. Using the mkimage tool you can then convert this file into a script image which can be executed using U-Boot's autoscr command. U-boot Scripting Capabilities
Typically, your U-Boot recipe will build U-Boot for a single machine, in that case, I'd normally just patch the compiled in, default, U-Boot environment to do the right thing. This is achieved by
SRC_URI_machine += "file://mydefenv.patch"
Or (even better) use your own git tree. This would also have the additional benefit that your system might be able to boot up and to something useful, even if the environment would be totally corrupted.
Another possibility is to do it like Charles suggested in a comment to another answer, create an environment offline, and have U-Boot load it, see denx.de/wiki/view/DULG/UBootScripts
A third possibility, that I've also used sometimes, is to construct the environment offline (possibly using the same or a similar mechanism as in the link above), and the flash the environment to flash during the normal flash programming process. Though, most of the time I've done this on AT91's, using a tcl script similar to at91 Sam-Ba TCL script
No matter which method you chose, the bootcmd variable in U-Boot should hold your boot script.
The general answer is that bootcmd is run by default, and if there is persistent environment you can change the command and 'saveenv' so that it's kept.
It is easiest to modify the said bootcmd, which is executed anyway.
As an alternative to patching the kernel, it is possible to override the command in u-boot.
Create a file e.g. platform-top.h at the same place where you would place the patch file (it might already exist) and override the CONFIG_BOOTCOMMAND.
The result will look something like this:
/* ... */
/* replace the memory write with any other valid command */
#define CONFIG_BOOTCOMMAND "mw 0x1 0x1 && run default_bootcommand"
Don't forget to make the file known in your bbapend SRC_URI = "file://platform-top.h"
I'm trying to debug for the first time a gtk code and actually, I want to debug a callback function for key-press-event so I set a breakpoint with gdb and when it hits the breakpoint, the whole desktop evirement is freezing (I'm running under gnome-shell) it seems that the graphic envirement is waiting for the event to finish.
I got some idea that didn't worked :
The first attempts was to assign some gdb commands to the breakpoint :
(gdb) break on_key_press_callback
(gdb) commands
> back trace
> next
> next
> next
> continue
> end
but I don't know why, only the back trace command is executed, and then freeze.
The second attempt was to debug remotely using gdbserver and gdb on tty1 (no graphigs to freeze :) ) I was able to send commands like next and step after the breakpoint but there was nothing to see (can't list code, inspect the stack, ect ...)
So any good tips to be able to debug in such situations ?
Thanks
It's typical to have lockups when debugging an X program running on the same server that you're using to debug. For example, if the inferior (gdb terminology for the program being debugged) does a server grab -- whoops, the gdb GUI (or terminal or emacs etc) is locked out.
Your idea of doing more programmatic debugging is a good one, but it's hard to make it all work nicely. As you found, some gdb commands (basically those related to inferior control) don't work in commands. Also, it just isn't nearly as convenient.
You can go further that direction. For example you could use SystemTap to probe the program instead.
However there are also nicer approaches.
One way is to run the inferior using a virtual X server -- a nested one, or one running in a VM. Then you can escape to the "outer" X server for debugging. This will be much nicer.
Another way is to have two computers, and run the debugger on one and the inferior on the other. In a way this is really the same answer, just using a real machine rather than a virtual one.
The question is old, but for anyone that may be struggling with this issue, there is a way to stop the freezing behaviour from happening by disabling the X server grab.
You have to change the config in your IDE to run the program with the following system property:
-Dsun.awt.disablegrab=true
If you are using javaws (Java Web Start) to run the application use:
-J-Dsun.awt.disablegrab=true
instead.
I want to debug an application with lldb. At the beginning, I want to set a few breakpoints with a set of commands. I'm aware of the -s option, but this somehow doesn't let me interactively debug the application after executing the commands in the file. Essentially I want to replicate the behavior of gdb. How do I do this?
There is a bug in the way the lldb command parser sources command files, where it doesn't recognize that a command like "breakpoint command add" has switched to a new "input parser" (the one that reads and stashes away the commands but doesn't execute them, and then waits for the DONE to exit.) The effect of this is that, if you do:
breakpoint command add
some command
some other command
DONE
the input gets all messed up and things go poorly, as you have seen. This bug is actually fixed in TOT lldb, though that hasn't made it to an official Xcode release yet.
In the meantime, there aren't any great workarounds for this. If your breakpoint commands are simple, you can use the --one-liner option to specify them without switching to the breakpoint input parser. Or, if you know a little Python you can make Python function breakpoint commands, import them with "script import" and tie them to the breakpoint with the -F option.