Open GoogleCodeExporter opened 9 years ago
#1 is pretty interesting, and could be done reliably and easily, but there is
the risk of personal user information disclosure.
#2 is not really workable; gdb can get away with it because the failure case is
considered acceptable during debugging; there's a much more significant
downside when executing crash reporting on the user's system. It would still be
possible to fetch the class name, but the risk of user information disclosure
remains.
The idea of context-aware extended debugging information is very interesting,
however.
Original comment by landon.j.fuller@gmail.com
on 21 Sep 2011 at 10:50
Created branch landonf-30-register-examine to experiment with this feature.
Original comment by landon.j.fuller@gmail.com
on 24 Sep 2011 at 1:12
A very simple hack on ARM is to print r1 and r2 as C strings if the top
function is objc_msgSend (or r2 and r3 for objc_msgSend_stret), which can be
done (badly) by assuming the length of objc_msgSend is ~1/2/4K or so. (I don't
think objc_msgSend touches those registers, but I could be wrong.)
Alternatively, a symbolicatecrash-alike could recover selector names. A really
simple hack is to just print the contents of all registers interpreted as
C-strings if they point into a loaded image.
(r2 is nice because it's often a selector, e.g. -performSelector:withObject:...
or -respondsToSelector: and friends. r3 is a selector for
addObserver:selector:... and addTarget:action:... but those don't tend to crash)
Original comment by tc...@airsource.co.uk
on 28 Sep 2011 at 6:58
Thanks for giving this some attention. Your point about personal information
is well taken. I'd be just as happy to see a restricted version like described
in comment 3: Only objc_msgSend and only a relevant subset of registers.
Original comment by n8gray@gmail.com
on 25 Oct 2011 at 8:46
Original issue reported on code.google.com by
n8gray@gmail.com
on 21 Sep 2011 at 10:29