How to view the stack

[astrelsky]

I would like to view the contents of the stack when stopped at a breakpoint so I can see the arguments passed to a function. The "stack" window just shows a few levels, pc and a function name and doesn't show the stack. Attempting to navigate to *:4 esp goes to the address of the pointer on the stack (ie ghidra can read the stack memory) but attempting to go to esp or rsp results in "address not in trace".

It would be handy to be able to view the stack contents in a window.

[d-millar]

@astrelsky We have a ticket in for this, but it has been the subject of some debate. For many targets, walking/recording the entire stack on every step is pretty expensive and slows stepping to a crawl, so it would be better if it were optional. FYI, you should be able to open the stack in the Objects window and retrieve the entire stack and/or pull it up in the Interpreter (although obviously that doesn't currently support easy navigation). Which agent are you using (e.g. gdb, dbgeng....)?

[astrelsky]

Dbeng. To clarify I'm not looking to record the stack, it should be treated the same as memory. I just want an easy way to look at it as there currently appears to be no way to do so.

I did not see the stack in the objects view, I will look again.

Edit: there must have been something off about that session earlier this morning. I just ran it again and was able to navigate to the stack in the dynamic listing.

[d-millar]

Ok, well that's pretty straightforward: in Objects, open Debugger->Sessions[x]->Processes[y]->Threads[z]->Stack -- should give you what you want. Open any given frame, and it should have Frame, Instruction, Return, and Stack offsets. Double-clicking any of these or hitting G (fo GoTo) when they're selected should navigate to that address. Anything in any other window is recorded by default, which is why the Stack Viewer only shows modifications to the stack.

[astrelsky]

Doh, I was probably looking in the wrong place. For some reason I didn't even think to look under the thread even though it makes sense since the stack is local to each thread.

[astrelsky]

Ok, well that's pretty straightforward: in Objects, open Debugger->Sessions[x]->Processes[y]->Threads[z]->Stack -- should give you what you want. Open any given frame, and it should have Frame, Instruction, Return, and Stack offsets. Double-clicking any of these or hitting G (fo GoTo) when they're selected should navigate to that address. Anything in any other window is recorded by default, which is why the Stack Viewer only shows modifications to the stack.

The stack viewer only shows Level, PC, Function and Comment. It would be nice to have the stack offset added to that window so it can be accessed easily.

Also I'm currently 2 for 4 with the stack being accessible in the trace.

Just noticed that ctrl+z doesn't undo markup in the dynamic listing.

[d-millar]

Re stack offset, don't object in principle to the idea, but it would be work, i.e. that info is not available by default for other platforms. So, we would have to either implement that functionailty for gdb, lldb, etc. or leave it missing for everything but windows. Will raise it as a possibility, though.

What do you mean by being "2 for 4" re trace?

[astrelsky]

Re stack offset, don't object in principle to the idea, but it would be work, i.e. that info is not available by default for other platforms. So, we would have to either implement that functionailty for gdb, lldb, etc. or leave it missing for everything but windows. Will raise it as a possibility, though.

What do you mean by being "2 for 4" re trace?

The address of the stack was only available in 2 out of 4 debugging sessions. The other two times I got "address not in trace" and had to disconnect and restart the debugging session.

[d-millar]

Ah - not sure why those addresses are not in the trace, but you can force all of memory in from the Regions view. Then every address should be navigable. (This is only a truly bad idea on embedded devices where navigating to unreadable memory would kill the device.)