dolphin/Source/Core/DolphinQt/Debugger/BreakpointWidget.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

78 lines
1.8 KiB
C
Raw Permalink Normal View History

// Copyright 2017 Dolphin Emulator Project
// SPDX-License-Identifier: GPL-2.0-or-later
#pragma once
#include <optional>
#include <QDockWidget>
#include <QString>
#include "Common/CommonTypes.h"
class QAction;
class QCloseEvent;
class QPoint;
class QShowEvent;
class QTableWidget;
class QTableWidgetItem;
class QToolBar;
class QWidget;
namespace Core
{
class System;
}
class CustomDelegate;
class BreakpointWidget : public QDockWidget
{
Q_OBJECT
public:
explicit BreakpointWidget(QWidget* parent = nullptr);
~BreakpointWidget();
void AddBP(u32 addr);
Debugger: Rework temporary breakpoints Before: 1. In theory there could be multiple, but in practice they were (manually) cleared before creating one 2. (Some of) the conditions to clear one were either to reach it, to create a new one (due to the point above), or to step. This created weird behavior: let's say you Step Over a `bl` (thus creating a temporary breakpoint on `pc+4`), and you reached a regular breakpoint inside the `bl`. The temporary one would still be there: if you resumed, the emulation would still stop there, as a sort of Step Out. But, if before resuming, you made a Step, then it wouldn't do that. 3. The breakpoint widget had no idea concept of them, and will treat them as regular breakpoints. Also, they'll be shown only when the widget is updated in some other way, leading to more confusion. 4. Because only one breakpoint could exist per address, the creation of a temporary breakpoint on a top of a regular one would delete it and inherit its properties (e.g. being log-only). This could happen, for instance, if you Stepped Over a `bl` specifically, and pc+4 had a regular breakpoint. Now there can only be one temporary breakpoint, which is automatically cleared whenever emulation is paused. So, removing some manual clearing from 1., and removing the weird behavior of 2. As it is stored in a separate variable, it won't be seen at all depending on the function used (fixing 3., and removing some checks in other places), and it won't replace a regular breakpoint, instead simply having priority (fixing 4.).
2024-06-15 09:36:38 +00:00
void AddBP(u32 addr, bool break_on_hit, bool log_on_hit, const QString& condition);
void AddAddressMBP(u32 addr, bool on_read = true, bool on_write = true, bool do_log = true,
bool do_break = true, const QString& condition = {});
void AddRangedMBP(u32 from, u32 to, bool do_read = true, bool do_write = true, bool do_log = true,
bool do_break = true, const QString& condition = {});
void UpdateButtonsEnabled();
2018-02-14 22:25:01 +00:00
void Update();
2018-03-16 11:39:53 +00:00
signals:
void ShowCode(u32 address);
void ShowMemory(u32 address);
2018-03-16 11:39:53 +00:00
protected:
void closeEvent(QCloseEvent*) override;
void showEvent(QShowEvent* event) override;
private:
void CreateWidgets();
void EditBreakpoint(u32 address, int edit, std::optional<QString> = std::nullopt);
void EditMBP(u32 address, int edit, std::optional<QString> = std::nullopt);
void OnClear();
void OnClicked(QTableWidgetItem* item);
void OnNewBreakpoint();
void OnEditBreakpoint(u32 address, bool is_instruction_bp);
void OnLoad();
void OnSave();
void OnContextMenu(const QPoint& pos);
void OnItemChanged(QTableWidgetItem* item);
2018-04-11 21:43:47 +00:00
void UpdateIcons();
Core::System& m_system;
QToolBar* m_toolbar;
QTableWidget* m_table;
2018-04-11 21:43:47 +00:00
QAction* m_new;
QAction* m_clear;
QAction* m_load;
QAction* m_save;
};