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

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

 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

 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