This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Don't dissasemble large functions by default
ClosedPublic

Authored by labath on May 12 2020, 8:26 AM.

Details

Summary

If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.

This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, or start/stop addresses for disassembly.

The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.

Diff Detail

Event Timeline

labath created this revision.May 12 2020, 8:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2020, 8:26 AM
JDevlieghere accepted this revision.May 12 2020, 11:10 AM

Looks good to me.

lldb/source/Commands/CommandObjectDisassemble.cpp
231

nit: I don't think we need either of these commas.

lldb/test/Shell/Commands/command-disassemble-process.yaml
93

Cool, I didn't realize this was possible.

This revision is now accepted and ready to land.May 12 2020, 11:10 AM

Instead of just printing out the range, can we print out the disassemble command you would run to actually disassemble the range?

Also, I think we should add a --force option since if you were using this in a script you wouldn't get a chance to respond to the error.

labath marked 3 inline comments as done.

Instead of just printing out the range, can we print out the disassemble command you would run to actually disassemble the range?

Also, I think we should add a --force option since if you were using this in a script you wouldn't get a chance to respond to the error.

Yes, I've been thinking about a --force option too. You're right that this is a friendlier interface for scripting purposes.

The reason I wanted to print the range was to give the user a chance to pause and say "yes, I really don't want to disassemble all of *that*". With a --force option, do you think it's necessary to print the repeat command? It seems that doing a "<Up>--force<Return> would be more straight-forward than copy-pasting a chunk of text (and I don't believe we currently have a way to fetch the original command line from within a CommandObject implementation).

lldb/test/Shell/Commands/command-disassemble-process.yaml
93

It's a very recent addition. It runs as a textual pre-processing step, so you can use it to do all the evi^H^H^Hnice things you can with a c preprocessor.

labath updated this revision to Diff 263697.May 13 2020, 6:44 AM
labath marked an inline comment as done.

Remove commas, add --force.

jingham accepted this revision.May 13 2020, 11:11 AM

If you have --force, then the address range is informational, in which case having the full command would be more confusing than anything. So this is fine, thanks for adding it.

I thought briefly about whether we should also add a setting for this. But if it is something that you come across often you can just re-alias di to disassemble --force. I used to think we needed to always provide global settings for this sort of behavior, but if the setting just controls the behavior of one command, I'm beginning to think using aliases is better than adding more and more stuff to the settings.

I agree you want to print out the range. Many of the times you get huge functions, they aren't actually huge, they just look that way because we're just missing the subsequent symbols. So the user might be disassembling something they know is a small function, and we need to give them some clue to why we think that's not so.

This looks fine to me.

This revision was automatically updated to reflect the committed changes.

I reverted this it breaks TestFoundationDisassembly.py.