Am 28.01.2014 17:24, schrieb dennis luehring:
Am 28.01.2014 17:16, schrieb Sarath Kodali:
I expect this is how it will be even with dbg and IDEs. The IDE
will have a plugin that sits between the debugger and IDE. The
communication between the IDE plugin and debugger will be over a
socket and the dbg output will be in JSON format so that IDE
plugin can parse it properly. Depending on the IDE, the plugin
will be either a library (dll) or an independent executable.
its a little bit different to pin because pin is the host
of the given tool-communication dll - so the dll interface is the
interface not JSON
(pin(tool dll<--)-- any protocol --> ide/whatever
in your idea
dbg <--- socker/JASON --> ide/whatever
the question is - debuggers needs to throw masses
of information around - why put a slow JSON parser between, every single
step command gets JSONed, parsed, singlestep, result gets JSOned etc...
millions of times - why?
i would suggest an real tool api for loaded protocol-drivers - like pin
do - and implement a control_dbg_with_tcp_and_json.dll as a driver
this way its still possible to build a super fast tracing server on top
of dbg - else JSON will become a problem - without any need because
the same target is reachable with a driver-dll(plugin)