From 1a09a5cbe781ba423f94e1f3b3528263cc8b610b Mon Sep 17 00:00:00 2001 From: John Helmert III Date: Sun, 10 Mar 2024 09:47:53 -0700 Subject: [PATCH 1/5] ProcessesWidget: make ColumnIndex a class member The same name with a differing definition clashes with ColumnIndex from ThreadsWidget, which violates C++ ODR (-Werror=odr). This brings ProcessesWidget in line with other widgets that define the column index enums within their respective classes. Signed-off-by: John Helmert III --- src/widgets/ProcessesWidget.cpp | 31 ++++++++++++++----------------- src/widgets/ProcessesWidget.h | 7 +++++++ 2 files changed, 21 insertions(+), 17 deletions(-) diff --git a/src/widgets/ProcessesWidget.cpp b/src/widgets/ProcessesWidget.cpp index 2a9477f8f4..0a45a98e55 100644 --- a/src/widgets/ProcessesWidget.cpp +++ b/src/widgets/ProcessesWidget.cpp @@ -9,13 +9,6 @@ #define DEBUGGED_PID (-1) -enum ColumnIndex { - COLUMN_PID = 0, - COLUMN_UID, - COLUMN_STATUS, - COLUMN_PATH, -}; - ProcessesWidget::ProcessesWidget(MainWindow *main) : CutterDockWidget(main), ui(new Ui::ProcessesWidget) { @@ -23,10 +16,14 @@ ProcessesWidget::ProcessesWidget(MainWindow *main) // Setup processes model modelProcesses = new QStandardItemModel(1, 4, this); - modelProcesses->setHorizontalHeaderItem(COLUMN_PID, new QStandardItem(tr("PID"))); - modelProcesses->setHorizontalHeaderItem(COLUMN_UID, new QStandardItem(tr("UID"))); - modelProcesses->setHorizontalHeaderItem(COLUMN_STATUS, new QStandardItem(tr("Status"))); - modelProcesses->setHorizontalHeaderItem(COLUMN_PATH, new QStandardItem(tr("Path"))); + modelProcesses->setHorizontalHeaderItem(ProcessesWidget::COLUMN_PID, + new QStandardItem(tr("PID"))); + modelProcesses->setHorizontalHeaderItem(ProcessesWidget::COLUMN_UID, + new QStandardItem(tr("UID"))); + modelProcesses->setHorizontalHeaderItem(ProcessesWidget::COLUMN_STATUS, + new QStandardItem(tr("Status"))); + modelProcesses->setHorizontalHeaderItem(ProcessesWidget::COLUMN_PATH, + new QStandardItem(tr("Path"))); ui->viewProcesses->horizontalHeader()->setDefaultAlignment(Qt::AlignLeft | Qt::AlignVCenter); ui->viewProcesses->verticalHeader()->setVisible(false); ui->viewProcesses->setFont(Config()->getFont()); @@ -129,10 +126,10 @@ void ProcessesWidget::setProcessesGrid() rowStatus->setFont(font); rowPath->setFont(font); - modelProcesses->setItem(i, COLUMN_PID, rowPid); - modelProcesses->setItem(i, COLUMN_UID, rowUid); - modelProcesses->setItem(i, COLUMN_STATUS, rowStatus); - modelProcesses->setItem(i, COLUMN_PATH, rowPath); + modelProcesses->setItem(i, ProcessesWidget::COLUMN_PID, rowPid); + modelProcesses->setItem(i, ProcessesWidget::COLUMN_UID, rowUid); + modelProcesses->setItem(i, ProcessesWidget::COLUMN_STATUS, rowStatus); + modelProcesses->setItem(i, ProcessesWidget::COLUMN_PATH, rowPath); i++; } @@ -155,7 +152,7 @@ void ProcessesWidget::onActivated(const QModelIndex &index) if (!index.isValid()) return; - int pid = modelFilter->data(index.sibling(index.row(), COLUMN_PID)).toInt(); + int pid = modelFilter->data(index.sibling(index.row(), ProcessesWidget::COLUMN_PID)).toInt(); // Verify that the selected pid is still in the processes list since dp= will // attach to any given id. If it isn't found simply update the UI. for (const auto &value : Core()->getAllProcesses()) { @@ -185,7 +182,7 @@ ProcessesFilterModel::ProcessesFilterModel(QObject *parent) : QSortFilterProxyMo bool ProcessesFilterModel::filterAcceptsRow(int row, const QModelIndex &parent) const { // All columns are checked for a match - for (int i = COLUMN_PID; i <= COLUMN_PATH; ++i) { + for (int i = ProcessesWidget::COLUMN_PID; i <= ProcessesWidget::COLUMN_PATH; ++i) { QModelIndex index = sourceModel()->index(row, i, parent); if (qhelpers::filterStringContains(sourceModel()->data(index).toString(), this)) { return true; diff --git a/src/widgets/ProcessesWidget.h b/src/widgets/ProcessesWidget.h index fcc9db8008..40f2f0f657 100644 --- a/src/widgets/ProcessesWidget.h +++ b/src/widgets/ProcessesWidget.h @@ -31,6 +31,13 @@ class ProcessesWidget : public CutterDockWidget Q_OBJECT public: + enum ColumnIndex { + COLUMN_PID = 0, + COLUMN_UID, + COLUMN_STATUS, + COLUMN_PATH, + }; + explicit ProcessesWidget(MainWindow *main); ~ProcessesWidget(); From 43950242aebd259c8f81a75d65aebb3cf9f1afde Mon Sep 17 00:00:00 2001 From: John Helmert III Date: Sun, 10 Mar 2024 09:47:53 -0700 Subject: [PATCH 2/5] ThreadsWidget: make ColumnIndex a class member This brings ThreadsWidget into alignment with ProcessesWidget and others which have column index enumerators as class members. This also avoids cluttering global scope with generic names, making it easier to avoid C++ ODR violations with differing definitions. Closes: #3316 Signed-off-by: John Helmert III --- src/widgets/ThreadsWidget.cpp | 24 ++++++++++-------------- src/widgets/ThreadsWidget.h | 6 ++++++ 2 files changed, 16 insertions(+), 14 deletions(-) diff --git a/src/widgets/ThreadsWidget.cpp b/src/widgets/ThreadsWidget.cpp index d9149108f9..8d47412888 100644 --- a/src/widgets/ThreadsWidget.cpp +++ b/src/widgets/ThreadsWidget.cpp @@ -9,21 +9,17 @@ #define DEBUGGED_PID (-1) -enum ColumnIndex { - COLUMN_PID = 0, - COLUMN_STATUS, - COLUMN_PATH, -}; - ThreadsWidget::ThreadsWidget(MainWindow *main) : CutterDockWidget(main), ui(new Ui::ThreadsWidget) { ui->setupUi(this); // Setup threads model modelThreads = new QStandardItemModel(1, 3, this); - modelThreads->setHorizontalHeaderItem(COLUMN_PID, new QStandardItem(tr("PID"))); - modelThreads->setHorizontalHeaderItem(COLUMN_STATUS, new QStandardItem(tr("Status"))); - modelThreads->setHorizontalHeaderItem(COLUMN_PATH, new QStandardItem(tr("Path"))); + modelThreads->setHorizontalHeaderItem(ThreadsWidget::COLUMN_PID, new QStandardItem(tr("PID"))); + modelThreads->setHorizontalHeaderItem(ThreadsWidget::COLUMN_STATUS, + new QStandardItem(tr("Status"))); + modelThreads->setHorizontalHeaderItem(ThreadsWidget::COLUMN_PATH, + new QStandardItem(tr("Path"))); ui->viewThreads->horizontalHeader()->setDefaultAlignment(Qt::AlignLeft | Qt::AlignVCenter); ui->viewThreads->verticalHeader()->setVisible(false); ui->viewThreads->setFont(Config()->getFont()); @@ -120,9 +116,9 @@ void ThreadsWidget::setThreadsGrid() rowStatus->setFont(font); QStandardItem *rowPath = new QStandardItem(path); rowPath->setFont(font); - modelThreads->setItem(i, COLUMN_PID, rowPid); - modelThreads->setItem(i, COLUMN_STATUS, rowStatus); - modelThreads->setItem(i, COLUMN_PATH, rowPath); + modelThreads->setItem(i, ThreadsWidget::COLUMN_PID, rowPid); + modelThreads->setItem(i, ThreadsWidget::COLUMN_STATUS, rowStatus); + modelThreads->setItem(i, ThreadsWidget::COLUMN_PATH, rowPath); i++; } @@ -146,7 +142,7 @@ void ThreadsWidget::onActivated(const QModelIndex &index) if (!index.isValid()) return; - int tid = modelFilter->data(index.sibling(index.row(), COLUMN_PID)).toInt(); + int tid = modelFilter->data(index.sibling(index.row(), ThreadsWidget::COLUMN_PID)).toInt(); // Verify that the selected tid is still in the threads list since dpt= will // attach to any given id. If it isn't found simply update the UI. @@ -169,7 +165,7 @@ ThreadsFilterModel::ThreadsFilterModel(QObject *parent) : QSortFilterProxyModel( bool ThreadsFilterModel::filterAcceptsRow(int row, const QModelIndex &parent) const { // All columns are checked for a match - for (int i = COLUMN_PID; i <= COLUMN_PATH; ++i) { + for (int i = ThreadsWidget::COLUMN_PID; i <= ThreadsWidget::COLUMN_PATH; ++i) { QModelIndex index = sourceModel()->index(row, i, parent); if (qhelpers::filterStringContains(sourceModel()->data(index).toString(), this)) { return true; diff --git a/src/widgets/ThreadsWidget.h b/src/widgets/ThreadsWidget.h index 259c919de2..fd452d1e19 100644 --- a/src/widgets/ThreadsWidget.h +++ b/src/widgets/ThreadsWidget.h @@ -31,6 +31,12 @@ class ThreadsWidget : public CutterDockWidget Q_OBJECT public: + enum ColumnIndex { + COLUMN_PID = 0, + COLUMN_STATUS, + COLUMN_PATH, + }; + explicit ThreadsWidget(MainWindow *main); ~ThreadsWidget(); From f8c7df8260bea74dabe45a7b961da339c277bd38 Mon Sep 17 00:00:00 2001 From: Anton Kochkov Date: Tue, 19 Mar 2024 17:51:58 +0800 Subject: [PATCH 3/5] Update Rizin to the latest `dev` (#3319) --- cmake/BundledRizin.cmake | 7 +++---- rizin | 2 +- src/core/Cutter.cpp | 10 ++++------ src/widgets/DisassemblerGraphView.cpp | 2 +- 4 files changed, 9 insertions(+), 12 deletions(-) diff --git a/cmake/BundledRizin.cmake b/cmake/BundledRizin.cmake index 1d6208b9a1..3e05b26304 100644 --- a/cmake/BundledRizin.cmake +++ b/cmake/BundledRizin.cmake @@ -59,10 +59,9 @@ endif() # instead of being hardcoded. set (Rizin_VERSION 0.8) -set (RZ_LIBS rz_core rz_config rz_cons rz_io rz_util rz_flag rz_asm rz_debug - rz_hash rz_bin rz_lang rz_il rz_analysis rz_parse rz_bp rz_egg rz_reg - rz_search rz_syscall rz_socket rz_magic rz_crypto rz_type rz_diff rz_sign - rz_demangler) +set (RZ_LIBS rz_core rz_config rz_cons rz_io rz_util rz_flag rz_arch rz_debug + rz_hash rz_bin rz_lang rz_il rz_bp rz_egg rz_reg rz_search rz_syscall + rz_socket rz_magic rz_crypto rz_type rz_diff rz_sign rz_demangler) set (RZ_EXTRA_LIBS rz_main) set (RZ_BIN rz-bin rizin rz-diff rz-find rz-gg rz-hash rz-run rz-asm rz-ax) diff --git a/rizin b/rizin index 4a0dca6613..94099b860e 160000 --- a/rizin +++ b/rizin @@ -1 +1 @@ -Subproject commit 4a0dca66131de65ca10679e42e3adb5d39735ffa +Subproject commit 94099b860e6ce712e337e9ee29d258d51ae32962 diff --git a/src/core/Cutter.cpp b/src/core/Cutter.cpp index 6951e01a02..0f646b810e 100644 --- a/src/core/Cutter.cpp +++ b/src/core/Cutter.cpp @@ -1295,7 +1295,7 @@ RVA CutterCore::getLastFunctionInstruction(RVA addr) if (!fcn) { return RVA_INVALID; } - RzAnalysisBlock *lastBB = (RzAnalysisBlock *)rz_list_last(fcn->bbs); + RzAnalysisBlock *lastBB = (RzAnalysisBlock *)rz_pvector_tail(fcn->bbs); return lastBB ? rz_analysis_block_get_op_addr(lastBB, lastBB->ninstr - 1) : RVA_INVALID; } @@ -1641,7 +1641,7 @@ QVector CutterCore::getHeapChunks(RVA arena_addr) rz_list_free(arenas); return chunks_vector; } - m_arena = ((RzArenaListItem *)rz_list_get_head_data(arenas))->addr; + m_arena = ((RzArenaListItem *)rz_list_first(arenas))->addr; rz_list_free(arenas); } else { m_arena = arena_addr; @@ -3061,7 +3061,7 @@ QList CutterCore::getAllFunctions() function.linearSize = rz_analysis_function_linear_size(fcn); function.nargs = rz_analysis_arg_count(fcn); function.nlocals = rz_analysis_var_local_count(fcn); - function.nbbs = rz_list_length(fcn->bbs); + function.nbbs = rz_pvector_len(fcn->bbs); function.calltype = fcn->cc ? QString::fromUtf8(fcn->cc) : QString(); function.name = fcn->name ? QString::fromUtf8(fcn->name) : QString(); function.edges = rz_analysis_function_count_edges(fcn, nullptr); @@ -4334,10 +4334,9 @@ QString CutterCore::getVersionInformation() const char *name; const char *(*callback)(); } vcs[] = { - { "rz_analysis", &rz_analysis_version }, + { "rz_arch", &rz_arch_version }, { "rz_lib", &rz_lib_version }, { "rz_egg", &rz_egg_version }, - { "rz_asm", &rz_asm_version }, { "rz_bin", &rz_bin_version }, { "rz_cons", &rz_cons_version }, { "rz_flag", &rz_flag_version }, @@ -4350,7 +4349,6 @@ QString CutterCore::getVersionInformation() #if !USE_LIB_MAGIC { "rz_magic", &rz_magic_version }, #endif - { "rz_parse", &rz_parse_version }, { "rz_reg", &rz_reg_version }, { "rz_sign", &rz_sign_version }, { "rz_search", &rz_search_version }, diff --git a/src/widgets/DisassemblerGraphView.cpp b/src/widgets/DisassemblerGraphView.cpp index 82da086613..a220188f61 100644 --- a/src/widgets/DisassemblerGraphView.cpp +++ b/src/widgets/DisassemblerGraphView.cpp @@ -225,7 +225,7 @@ void DisassemblerGraphView::loadCurrentGraph() return; } - for (const auto &bbi : CutterRzList(fcn->bbs)) { + for (const auto &bbi : CutterPVector(fcn->bbs)) { RVA bbiFail = bbi->fail; RVA bbiJump = bbi->jump; From 575013904100efdc71cbb9b614e4a1587f94ac7e Mon Sep 17 00:00:00 2001 From: Anton Kochkov Date: Tue, 2 Apr 2024 20:55:16 +0800 Subject: [PATCH 4/5] Update Rizin to the latest dev --- rizin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rizin b/rizin index 94099b860e..3d93397dd8 160000 --- a/rizin +++ b/rizin @@ -1 +1 @@ -Subproject commit 94099b860e6ce712e337e9ee29d258d51ae32962 +Subproject commit 3d93397dd8b96ce1e8683a21ab86d94812f0b23f From bce9fe7732890934f750d9d91f4093983dbb5830 Mon Sep 17 00:00:00 2001 From: Ofek Date: Mon, 8 Apr 2024 23:00:51 +0300 Subject: [PATCH 5/5] Update GraphGridLayout Documentation (#3325) --- src/widgets/GraphGridLayout.cpp | 162 ++++++++++++++++---------------- 1 file changed, 83 insertions(+), 79 deletions(-) diff --git a/src/widgets/GraphGridLayout.cpp b/src/widgets/GraphGridLayout.cpp index 0cf7840d90..51a5abca97 100644 --- a/src/widgets/GraphGridLayout.cpp +++ b/src/widgets/GraphGridLayout.cpp @@ -14,96 +14,97 @@ Basic familiarity with graph algorithms is recommended. # Terms used: -- **Vertex**, **node**, **block** - read description of graph for definition. Within this text -vertex and node are used interchangeably with block due to code being written for visualizing basic +- **Vertex**, **node**, **block** - see the definition of graph. Within this text +vertex/node/block are used interchangeably due to the code being purposed for visualizing basic block control flow graph. -- **edge** - read description of graph for definition for precise definition. -- **DAG** - directed acyclic graph, graph using directed edges which doesn't have cycles. DAG may -contain loops if following them would require going in both directions of edges. Example 1->2 1->3 -3->2 is a DAG, 2->1 1->3 3->2 isn't a DAG. +- **edge** - see the definition of graph. +- **DAG** - directed acyclic graph, a graph using directed edges which doesn't have cycles. A DAG +may contain loops if following them would require going in both directions of edges. Example 1->2 +1->3 3->2 is a DAG, 2->1 1->3 3->2 isn't a DAG. - **DFS** - depth first search, a graph traversal algorithm -- **toposort** - topological sorting, process of ordering a DAG vertices that all edges go from -vertices earlier in the toposort order to vertices later in toposort order. There are multiple -algorithms for implementing toposort operation. Single DAG can have multiple valid topological +- **toposort** - topological sorting, the process of ordering a DAG vertices that results in all +edges going from vertices earlier in the toposort order to vertices later in toposort order. There +are multiple algorithms implementing toposort. A single DAG can have multiple valid topological orderings, a toposort algorithm can be designed to prioritize a specific one from all valid toposort orders. Example: for graph 1->4, 2->1, 2->3, 3->4 valid topological orders are [2,1,3,4] and [2,3,1,4]. -# High level structure of the algorithm -1. select subset of edges that form a DAG (remove cycles) -2. toposort the DAG -3. choose a subset of edges that form a tree and assign layers -4. assign node positions within grid using tree structure, child subtrees are placed side by side +# High level algorithm structure +1. Select a subset of edges that form a DAG (remove cycles) +2. Toposort the DAG +3. Choose a subset of edges that form a tree and assign layers +4. Assign node positions within grid using tree structure, child subtrees are placed side by side with parent on top -5. perform edge routing -6. calculate column and row pixel positions based on node sizes and amount edges between the rows -7. [optional] layout compacting +5. Perform edge routing +6. Calculate column and row pixel positions based on node sizes and amount edges between the rows +7. [optional] Layout compacting -Contrary to many other layered graph drawing algorithm this implementation doesn't perform node -reordering to minimize edge crossing. This simplifies implementation, and preserves original control -flow structure for conditional jumps ( true jump on one side, false jump on other). Due to most of -control flow being result of structured programming constructs like if/then/else and loops, -resulting layout is usually readable without node reordering within layers. +Contrary to many other layered graph-drawing algorithms this implementation doesn't perform node +reordering to minimize edge crossing. This simplifies the implementation, and preserves the original +control-flow structure for conditional jumps ( true jump on one side, false jump on other). Due to +most of the control flow resulting from structured programming constructs like if/then/else and +loops, the resulting layout is usually readable without node reordering within layers. -# Description of grid. -To simplify the layout algorithm initial steps assume that all nodes have the same size and edges -are zero width. After placing the nodes and routing the edges it is known which nodes are in in -which row and column, how many edges are between each pair of rows. Using this information positions -are converted from the grid cells to pixel coordinates. Routing 0 width edges between rows can also +# Grid +To simplify the layout algorithm, its initial steps assume that all nodes have the same size and +that edges are zero-width. After nodes placement and edges rounting, the row/column of nodes is +known as well as the amount of edges between each pair of rows. Using this information, positions +are converted from grid cells to pixel coordinates. Routing zero-width edges between rows can also be interpreted as every second row and column being reserved for edges. The row numbers in code are -using first interpretation. To allow better centering of nodes one above other each node is 2 +using the first interpretation. To allow better centering of nodes one above other, each node is 2 columns wide and 1 row high. \image html graph_grid.svg # 1-2 Cycle removal and toposort -Cycle removal and toposort are done at the same time during single DFS traversal. In case entrypoint -is part of a loop DFS started from entrypoint. This ensures that entrypoint is at the top of -resulting layout if possible. Resulting toposort order is used in many of the following layout steps -that require calculating some property of a vertex based on child property or the other way around. -Using toposort order such operations can be implemented iteration through array in either forward or -reverse direction. To prevent running out of stack memory when processing large graphs DFS is -implemented non-recursively. +Cycle removal and toposort are done in a single DFS traversal. In case the entrypoint +is part of a loop, the DFS starts from the entrypoint. This ensures that the entrypoint is at the +top of resulting layout, if possible. The resulting toposort order is used in many of the following +layout steps that require calculating some property of a vertex based on a child property or the +other way around. Using toposort order, such operations can be implemented by array iteration in +either forward/backward direction. To prevent running out of stack memory when processing large +graphs, DFS is implemented non-recursively. # Row assignment Rows are assigned in toposort order from top to bottom, with nodes row being max(predecessor.row)+1. -This ensures that loop edges are only ones going from deeper levels to previous layers. +This ensures that loop back-edges are the only edges going from lower to higher layers. -To further simply node placement a subset of edges is selected which forms a tree. This turns DAG -drawing problem into a tree drawing problem. For each node in level n following nodes which have -level exactly n+1 are greedily assigned as child nodes in tree. If a node already has parent -assigned then corresponding edge is not part of tree. +To further simply node placement, a subset of edges is selected which forms a tree. This turns a DAG +drawing problem into a tree drawing problem. For each node in level n the following nodes with +level exactly n+1 are greedily assigned as child nodes in the tree. If a node already has a parent +assigned then the corresponding edge is not part of the tree. -# Node position assignment +# Node placement Since the graph has been reduced to a tree, node placement is more or less putting subtrees side by -side with parent on top. There is some room for interpretation what exactly side by side means and -where exactly on top is. Drawing the graph either too dense or too big may make it less readable so -there are configuration options which allow choosing these things resulting in more or less dense -layout. +side with parent on top. There is some room for interpretation as to what exactly 'side by side' +means and where exactly 'on top' is: drawing the graph either too dense or too sparse may make it +less readable, so there are configuration options which allow choosing these things resulting in +more or less dense layout. -Once the subtrees are placed side by side. Parent node can be placed either in the middle of -horizontal bounds or in the middle of direct children. First option results in narrower layout and -more vertical columns. Second option results in nodes being more spread out which may help seeing -where each edge goes. +Once the subtrees are placed side by side, the parent node can be placed either in the middle of +the horizontal bounds or in the middle of its direct children. The first option results in narrower +layout and more vertical columns, while the second option results in more spread out layout which +may help seeing where each edge goes. -In more compact mode two subtrees are placed side by side taking into account their shape. In wider -mode bounding box of shorter subtree is used instead of exact shape. This gives slightly sparse -layout without it being too wide. +In compact mode two subtrees are placed side by side accounting for their shape. In wider +mode the bounding box of the shorter subtree is used instead of its exact shape. This gives slightly +sparser layout without being too wide. \image html graph_parent_placement.svg # Edge routing -Edge routing can be split into: main column selection, rough routing, segment offset calculation. +Edge routing can be split into: main column selection, rough routing, and segment offset +calculation. -Transition from source to target row is done using single vertical segment. This is called main -column. +Transition from source to target row is done using a single vertical segment. This segment is called +the 'main column'. -A sweep line is used for computing main columns: Blocks and edges are processed as events top to +Main columns are computed using a sweep line: blocks and edges are processed as events top to bottom based off their row (max(start row, end row) for edges). Blocked columns are tracked in a tree structure which allows searching nearest column with at least last N rows empty. The column of the starting block is favored for the main column, otherwise the target block's column is chosen @@ -114,10 +115,9 @@ true or false branch. In case of upward edges it is allowed to choose a column o is slightly further than nearest empty to reduce the chance of producing tilted figure 8 shaped crossing between two blocks. -Rough routing creates the path of edge using up to 5 segments using grid coordinates. -Due to nodes being placed in a grid. Horizontal segments of edges can't intersect with any nodes. +Due to nodes being placed in a grid, horizontal segments of edges can't intersect with any nodes. The path for edges is chosen so that it consists of at most 5 segments, typically resulting in -sideways U shape or square Z shape. +sideways U shape or square Z shape: - short vertical segment from node to horizontal line - move to empty column - vertical segment between starting row and end row @@ -134,45 +134,49 @@ ensures that two segments don't overlap. Segment offsets within each column are with some heuristics for assignment order to reduce amount of edge crossings and result in more visually pleasing output for a typical CFG graph. Each segment gets assigned an offset that is maximum of previously assigned offsets overlapping with current segment + segment spacing. -Assignment order is chosen based on: -* direction of previous and last segment - helps reducing crossings and place the segments between + +Assignment order is based on: +- direction of previous and last segment - helps reducing crossings and place the segments between nodes -* segment length - reduces crossing when segment endpoints have the same structure as valid +- segment length - reduces crossing when segment endpoints have the same structure as valid parentheses expression -* edge length - establishes some kind of order when single node is connected to many edges, +- edge length - establishes some kind of order when single node is connected to many edges, typically a block with switch statement or block after switch statement. # Layout compacting -Doing the layout within a grid causes minimal spacing to be limited by widest and tallest block -within each column and row. One common case is block with function entrypoint being wider due to -function name causing wide horizontal space between branching blocks. Another case is rows in two +Doing the layout on a grid limits the minimal spacing to the widest block within a column and +tallest block within a row. One common case is a function-entry block being wider due to the +function name, causing wide horizontal space between branching blocks. Another case is rows in two parallel columns being aligned. \image html layout_compacting.svg -Both problems are mitigated by squishing graph. Compressing in each of the two direction is done +Both problems are mitigated by squishing the graph. Compressing in each of the two direction is done separately. The process is defined as liner program. Each variable represents a position of edge segment or node in the direction being optimized. -Following constraints are used +The following constraints are used: - Keep the order with nearest segments. -- If the node has two outgoing edges, one to the node on left side and other to the right, keep them -on the corresponding side of node's center. -- For all edges keep the node which is above above. This helps when vertical block spacing is set -bigger than double edge spacing and edge shadows relationship between two blocks. +- If a node has two outgoing edges, one to the left and one to the right, keep them +on the corresponding side of the node's center. - Equality constraint to keep relative position between nodes and and segments directly connected to them. -- Equality constraint to keep the node centered when control flow merges -In the vertical direction objective function minimizes y positions of nodes and lengths of vertical -segments. In the horizontal direction objective function minimizes lengths of horizontal segments. +- For all blocks connected by forward edge, keep the vertical distance at least as big as configured +block vertical spacing. This helps when vertical block-spacing is set bigger than double edge +spacing and an edge shadows relationship between two blocks. +- Equality constraint to keep a node centered when control flow merges. + +In the vertical direction the objective function minimizes y positions of nodes and lengths of +vertical segments. In the horizontal direction the objective function minimizes the lengths of +horizontal segments. -In the resulting linear program all constraints beside x_i >= 0 consist of exactly two variables: +In the resulting linear program all constraints besides x_i >= 0 consist of exactly two variables: either x_i - x_j <= c_k or x_i = x_j + c_k. -Since it isn't necessary get perfect solution and to avoid worst case performance current -implementation isn't using a general purpose linear programming solver. Each variable is changed -until constraint is reached and afterwards variables are grouped and changed together. +Since a perfect solution isn't necessary and to avoid worst case performance, the current +implementation isn't using a general purpose linear solver. Instead, each variable is modified +until a constraint is satisfied and afterwards variables are grouped and modified together. */