Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breakpoint set on GUI does not work [Branch: debugger] #2578

Closed
Fare9 opened this issue Dec 22, 2020 · 1 comment
Closed

Breakpoint set on GUI does not work [Branch: debugger] #2578

Fare9 opened this issue Dec 22, 2020 · 1 comment

Comments

@Fare9
Copy link

Fare9 commented Dec 22, 2020

The breakpoints that are set in the listing view do not work/are not listed in gdb (but you can set them through gdb breakpoint command).

Steps to reproduce the behavior:

  1. Open a binary in debugger view.
  2. Add a breakpoint using the list view (press 'K' for software breakpoint).
  3. In GNU GDB view, write "info breakpoints" and no breakpoint from list view have been set.
  4. If you press "c" in order to continue the program, no stop will happen.

Expected Behavior:
If a breakpoint is set on list view, the breakpoint should be generated in the engine used (gdb, windbg, etc).

If applicable, add screenshots to help explain your problem.

imagen
In the image appears one breakpoints (using info breakpoints) that was added using gdb command "breakpoint", but the one on the list view (address 00401149) is not in the list of breakpoints from GDB.

  • OS: Ubuntu 20.04.1 LTS.
  • Java Version: openjdk 11.0.9.1 2020-11-04
  • Ghidra Version: Ghidra 9.3 Build Dev (Debugger branch)
@nsadeveloper789
Copy link
Contributor

There are a few things that have to happen before breakpoints are effective. The best way to verify those dependencies have been met is to verify that your dynamic and static listings are synchronized. The static one is just your standard Ghidra Listing window. It displays disassembly from your imported binary. The dynamic one was introduced with the debugger and resembles the standard listing, but displays memory and disassembly from the actual target. You must be recording into a trace for this view to be active. Clicking (or otherwise navigating) within one listing should navigate the other to the corresponding location. If not, then something has gone wrong:

  1. Verify you're recording. In the Threads view, you should see a tab row at the top, with the current trace listed. If not, right-click the inferior (probably [2]) in the Objects window and select "Record." If your listings are synced, you can skip ahead.
  2. Verify your module is mapped. If your listings are synced, your module is mapped. If not, find your module in the "Modules" window, right-click and select "Map Module to ." This should compute and propose a relocation offset where Ghidra believes the module is mapped into the trace. Confirm the dialog, and your listings should now be synced.

When synced:

The Breakpoints provider has two panes (please use F1 to read more in our help). The top pane are just those saved to program databases. The bottom are those locations actually present in a target. The static listing shows breakpoints from the top pane. The dynamic listing shows breakpoints from the bottom pane. You should only expect GDB to be synced with the bottom pane. Ghidra uses the module map to track which breakpoints from the top correspond to which breakpoints from the bottom. When Ghidra notices a breakpoint from the top ought to have a corresponding one from the bottom, it assigns it a "mixed enabled" icon. (Judging from your screenshot, where I see just plain "enabled," I suspect you're not recording, or the module mapping process has failed.) Use the "Toggle Breakpoint (K)" action, or click the icon in the "Breakpoints" view, to place the breakpoint on target.

Similarly, placing a breakpoint via the CLI should cause that breakpoint to appear in the bottom table (when you're recording). Ghidra will attempt to map that breakpoint to a static image and render it in the listing. An entry will appear in the top table, but it is not saved to the program until you Toggle it.

Reconciling "mixed enabled" states automatically is a known issue. For now, just be sure to toggle all your desired breakpoints immediately after launching (and recording).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants