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

-conservative option to split ironclad from slight risk but faster #708

Closed
derekbruening opened this issue Nov 28, 2014 · 2 comments
Closed

Comments

@derekbruening
Copy link
Contributor

From bruen...@google.com on December 07, 2011 13:15:57

as part of issue #460 I'm considering a -conservative option that's off by
default, letting me do technically risky but 99.9% safe stuff and improve
performance.

things like: read retaddr off stack an entrance to hooked callee w/o
try/except. read args off stack as well. remember this is on entrance to
standard allocation routines. extremely unlikely to have a bad stack
pointer there: requires hand-rolled bizarre code.

another: assume module won't be racily unloaded while code inside it
continues to execute: allowing me to pass data structs around that might be
deleted on racy unload and avoid table lookups at hook time.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=708

@derekbruening
Copy link
Contributor Author

From bruen...@google.com on December 08, 2011 10:12:40

-leaks_only -no_count_leaks
0.00user 0.01system 0:27.97elapsed 0%CPU (0avgtext+0avgdata 234240maxresident)k
0.00user 0.00system 0:27.53elapsed 0%CPU (0avgtext+0avgdata 234240maxresident)k
0.00user 0.00system 0:27.95elapsed 0%CPU (0avgtext+0avgdata 233984maxresident)k
-conservative -leaks_only -no_count_leaks
0.00user 0.00system 0:36.41elapsed 0%CPU (0avgtext+0avgdata 234496maxresident)k
0.00user 0.00system 0:38.34elapsed 0%CPU (0avgtext+0avgdata 234496maxresident)k
0.00user 0.00system 0:36.91elapsed 0%CPU (0avgtext+0avgdata 234240maxresident)k

@derekbruening
Copy link
Contributor Author

From derek.br...@gmail.com on December 08, 2011 12:54:30

This issue was closed by revision r665 .

Status: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant