www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - New debugger for D!!!

reply "Sarath Kodali" <sarath dummy.com> writes:
I'm planning to release a new debugger for D sometime during end 
of February.  This is a heads up for all those who are eagerly 
looking for a good debugger for D.

Here is a sample debug session:

$ ./dbg ./dbg
New session s1 (./dbg) started
New process p1 (program dbg) created
p1.1 SUSPENDED  [D main in dbg.d]
78:  main(string[] args)
dbg> list 175
Source listing for thread p1.1, program dbg
175:      if (srcpath !is null)
176:          dv_dbgSrcpath(srcpath);
177:      if (sympath !is null)
178:          dv_dbgSympath(sympath);
179:      auto cmd = new Command(uiType);
180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
181:      if (dbgrc is null)
182:      {
183:          dbgrc = homedir ~ "/" ~ DBGRC_FILE;
184:          cmd.rc_exec(dbgrc);    // home dir dbgrc
dbg> run -u 179
p1.1 SUSPENDED  [D main in dbg.d]
179:      auto cmd = new Command(uiType);
dbg> step -o
p1.1 STEPPED  [D main in dbg.d]
180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
dbg> help
Run help on the following topics to get additional help.
Start & Stop:
     create, grab, quit, release, %follow, %srcpath, %sympath
Execution:
     halt, jump, kill, run, step, wait, %thread
Events:
     events, onstop, signal, stop, syscall, %lastevent, %thisevent
View or Modify:
     dump, list, maps, print, regs, set, stack, status, symbols, 
vars, which
     %dbg_lang, %file, %frame, %func, %lang, %line, %list_file, 
%list_line,
     %loc, %num_lines
Convenience:
     !, alias, help, logoff, logon, script, %cwd, %logfile, 
%log_prefix,
     %prompt, %result, %verbose

For a full list of help topics, run "help toc".
dbg> help create
SYNOPSIS:
     create [-f <follow>] [-l] [-s <srcpath>] [-S <sympath>] 
[<shell_cmd_string>]
DESCRIPTION:
     Create a new debugging session for <shell_cmd_string>. The 
existing debug
     sessions are not affected by this command. One could 
simultaneously
     have multiple debug sessions. If <shell_cmd_string> is not 
specified, the
     <shell_cmd_string> from previous create command is used and 
the previous
     create session is destroyed. After the session is created, 
this command
     runs all the processes till their 'start' function.
OPTIONS:
     -f    follow 'prog', 'proc', 'thread' or 'all' or 'none'
     -l    load only; do not run new program / thread till its 
'start' function
     -s    paths for source files
     -S    paths for debug symbol files
NOTES:
     It is not possible to redirect or pipe the output of create 
command.
EXAMPLES:
     create test_prog1 arg1 arg2 2>/tmp/prog1.err | test_prog2
           # creates a new debug session for test_prog1 and 
test_prog2
     create MANPAGER=more man 1p man
     create xterm -e ./cmd
SEE ALSO:
     events, quit, kill, release, run, shell_cmd_string, status, 
step
     %dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath, 
%sympath
dbg>
Jan 27 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 I'm planning to release a new debugger for D sometime during 
 end of February.  This is a heads up for all those who are 
 eagerly looking for a good debugger for D.

 Here is a sample debug session:

 $ ./dbg ./dbg
 New session s1 (./dbg) started
 New process p1 (program dbg) created
 p1.1 SUSPENDED  [D main in dbg.d]
 78:  main(string[] args)
 dbg> list 175
 Source listing for thread p1.1, program dbg
 175:      if (srcpath !is null)
 176:          dv_dbgSrcpath(srcpath);
 177:      if (sympath !is null)
 178:          dv_dbgSympath(sympath);
 179:      auto cmd = new Command(uiType);
 180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
 181:      if (dbgrc is null)
 182:      {
 183:          dbgrc = homedir ~ "/" ~ DBGRC_FILE;
 184:          cmd.rc_exec(dbgrc);    // home dir dbgrc
 dbg> run -u 179
 p1.1 SUSPENDED  [D main in dbg.d]
 179:      auto cmd = new Command(uiType);
 dbg> step -o
 p1.1 STEPPED  [D main in dbg.d]
 180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
 dbg> help
 Run help on the following topics to get additional help.
 Start & Stop:
     create, grab, quit, release, %follow, %srcpath, %sympath
 Execution:
     halt, jump, kill, run, step, wait, %thread
 Events:
     events, onstop, signal, stop, syscall, %lastevent, 
 %thisevent
 View or Modify:
     dump, list, maps, print, regs, set, stack, status, symbols, 
 vars, which
     %dbg_lang, %file, %frame, %func, %lang, %line, %list_file, 
 %list_line,
     %loc, %num_lines
 Convenience:
     !, alias, help, logoff, logon, script, %cwd, %logfile, 
 %log_prefix,
     %prompt, %result, %verbose

 For a full list of help topics, run "help toc".
 dbg> help create
 SYNOPSIS:
     create [-f <follow>] [-l] [-s <srcpath>] [-S <sympath>] 
 [<shell_cmd_string>]
 DESCRIPTION:
     Create a new debugging session for <shell_cmd_string>. The 
 existing debug
     sessions are not affected by this command. One could 
 simultaneously
     have multiple debug sessions. If <shell_cmd_string> is not 
 specified, the
     <shell_cmd_string> from previous create command is used and 
 the previous
     create session is destroyed. After the session is created, 
 this command
     runs all the processes till their 'start' function.
 OPTIONS:
     -f    follow 'prog', 'proc', 'thread' or 'all' or 'none'
     -l    load only; do not run new program / thread till its 
 'start' function
     -s    paths for source files
     -S    paths for debug symbol files
 NOTES:
     It is not possible to redirect or pipe the output of create 
 command.
 EXAMPLES:
     create test_prog1 arg1 arg2 2>/tmp/prog1.err | test_prog2
           # creates a new debug session for test_prog1 and 
 test_prog2
     create MANPAGER=more man 1p man
     create xterm -e ./cmd
 SEE ALSO:
     events, quit, kill, release, run, shell_cmd_string, status, 
 step
     %dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath, 
 %sympath
 dbg>
Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep
Jan 27 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 27 January 2014 at 17:10:06 UTC, John Colvin wrote:
 On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 I'm planning to release a new debugger for D sometime during 
 end of February.  This is a heads up for all those who are 
 eagerly looking for a good debugger for D.

 Here is a sample debug session:

 $ ./dbg ./dbg
 New session s1 (./dbg) started
 New process p1 (program dbg) created
 p1.1 SUSPENDED  [D main in dbg.d]
 78:  main(string[] args)
 dbg> list 175
 Source listing for thread p1.1, program dbg
 175:      if (srcpath !is null)
 176:          dv_dbgSrcpath(srcpath);
 177:      if (sympath !is null)
 178:          dv_dbgSympath(sympath);
 179:      auto cmd = new Command(uiType);
 180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
 181:      if (dbgrc is null)
 182:      {
 183:          dbgrc = homedir ~ "/" ~ DBGRC_FILE;
 184:          cmd.rc_exec(dbgrc);    // home dir dbgrc
 dbg> run -u 179
 p1.1 SUSPENDED  [D main in dbg.d]
 179:      auto cmd = new Command(uiType);
 dbg> step -o
 p1.1 STEPPED  [D main in dbg.d]
 180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
 dbg> help
 Run help on the following topics to get additional help.
 Start & Stop:
    create, grab, quit, release, %follow, %srcpath, %sympath
 Execution:
    halt, jump, kill, run, step, wait, %thread
 Events:
    events, onstop, signal, stop, syscall, %lastevent, 
 %thisevent
 View or Modify:
    dump, list, maps, print, regs, set, stack, status, symbols, 
 vars, which
    %dbg_lang, %file, %frame, %func, %lang, %line, %list_file, 
 %list_line,
    %loc, %num_lines
 Convenience:
    !, alias, help, logoff, logon, script, %cwd, %logfile, 
 %log_prefix,
    %prompt, %result, %verbose

 For a full list of help topics, run "help toc".
 dbg> help create
 SYNOPSIS:
    create [-f <follow>] [-l] [-s <srcpath>] [-S <sympath>] 
 [<shell_cmd_string>]
 DESCRIPTION:
    Create a new debugging session for <shell_cmd_string>. The 
 existing debug
    sessions are not affected by this command. One could 
 simultaneously
    have multiple debug sessions. If <shell_cmd_string> is not 
 specified, the
    <shell_cmd_string> from previous create command is used and 
 the previous
    create session is destroyed. After the session is created, 
 this command
    runs all the processes till their 'start' function.
 OPTIONS:
    -f    follow 'prog', 'proc', 'thread' or 'all' or 'none'
    -l    load only; do not run new program / thread till its 
 'start' function
    -s    paths for source files
    -S    paths for debug symbol files
 NOTES:
    It is not possible to redirect or pipe the output of create 
 command.
 EXAMPLES:
    create test_prog1 arg1 arg2 2>/tmp/prog1.err | test_prog2
          # creates a new debug session for test_prog1 and 
 test_prog2
    create MANPAGER=more man 1p man
    create xterm -e ./cmd
 SEE ALSO:
    events, quit, kill, release, run, shell_cmd_string, status, 
 step
    %dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath, 
 %sympath
 dbg>
Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep
woops, missed a couple: http://pastebin.com/t0sejnF9
Jan 27 2014
parent "Sarath Kodali" <sarath dummy.com> writes:
On Monday, 27 January 2014 at 17:13:05 UTC, John Colvin wrote:

 Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep
woops, missed a couple: http://pastebin.com/t0sejnF9
Thanks!
Jan 27 2014
prev sibling next sibling parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 I'm planning to release a new debugger for D sometime during 
 end of February.  This is a heads up for all those who are 
 eagerly looking for a good debugger for D.
Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-)
Jan 27 2014
next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote:
 On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 I'm planning to release a new debugger for D sometime during 
 end of February.  This is a heads up for all those who are 
 eagerly looking for a good debugger for D.
Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-)
Ditto to these. I'm planning a project that will need a multi platform debugger, and would love to learn more about this.
Jan 27 2014
prev sibling parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote:
 Which OSs are supported?
 Which compilers are supported, which debug info base is used?
 Is the info directly extracted from the executable aka 
 Dwarf/CV4/PDB support?

 The sample debug session looks cool, so I'd really like to know 
 this to estimate whether it's worth to integrate it into Mono-D 
 or other IDEs :-)
Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath
Jan 27 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/14 7:00 PM, Sarath Kodali wrote:
 On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote:
 Which OSs are supported?
 Which compilers are supported, which debug info base is used?
 Is the info directly extracted from the executable aka Dwarf/CV4/PDB
 support?

 The sample debug session looks cool, so I'd really like to know this
 to estimate whether it's worth to integrate it into Mono-D or other
 IDEs :-)
Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath
This does sound very interesting - and don't forget to submit a talk on the topic to DConf!!! Andrei
Jan 27 2014
next sibling parent "yazd" <yazan.dabain gmail.com> writes:
On Tuesday, 28 January 2014 at 05:19:13 UTC, Andrei Alexandrescu 
wrote:
 This does sound very interesting - and don't forget to submit a 
 talk on the topic to DConf!!!

 Andrei
