[Bug] VV< and VV> do nothing

[xelxebar]

Overview

From the help menu of graph mode, VV?, the commands < (show function callgraph) and > (show program callgraph) are listed but seem to have no effect.

This seems to be part of the meta-issue #6967; however, it doesn't reference an explicit issue for this bug. Also, this potentially overlaps with #8062, given the help text for the < command.

[radare]

It was removed on purpose. See my previous reply. Use git log to find when and where

…

On 30 Jul 2017, at 08:34, xelxebar ***@***.***> wrote: Overview From the help menu of graph mode, VV?, the commands < (show function callgraph) and > (show program callgraph) are listed but seem to have no effect. This seems to be part of the meta-issue #6967; however, it doesn't reference an explicit issue for this bug. Also, this potentially overlaps with #8062, given the help text for the < command. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[xelxebar]

Okay. Thanks. In that case, it might make sense to remove the help information about those commands in libr/core/graph.c.

[radare]

Well we can compute an aprox time of the cost of rendering this and showing a warning with y/n options before doing so. And reenable that graph. Eventually we can render partial graphs or cut them at a specific amount of nodes and slowly render more in background. Shouldnt harm to do that in a thread

…

On 30 Jul 2017, at 15:12, xelxebar ***@***.***> wrote: Okay. Thanks. In that case, it might make sense to remove the help information about those commands in libr/core/graph.c. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[xelxebar]

Asyncronously generating the graph would be great! I would imagine that it's reasonable to assume we can immediately show the entry node. Ideally, we'd then grow the trie on the fly as needed, like you're saying.

[radare]

Fixed