TY - GEN
T1 - Replay debugging
T2 - 2014 ACM/IEEE 41st International Symposium on Computer Architecture, ISCA 2014
AU - Honarmand, Nima
AU - Torrellas, Josep
PY - 2014
Y1 - 2014
N2 - Hardware-assisted Record and Deterministic Replay (RnR) of programs has been proposed as a primitive for debugging hard-to-repeat software bugs. However, simply providing support for repeatedly stumbling on the same bug does not help diagnose it. For bug diagnosis, developers typically want to modify the code, e.g., by creating and operating on new variables, or printing state. Unfortunately, this renders the RnR log inconsistent and makes Replay Debugging (i.e., debugging while using an RnR log for replay) dicey at best. This paper presents rdb, the first scheme for replay debugging that guarantees exact replay. rdb relies on two mechanisms. The first one is compiler support to split the instrumented application into two executables: one that is identical to the original program binary, and another that encapsulates all the added debug code. The second mechanism is a runtime infrastructure that replays the application and, without affecting it in any way, invokes the appropriate debug code at the appropriate locations. We describe an implementation of rdb based on LLVM and Pin, and show an example of how rdb's replay debugging helps diagnose a real bug.
AB - Hardware-assisted Record and Deterministic Replay (RnR) of programs has been proposed as a primitive for debugging hard-to-repeat software bugs. However, simply providing support for repeatedly stumbling on the same bug does not help diagnose it. For bug diagnosis, developers typically want to modify the code, e.g., by creating and operating on new variables, or printing state. Unfortunately, this renders the RnR log inconsistent and makes Replay Debugging (i.e., debugging while using an RnR log for replay) dicey at best. This paper presents rdb, the first scheme for replay debugging that guarantees exact replay. rdb relies on two mechanisms. The first one is compiler support to split the instrumented application into two executables: one that is identical to the original program binary, and another that encapsulates all the added debug code. The second mechanism is a runtime infrastructure that replays the application and, without affecting it in any way, invokes the appropriate debug code at the appropriate locations. We describe an implementation of rdb based on LLVM and Pin, and show an example of how rdb's replay debugging helps diagnose a real bug.
UR - http://www.scopus.com/inward/record.url?scp=84905454052&partnerID=8YFLogxK
UR - http://www.scopus.com/inward/citedby.url?scp=84905454052&partnerID=8YFLogxK
U2 - 10.1109/ISCA.2014.6853229
DO - 10.1109/ISCA.2014.6853229
M3 - Conference contribution
AN - SCOPUS:84905454052
SN - 9781479943968
T3 - Proceedings - International Symposium on Computer Architecture
SP - 445
EP - 456
BT - 41st Annual International Symposium on Computer Architecture, ISCA 2014 - Conference Proceedings
PB - Institute of Electrical and Electronics Engineers Inc.
Y2 - 14 June 2014 through 18 June 2014
ER -