Yes please, it would be a very interesting talk.
Jan 27 2014
prev sibling parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Tuesday, 28 January 2014 at 05:19:13 UTC, Andrei Alexandrescu 
wrote:
 This does sound very interesting - and don't forget to submit a 
 talk on the topic to DConf!!!

 Andrei
Can't commit but will try :( too many things in my hand ...
Jan 28 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/14 8:04 AM, Sarath Kodali wrote:
 On Tuesday, 28 January 2014 at 05:19:13 UTC, Andrei Alexandrescu wrote:
 This does sound very interesting - and don't forget to submit a talk
 on the topic to DConf!!!

 Andrei
Can't commit but will try :( too many things in my hand ...
Do it. http://www.youtube.com/watch?v=JoqDYcCDOTg Andrei
Jan 28 2014
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 28.01.2014 04:00, schrieb Sarath Kodali:
 I'm also
 planning to add a JSON or CSV output format so that it will be
 easy to parse the output when integrating with IDEs. So I would
 recommend that you wait till I release 1.0 version - sometime
 before Dconf 2014 - hopefully!
why don't ease the IDE integration even more - for example the pin tool from intel (ptools.org) is a normal executable (the server) but you can give pin a tool/commander dll per commandline which is then responsible for controling the debugger - this way its very easy to integrate the debugger into any environment fast and performant examples pin.exe -t idadbg.dll <- starts pin with an IDA-tool-dll to be able to control pin with the ida debugger pin.exe -t vsdbg.dll <- starts pin with an vs-studio debug helper this way you can use pin as an debugger for VStudio etc. csv and json is nice - but there a much nicer ways of doing ipc
Jan 27 2014
parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Tuesday, 28 January 2014 at 06:34:50 UTC, dennis luehring 
wrote:
 Am 28.01.2014 04:00, schrieb Sarath Kodali:
 I'm also
 planning to add a JSON or CSV output format so that it will be
 easy to parse the output when integrating with IDEs. So I would
 recommend that you wait till I release 1.0 version - sometime
 before Dconf 2014 - hopefully!
