Right now I've been using GDB to disassemble a binary file and check out different registers and whatnot. Is there an easy command to examine everything on the stack? Can this be limited to everything in a function?
You can view the contents of the stack with x/10x $sp
This will print the top 10 elements of the stack.
For the current stack frame:
info frame lists general info about the frame (where things start in memory, etc.)
info args lists arguments to the function
info locals lists local variables stored in the frame
bt (or backtrace) will give you a call stack.
frame <args> will select a frame on the call stack for inspection
info frame <args> will give you information about a specific frame from the stack. When called without arguments it will display the currently selected frame
info locals can give you information about any local variables on the stack.
just try bt full, and you will get all frames and locals
input frame x, to enter the x frame
by the way, you should know about process address space and what it is composed:
linux virtual address space, this will help you understand how the frame is used.
Related
I have what I think is a stack corruption.
I have an stack variable (a pointer ) in the position:
0x7000C0E4 ; the normal information stored is 0x700022A5
I know that from time to time some unexpected code trashes the high part of the word getting one of these values:
0x000022A5 or 0x005122A5; I guess is a 16 bits write operation.
I'd like to set a breakpoint to stop when someone writes in that address but only when after the write the content of the stack address is 0x000022A5 or 0x005122A5
I guess I need two conditional breakpoints.
Anyone knows idf this is possible and the syntax to setup such breakpoints.
After #Holger comments I've setup what I think is the conditional breakpoint I need. But it does not work as expected. See he attached picture. Let me recall:
I know someone is corruption the 0x7000c0de position, writing a 0x0000 instead of the expected value 0x7000. I use that as a pointer and the resulted pointer is 0x000022A5 instead of the expected 0x700022A5. I've setup 2 breakpoints , one at the trap function (I fall here after trying to access to the bad address) and a conditional Write breakpoint which should stop only when some writes the 0x0000 and additionaly the 0x7000c0dc address content is 0x000022A5. As you see in the picture my debugger stops only in the TRap function and at that moment the content of the 0x7000c0dc is effectively 0x000022A5. So why this conditional breakpoint is not working?
This should be done with data breakpoints.
The command in TRACE32 for data breakpoints is this one:
Break.Set <address> /Write /Data.<width> <value>
In your particular case you'll need two data-breakpoints. E.g. like this:
Break.Set 0x7000C0E6 /Write /Data.Word 0x0000
Break.Set 0x7000C0E6 /Write /Data.Word 0x0051
This will only work if your CPU supports data breakpoints and if the change on the stack was actually done by the CPU. It will not stop if the memory was altered by DMA or a peripheral hardware component or so.
If your CPU does not support data breakpoints TRACE32 will emulate the data breakpoints in a way that it will actually stop every time data is written to the given address, but immediately restart the CPU if the written data does not match.
Is there a way to attach a print statement to the call of a function? I would like to debug a x64 program with nested loops and logic and it would be faster to see the sequence of function calls by printing them as they occur, rather than setting breakpoints.
Can this be done with a post hook in gdb or a different technique?
Is there a way to attach a print statement to the call of a function?
Yes: attach a breakpoint to every function you want to trace, and attach commands to each of these breakpoints:
(gdb) break foo
(gdb) commands $bpnum
continue
end
Now every time foo is called, GDB will print the usual "Breakpoint N ..." message, and then continue.
Obviously you could print additional info (argument values, call stack, thread-id, etc.).
You will probably want to set height 0 to disable pagination. You will also probably want to log this to a file (see set logging file, set logging on, etc.)
I have been trying to find a memory leak in a server. I leave it running and use top command to inspect the VIRT memory size field on it's PID while I connect clients to it. I notice that every time I run something which connects to the server the field increases by about 5 MB suggesting there is a leak somewhere. I want to set a breakpoint in gdb on any call to operator new and connect a client to see if i see any calls to new from an unexpected backtrace that I haven't already correctly inspected for a corresponding delete. How does one set such a breakpoint?
I am on linux btw.
I currently have a 1028*32 byte array of structures in shared memory using boost::interprocess. Each of these contains location and drawing information from players in a game that I am scraping from a DLL to be drawn in a remote overlay. My basic mechanism of controlling reading and writing is a bool at the beginning of the shared memory object that each process toggles on and off. This method works, and I can get information from each of the players ingame, but unfortunately this method is really slow. Is there any way to transfer this information quicker? If at all possible, I would like to have it so that I can call my drawing function once a particular member of the array gets updated (say member 0 gets updated, before my scraper dll updates the next member, start drawing the info of member 0, then continue).
Well, you could a have a flag per member and continuously process the array and check for newly set flags. If you need more event style notifications then you could have a monitor for each individual member and signal it once it got updated. I'm not sure how the performance will be affected by having a 1000 monitors though.
In gdb, after reaching a breakpoint, I want to list all the variables in the current context, instead of giving each variable name explicitly? Is there any way to achieve this at all?
You want info locals. Or, if you are getting a back trace, bt full.
You can attach info locals to a breakpoint with the commands command.