summaryrefslogtreecommitdiffstats
path: root/compiler/driver
diff options
context:
space:
mode:
authorSebastien Hertz <shertz@google.com>2014-05-23 08:59:42 +0200
committerSebastien Hertz <shertz@google.com>2014-06-11 14:29:00 +0200
commit9f1020305292a21fd14a402b189c765a125226ab (patch)
tree6b730cbe56ded370d1b4293629826ad2c7b06f7f /compiler/driver
parentbc72903b909f5147b8cb207f3e5d02a8ef85e4e7 (diff)
downloadart-9f1020305292a21fd14a402b189c765a125226ab.zip
art-9f1020305292a21fd14a402b189c765a125226ab.tar.gz
art-9f1020305292a21fd14a402b189c765a125226ab.tar.bz2
Fix exception reporting from interpreter
To comply with JDWP exception report rules, we must report an exception at the location of the throw (or the first instruction encountered after a native call). To do this, we use the CatchLocationFinder visitor to look for a catch handler until we reach a native frame or the top frame. Because interpreter handles pending exception on a method-by-method basis, we need a flag to remember we already reported the exception and avoid reporting it multiple times when unwinding methods. The drawback is we need to maintain the state of this flag. We clear it when the exception is cleared. In the case we temporarily clear the exception (when finding a catch handler for instance), we restore the flag to its previous value at the same time we restore the pending exception. Bump oat version to force recompilation because we modify Thread offsets. Bug: 14402770 Change-Id: Ic059c58f80b2023b118038301f8f0a24f1e18241
Diffstat (limited to 'compiler/driver')
0 files changed, 0 insertions, 0 deletions