why don't ease the IDE integration even more - for example the pin tool from intel (ptools.org) is a normal executable (the server) but you can give pin a tool/commander dll per commandline which is then responsible for controling the debugger - this way its very easy to integrate the debugger into any environment fast and performant examples pin.exe -t idadbg.dll <- starts pin with an IDA-tool-dll to be able to control pin with the ida debugger pin.exe -t vsdbg.dll <- starts pin with an vs-studio debug helper this way you can use pin as an debugger for VStudio etc. csv and json is nice - but there a much nicer ways of doing ipc
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.
Jan 28 2014
parent reply dennis luehring <dl.soluz gmx.net> writes:
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?
Jan 28 2014
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
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)
Jan 28 2014
prev sibling parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Tuesday, 28 January 2014 at 16:24:32 UTC, dennis luehring 
wrote:
 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'm not fixated on JSON :) I thought that is more popular now-a-days :). Today dbg outputs in human readable format. After the alpha release, I will add the machine readable format - what everyone prefers.
Jan 28 2014
parent dennis luehring <dl.soluz gmx.net> writes:
Am 28.01.2014 18:23, schrieb Sarath Kodali:
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'm not fixated on JSON:) I thought that is more popular now-a-days:). Today dbg outputs in human readable format. After the alpha release, I will add the machine readable format - what everyone prefers.
clear - i would just use a plugin system for adding json or whatever communication (like pin do) so its still api based - not (text/binary) protocol based from the very beginning
Jan 28 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-28 04:00, Sarath Kodali wrote:

 Next month I will be releasing an alpha version with support for Linux,
 x86, Elf+Dwarf, DMD and GCC.
I'm waiting for the OS X version :)
  But in the coming months I will add support
 for other 64 bit OSes and compilers. I'm also planning to add a JSON or
 CSV output format so that it will be easy to parse the output when
 integrating with IDEs.
Why not make it useable as a library that can be directly integrated into an IDE. -- /Jacob Carlborg
Jan 28 2014
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg wrote:
 On 2014-01-28 04:00, Sarath Kodali wrote:

 Next month I will be releasing an alpha version with support 
 for Linux,
 x86, Elf+Dwarf, DMD and GCC.
I'm waiting for the OS X version :)
not going happen until dmd gets fixed. i'm not tested GDC yet, but others compilers don't emit variable address info for debug or it shown as "optimized out" values. i think it may be related to TLS because __gshared variables CAN be debugged.
Jan 28 2014
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 28 January 2014 13:24, evilrat <evilrat666 gmail.com> wrote:
 On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg wrote:
 On 2014-01-28 04:00, Sarath Kodali wrote:

 Next month I will be releasing an alpha version with support for Linux,
 x86, Elf+Dwarf, DMD and GCC.
I'm waiting for the OS X version :)
not going happen until dmd gets fixed. i'm not tested GDC yet, but others compilers don't emit variable address info for debug or it shown as "optimized out" values. i think it may be related to TLS because __gshared variables CAN be debugged.
1) If it's "optimised out" then I suggest not running a debugger with -O generated code. 2) What debugger are you using? I am aware that gdb does not evaluate D programs correctly in certain situations.
Jan 28 2014
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 28 January 2014 at 13:59:48 UTC, Iain Buclaw wrote:
 On 28 January 2014 13:24, evilrat <evilrat666 gmail.com> wrote:
 On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg 
 wrote:
 On 2014-01-28 04:00, Sarath Kodali wrote:

 Next month I will be releasing an alpha version with support 
 for Linux,
 x86, Elf+Dwarf, DMD and GCC.
I'm waiting for the OS X version :)
not going happen until dmd gets fixed. i'm not tested GDC yet, but others compilers don't emit variable address info for debug or it shown as "optimized out" values. i think it may be related to TLS because __gshared variables CAN be debugged.
1) If it's "optimised out" then I suggest not running a debugger with -O generated code.
it is optimized out with LDC compiled program, and simply not present with DMD.
 2) What debugger are you using? I am aware that gdb does not 
 evaluate
 D programs correctly in certain situations.
both gdb and llvm. results are same.
Jan 28 2014
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 28 January 2014 14:14, evilrat <evilrat666 gmail.com> wrote:
 On Tuesday, 28 January 2014 at 13:59:48 UTC, Iain Buclaw wrote:
 On 28 January 2014 13:24, evilrat <evilrat666 gmail.com> wrote:
 On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg wrote:
 On 2014-01-28 04:00, Sarath Kodali wrote:

 Next month I will be releasing an alpha version with support for Linux,
 x86, Elf+Dwarf, DMD and GCC.
I'm waiting for the OS X version :)
not going happen until dmd gets fixed. i'm not tested GDC yet, but others compilers don't emit variable address info for debug or it shown as "optimized out" values. i think it may be related to TLS because __gshared variables CAN be debugged.
1) If it's "optimised out" then I suggest not running a debugger with -O generated code.
it is optimized out with LDC compiled program, and simply not present with DMD.
This sounds promising for GDC (I'm yet to come across some that is along the lines of what you describe).
Jan 28 2014
prev sibling parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg wrote:
 On 2014-01-28 04:00, Sarath Kodali wrote:

 Next month I will be releasing an alpha version with support 
 for Linux,
 x86, Elf+Dwarf, DMD and GCC.
I'm waiting for the OS X version :)
 But in the coming months I will add support
 for other 64 bit OSes and compilers. I'm also planning to add 
 a JSON or
 CSV output format so that it will be easy to parse the output 
 when
 integrating with IDEs.
Why not make it useable as a library that can be directly integrated into an IDE.
If dbg is a library, whenever the debugger hangs or crashes, the IDE also hangs or crashes and you may loose all your data. It is much safer to have dbg as a server and have an IDE plugin as a client.
Jan 28 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-28 17:21, Sarath Kodali wrote:

 If dbg is a library, whenever the debugger hangs or crashes, the IDE
 also hangs or crashes and you may loose all your data. It is much safer
 to have dbg as a server and have an IDE plugin as a client.
Fair enough. JSON still doesn't sound like a very effective way to communicate with. -- /Jacob Carlborg
Jan 28 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 1/28/2014 12:15 PM, Jacob Carlborg wrote:
 On 2014-01-28 17:21, Sarath Kodali wrote:

 If dbg is a library, whenever the debugger hangs or crashes, the IDE
 also hangs or crashes and you may loose all your data. It is much safer
 to have dbg as a server and have an IDE plugin as a client.
Fair enough. JSON still doesn't sound like a very effective way to communicate with.
Yea, I'd strongly recommend using a proper binary format. Protobuf can help with that. Text-based data is overused, overrated, and completely pointless for direct software->software communication (as opposed to human->software or software->human).
Jan 28 2014
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 28/01/2014 03:00, Sarath Kodali wrote:
 On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote:
 Which OSs are supported?
 Which compilers are supported, which debug info base is used?
 Is the info directly extracted from the executable aka Dwarf/CV4/PDB
 support?

 The sample debug session looks cool, so I'd really like to know this
 to estimate whether it's worth to integrate it into Mono-D or other
 IDEs :-)
Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath
Ok, going on the contrarian view here, but if those are your supported OSes/compiler, isn't that need fairly adequately filled by GDB at the moment? Why start work on a whole new compiler? Particularly, the Windows debugging scene for D is much more lacking than Linux, so I'm failing to see why all the enthusiasm around here...
Feb 06 2014
prev sibling parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 28/01/2014 03:00, Sarath Kodali wrote:
 On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote:
 Which OSs are supported?
 Which compilers are supported, which debug info base is used?
 Is the info directly extracted from the executable aka Dwarf/CV4/PDB
 support?

 The sample debug session looks cool, so I'd really like to know this
 to estimate whether it's worth to integrate it into Mono-D or other
 IDEs :-)
Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath
Ok, going on the contrarian view here, but if those are your supported OSes/compiler, isn't that need fairly adequately filled by GDB at the moment? Why start work on a whole new debugger? Particularly since the Windows debugging scene for D is much more lacking than Linux, so I'm failing to see why all the enthusiasm around here...
Feb 06 2014
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 p1.1 SUSPENDED  [D main in dbg.d]
 179:      auto cmd = new Command(uiType);
 dbg> step -o
 p1.1 STEPPED  [D main in dbg.d]
 180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
Would you mind putting the line number in the same line as the file name? I'm working on a debugger plugin for Vim, and I would obviously want to support your debugger once it's released. I find it easy to interpret the debugger output line by line, and it really makes things hard when I have to join data from multiple lines... You said you want to add JSON and\or CSV output formats, Vim doesn't support JSON natively and CSV is still multiple lines. So, if it wouldn't be too hard having data in the same line can be really be helpful! This is also true when printing values - having the expression and the result printed at the same line makes things easier to interpret. BTW, would you mind picking a different name? I understand that "dbg" stands for "D Debugger", but there is already a debugger named "dbg"(http://www.php-debugger.com/dbg/) and with a name so generic I would be surprised if there aren't other debuggers with that name...
Jan 28 2014
next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 28 January 2014 at 15:23:28 UTC, Idan Arye wrote:
 On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:


 BTW, would you mind picking a different name? I understand that 
 "dbg" stands for "D Debugger", but there is already a debugger 
 named "dbg"(http://www.php-debugger.com/dbg/) and with a name 
 so generic I would be surprised if there aren't other debuggers 
 with that name...
In the event that you take Idan's advice, I just want to be the first to come up with a lame naming suggestion. smackD I thought I was being very original with that one, but of course there is already a similarly named product used for Java in Eclipse: http://blog.teamextension.com/smack-enhanced-debugger-1278 but not being a Java person I have no idea if that is a popular product at all.
Jan 28 2014
prev sibling parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Tuesday, 28 January 2014 at 15:23:28 UTC, Idan Arye wrote:
 On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 p1.1 SUSPENDED  [D main in dbg.d]
 179:      auto cmd = new Command(uiType);
 dbg> step -o
 p1.1 STEPPED  [D main in dbg.d]
 180:      cmd.rc_exec(GLOBAL_DBGRC_FILE);
Would you mind putting the line number in the same line as the file name? I'm working on a debugger plugin for Vim, and I would obviously want to support your debugger once it's released. I find it easy to interpret the debugger output line by line, and it really makes things hard when I have to join data from multiple lines... You said you want to add JSON and\or CSV output formats, Vim doesn't support JSON natively and CSV is still multiple lines. So, if it wouldn't be too hard having data in the same line can be really be helpful! This is also true when printing values - having the expression and the result printed at the same line makes things easier to interpret.
The output is configurable, independent of JSON or CSV, and this is just one form. I will make it as easy of possible for plug-ins to parse the output.
 BTW, would you mind picking a different name? I understand that 
 "dbg" stands for "D Debugger", but there is already a debugger 
 named "dbg"(http://www.php-debugger.com/dbg/) and with a name 
 so generic I would be surprised if there aren't other debuggers 
 with that name...
I did not do any research on name; just shortened "debug" to "dbg" :) I'm bad at coming up with good names, so any suggestions are always welcome. - Sarath
Jan 28 2014
next sibling parent reply John J <john.joyus gmail.com> writes:
On 01/28/2014 12:00 PM, Sarath Kodali wrote:
 I did not do any research on name; just shortened "debug" to "dbg" :)
 I'm bad at coming up with good names, so any suggestions are always
 welcome.
bugD :)
Jan 28 2014
parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Tuesday, 28 January 2014 at 22:04:34 UTC, John J wrote:
 On 01/28/2014 12:00 PM, Sarath Kodali wrote:
 I did not do any research on name; just shortened "debug" to 
 "dbg" :)
 I'm bad at coming up with good names, so any suggestions are 
 always
 welcome.
bugD :)
buggeD?
Jan 28 2014
parent John J <john.joyus gmail.com> writes:
On 01/28/2014 06:04 PM, Francesco Cattoglio wrote:
 On Tuesday, 28 January 2014 at 22:04:34 UTC, John J wrote:
 On 01/28/2014 12:00 PM, Sarath Kodali wrote:
 I did not do any research on name; just shortened "debug" to "dbg" :)
 I'm bad at coming up with good names, so any suggestions are always
 welcome.
bugD :)
buggeD?
Yes, the bugD pronounced as bugged! :)
Jan 28 2014
prev sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
 I did not do any research on name; just shortened "debug" to 
 "dbg" :)
 I'm bad at coming up with good names, so any suggestions are 
 always welcome.

 - Sarath
D!buger
Jan 28 2014
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:
 I did not do any research on name; just shortened "debug" to 
 "dbg" :)
 I'm bad at coming up with good names, so any suggestions are 
 always welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
Jan 28 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/14 4:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:
 I did not do any research on name; just shortened "debug" to "dbg" :)
 I'm bad at coming up with good names, so any suggestions are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
noice
Jan 28 2014
parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei 
Alexandrescu wrote:
 On 1/28/14 4:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:
 I did not do any research on name; just shortened "debug" to 
 "dbg" :)
 I'm bad at coming up with good names, so any suggestions are 
 always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
noice
http://www.noicedebugger.com/ already exists!
Jan 29 2014
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali 
wrote:
 On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei 
 Alexandrescu wrote:
 On 1/28/14 4:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace 
 wrote:
 I did not do any research on name; just shortened "debug" 
 to "dbg" :)
 I'm bad at coming up with good names, so any suggestions 
 are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
noice
http://www.noicedebugger.com/ already exists!
I like bugD :o)
Jan 29 2014
parent reply "Andrea Fontana" <nospam example.com> writes:
On Wednesday, 29 January 2014 at 16:33:47 UTC, Gary Willoughby 
wrote:
 On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali 
 wrote:
 On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei 
 Alexandrescu wrote:
 On 1/28/14 4:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace 
 wrote:
 I did not do any research on name; just shortened "debug" 
 to "dbg" :)
 I'm bad at coming up with good names, so any suggestions 
 are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
noice
http://www.noicedebugger.com/ already exists!
I like bugD :o)
d-bugger
Jan 29 2014
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 29 January 2014 at 16:45:20 UTC, Andrea Fontana 
wrote:
 On Wednesday, 29 January 2014 at 16:33:47 UTC, Gary Willoughby 
 wrote:
 On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali 
 wrote:
 On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei 
 Alexandrescu wrote:
 On 1/28/14 4:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace 
 wrote:
 I did not do any research on name; just shortened "debug" 
 to "dbg" :)
 I'm bad at coming up with good names, so any suggestions 
 are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
noice
http://www.noicedebugger.com/ already exists!
I like bugD :o)
d-bugger
That'll give anyone from the UK a good laugh.
Jan 29 2014
next sibling parent "Andrea Fontana" <nospam example.com> writes:
On Wednesday, 29 January 2014 at 16:55:40 UTC, Meta wrote:
 On Wednesday, 29 January 2014 at 16:45:20 UTC, Andrea Fontana 
 wrote:
 On Wednesday, 29 January 2014 at 16:33:47 UTC, Gary Willoughby 
 wrote:
 On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali 
 wrote:
 On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei 
 Alexandrescu wrote:
 On 1/28/14 4:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace 
 wrote:
 I did not do any research on name; just shortened 
 "debug" to "dbg" :)
 I'm bad at coming up with good names, so any suggestions 
 are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
noice
http://www.noicedebugger.com/ already exists!
I like bugD :o)
d-bugger
That'll give anyone from the UK a good laugh.
:) Maybe d-bugging works better
Jan 29 2014
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2014-01-29 at 16:55 +0000, Meta wrote:
 On Wednesday, 29 January 2014 at 16:45:20 UTC, Andrea Fontana 
[…]
 d-bugger
That'll give anyone from the UK a good laugh.
Sort of. Remember bugger is colloquially a general purpose expletive as well as being a synonym for sodomy. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 29 2014
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2014-01-29 at 16:45 +0000, Andrea Fontana wrote:
[…]
 
 d-bugger
You may want to belay that suggestion: http://en.wikipedia.org/wiki/Bugger http://www.thefreedictionary.com/bugger http://www.oxforddictionaries.com/definition/english/bugger http://www.urbandictionary.com/define.php?term=bugger -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 29 2014
parent Justin Whear <justin economicmodeling.com> writes:
On Wed, 29 Jan 2014 17:03:59 +0000, Russel Winder wrote:

 On Wed, 2014-01-29 at 16:45 +0000, Andrea Fontana wrote: […]
 
 d-bugger
You may want to belay that suggestion: http://en.wikipedia.org/wiki/Bugger http://www.thefreedictionary.com/bugger http://www.oxforddictionaries.com/definition/english/bugger http://www.urbandictionary.com/define.php?term=bugger
bugger-d Do it for the LOLs
Jan 29 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/29/14 8:20 AM, Sarath Kodali wrote:
 On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei Alexandrescu wrote:
 On 1/28/14 4:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:
 I did not do any research on name; just shortened "debug" to "dbg" :)
 I'm bad at coming up with good names, so any suggestions are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
noice
http://www.noicedebugger.com/ already exists!
"noice" = "nice" in Australian, i.e. I meant I like "Dug". See also http://bostondanceparty.deviantart.com/art/Australia-162070359 Andrei
Jan 29 2014
prev sibling next sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
+1. Same name I thought of :)


On Wed, Jan 29, 2014 at 2:26 AM, Meta <jared771 gmail.com> wrote:

 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:

 I did not do any research on name; just shortened "debug" to "dbg" :)
 I'm bad at coming up with good names, so any suggestions are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
Jan 28 2014
parent "Meta" <jared771 gmail.com> writes:
Great minds think alike ;-)

On Wednesday, 29 January 2014 at 07:07:25 UTC, Rory McGuire wrote:
 +1. Same name I thought of :)


 On Wed, Jan 29, 2014 at 2:26 AM, Meta <jared771 gmail.com> 
 wrote:

 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:

 I did not do any research on name; just shortened "debug" to 
 "dbg" :)
 I'm bad at coming up with good names, so any suggestions are 
 always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
Jan 29 2014
prev sibling parent John J <john.joyus gmail.com> writes:
On 01/28/2014 07:26 PM, Meta wrote:
 On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:
 I did not do any research on name; just shortened "debug" to "dbg" :)
 I'm bad at coming up with good names, so any suggestions are always
 welcome.

 - Sarath
D!buger
Too complicated, keep it simple. Maybe Dug, which stands for D Debug.
Dug sounds good!
Jan 29 2014
prev sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace wrote:
 I did not do any research on name; just shortened "debug" to 
 "dbg" :)
 I'm bad at coming up with good names, so any suggestions are 
 always welcome.

 - Sarath
D!buger
"!" is not a valid character for filenames, and that can be a problem when you want to... you know... name the executable. It can always be named "Dbangbugger", but that's a bit cumbersome... maybe "Dbanger"? Eh... probably not a good idea...
Jan 28 2014
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 I'm planning to release a new debugger for D sometime during 
 end of February.  This is a heads up for all those who are 
 eagerly looking for a good debugger for D.

 Here is a sample debug session:
Do you know ngdb (https://github.com/MartinNowak/ngdb)? It might be helpful for your implementation.
Jan 28 2014
parent reply "Sarath Kodali" <sarath dummy.com> writes:
On Wednesday, 29 January 2014 at 01:13:12 UTC, Martin Nowak wrote:
 On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
 I'm planning to release a new debugger for D sometime during 
 end of February.  This is a heads up for all those who are 
 eagerly looking for a good debugger for D.

 Here is a sample debug session:
Do you know ngdb (https://github.com/MartinNowak/ngdb)? It might be helpful for your implementation.
Thanks for the link, I will take a look. Is this a working debugger? - Sarath
Jan 28 2014
parent Martin Nowak <code dawg.eu> writes:
On 01/29/2014 07:37 AM, Sarath Kodali wrote:
 Thanks for the link, I will take a look. Is this a working debugger?
Kind of ;), I'm not the original author, but I fixed the build and tried to improve it a little. Although I no longer plan to work on this, the existing code might be helpful because it's a fairly simple/straightforward implementation.
Jan 30 2014