Assume I have VBA code that runs on Microsoft Office, how can I plug the runtime VBA into lldb to understand better what actually runs and where staff doesn't run, what is the underlying cause of it?
Asked
Active
Viewed 40 times
0
park joh
- 23
- 3
-
lldb requires debugging symbols. Does Microsoft let you compile that way? – Richard Barber Mar 05 '20 at 17:24
-
IIUC, VBA programs are not compiled to executable code, but to some intermediate representation that then gets interpreted by the runtime. So you would have to talk to the runtime (much the way Java debugging works) to know what was currently executing, and get info on threads, stacks, variables and the like. Without that, all you would see are the interpreter's stack frames. If you understood how the interpreter worked, you might be able to figure out what functions were getting interpreted, but to do that you'd need a pretty detailed understanding of the runtime. – Jim Ingham Mar 05 '20 at 20:28
-
The VBA runtime most likely has affordances for debugging, which would be the preferred way to debug the code. But lldb has no support for hooking into that. It's probably a substantial piece of work to add this support. – Jim Ingham Mar 05 '20 at 20:28