New debugger for D!!!

dennis luehring dl.soluz at gmx.net
Tue Jan 28 08:27:43 PST 2014


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)






More information about the Digitalmars-d-announce mailing list