Is there a way to store the output of the last command in gdb to a string? What I would like to do is store the address information of selected machine level instructions. Redirecting the output is not a solution as it would generate too much output. A simulator would also be a solution, but I'd like to see if it would be possible with gdb as I only want the analysis on a small chunk of code.
So I would need something like this:
(gdb) display/i $pc
(gdb) 1: x/i $pc 0x100000d2e <main+61>: jle 0x100000d02 <main+17
(gdb) set $foo = ??? somehow set this to display line 1
(gdb) call myFunc($foo)
(I excluded the looping controls to keep the example simple)
Or would there be another way of doing this?
Not possible as far as I know, which is kind of surprising considering all the Lisp background of the author :) You'd need either redirection (grep, sed, and awk make wonders on large files, and there's always perl), or your own instruction decoding based on $pc, which I assume is not an option.
Then I don't really understand what you are trying to do. Figure out jump targets? Relocation correctness? What is that you don't know about the code until the runtime? More details can probably point into better direction.
Edit:
Just some links - haven't tried it yet - you might want to play with script-extension setting and see if you can make Python command files work for you:
see Extending GDB and Python in GDB.
Related
I need to disassemble some C code, but I want to also show the source lines mixed in with the assembly code. The issue I have is that I'm using gdb through the MI interface, which calls disassemble (or equivalent, perhaps -data-disassemble?), and I have no control over the options sent with the command. If I did have access to the command, I could probably just use
-data-disassemble ... -- 1.
I've tried making a user-defined command, e.g.:
define dis
disassemble /s
end
but I don't know how to force using that command through gdb/mi. I also tried making an alias, but it creates a naming conflict ("Alias disassemble is the name of an existing command") and probably wouldn't work anyway because of the MI connection.
I'd like to just add a line to my .gdbinit file that forces the /s option to be a default for disassemble, but I can't find any documentation that shows how this can be done.
As a side note, I'm trying to accomplish this in MSVC 2019, and I can sort of do it manually using the instructions from Microsoft's MIEngine custom command doc. But this doesn't go through the usual gdb/mi interface, and just dumps text into the Command Window. I was able to set disassembly-flavor intel, which works in changing the assembly into Intel format, so it seems like what I want to accomplish is at least plausible.
I would like to write a bat script which call gdb. I want to use script variables in debugging session (like paths, variable names etc.) For example name and location of the config, address ranges to dump or even command.
Is there easy way to do that? I know that there are gdb scripts but I'm not sure how to do that in easy way.
I see that I can access to script variables with "environment" specifier but I can't use it in other way than show and modify this data.
Without considering the sense of this example I would like to have behavior like below.
Bat script:
SET MY_COMMAND=run
SET MY_COMMAND2=quit
SET MY_FUNCTION=main
:: GDB CALL ??
And expected gdb behavior:
break MY_FUNCTION
MY_COMMAND
MY_COMMAND2
Maybe this will be solution for you:
~/.gdbinit
You can put gdb commands there, and whenever gdb is started it will execute them.
Well, in fact, in your case it would be easier to use another approach:
--command=FILE
Seems they all print out information about what's the current call frame is, and 'i frame' seems to give a bit more information. But I don't really see the necessity of 'where' command. Is there anything that 'where' command can do while 'bt' or 'i frame' cannot do?
Thanks!
where and bt are exact synonyms and produce exact same output. From the manual:
The names where and info stack (abbreviated info s) are additional
aliases for backtrace.
info frame is totally different: it describes current frame, not the call stack.
I don't really see the necessity of 'where' command
It's there to make life easier for people who first used another debugger (e.g. dbx).
The reason why I'm asking this, is because I'm coding in C++, in putty/ssh and I like the fact that I can code from pretty much everywhere without having to install anything.
So I'd like to have something that could help me debugging (viewing LIVE value of a variable, breakpoints, etc)
If you think that there's no such thing in this world, is there any good technique I could use to debug in command line?
Thanks
I've used gdb for command line debugging in the past with success:
http://www.gnu.org/software/gdb/
A decent tutorial can be found at:
http://www.cs.cmu.edu/~gilpin/tutorial/
vimgdb will give what you want. I've used it for about one year. The most interesting feature is:
Hightlight current line
List item
Can show disassembly code
Step into, Step over
inspect variables, memory address
Run all the underlying gdb command is possible
And, of course, set breakpoint, conditional breakpoint etc.
Highly customizable by vim key mapping and scripts.
Actually I use checkinstall to make an rpm for it, and installed it everywhere when I need to debug on the box.
I think it have the most important features I want from a visual debugger.
Have you tried gdb ? That's pretty much the command line debugger, but it's no vim plugin.
You have a script to do that: http://www.vim.org/scripts/script.php?script_id=1954
In my humble opinion, Vim is not designed to do such things and it is a bad idea to do so.
GDB, at least as it's configured by default on my Ubuntu 9.04 box, doesn't handle multi-line statements well. When I'm stepping through code, GDB only displays the last line of the current statement, even if that statement spans multiple lines.
I'm aware that I could use DDD or emacs as a frontend for GDB, but I'd prefer to solve this problem within GDB, if that's possible.
Does anyone know if there's a way to get GDB to do the right thing here?
How about running GDB with the text user interface?
gdb -tui
It makes a world of difference to the ease of use of GDB.
I'm afraid the answer is "no, there is no way to get gdb to do what you want".
The line info in the symbol tables associates each code instruction with a single
source line (not a source statement). gdb has no way of knowing that several
source lines are associated with the same source statement.