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

Design per-module logging system #121

Open
ALSchwalm opened this issue Jan 22, 2021 · 1 comment
Open

Design per-module logging system #121

ALSchwalm opened this issue Jan 22, 2021 · 1 comment

Comments

@ALSchwalm
Copy link
Collaborator

Ultimately, it would be very valuable to be able to turn on verbose debugging on a per-module basis. I don't have any design in mind, just that you could set it in the mythril cfg to help debugging without being overwhelmed with other messages.

@paulcacheux
Copy link
Contributor

Hi Adam, we are interested in tackling this issue. After some tests on our side it is clear to us that performance could be impacted by this filtering.

Currently what we though of was adding a configuration like:

{ 
  "version": 1, 
  "log": { 
    "*": "error", 
    "mythril::virtdev::pci": "trace" 
  }, 
  "vms": ... 
} 

Then for each log:

  • We check if the module (metadata.target()) is specified (like mythril::virtdev::pci is in the example)
  • We use the provided log max level if it is the case
  • We use the default level (*) otherwise

This would mean that each log call now has a BTreeMap entry search and multiple string comparisons.
Boot-to-shell time is increased by 50% by this change.

A solution to this problem would be to use the crate hashbrown which is an implementation of HashMap usable in a no-std environment (it was even used as the base of the rework of std’s HashMap). It improves performance in a significant way compared to BTreeMap, but is an additional dependency.

What do you think about this approach ?

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