GDB completions in dexed debugger GUI
For those who are not aware, GDB completion in CLI (TAB) is not just like standard bash completions, that also allows to complete using DWARF informations, very similarly to IDE completion. [Dexed-ide](https://gitlab.com/basile.b/dexed/-/releases/v3.9.20) debugger (aka "GDB Commander") now support this feature: short video demonstration: https://www.youtube.com/watch?v=hZYslYFohrI
GDB completions in dexed debugger GUI
For those who are not aware, GDB completion in CLI (TAB) is not just like standard bash completions, that also allows to complete using DWARF informations, very similarly to IDE completion. [Dexed-ide](https://gitlab.com/basile.b/dexed/-/releases/v3.9.20) debugger (aka "GDB Commander") now support this feature: short video demonstration : https://www.youtube.com/watch?v=hZYslYFohrI
Re: Dexed can be used to debug program that are not written in D
On Wednesday, 1 September 2021 at 17:08:30 UTC, Imperatorn wrote: On Friday, 27 August 2021 at 17:34:34 UTC, Basile B. wrote: Select a custom executable, that's been compiled with dwarf info (e.g -g). this custom executable has not to be related to the focused project. [...] Cool. Great job Lazarus debugger can do that too. 1. Execute > Parameters > Host application 2. in the field set the custom app 3. run this works because in theory you can debug a dll written in ObjFPC but that will be used by a "foreign" program. The feature is not explicit but that just works ;) ![](https://i.imgur.com/JqJVRI6.png) And Qt creator of course allows the same ![](https://i.imgur.com/g6AiGyR.png) using Debug > Start Debugging > Debug An External Application. In fact resricting a GDB gui to a single language makes no sense. 1. The source language does not matter or it is automatically selected (GDB only knows a few variation: C C++ Pascal Fortran etc.) 2. it's dwarf in all cases...
Dexed can be used to debug program that are not written in D
Select a custom executable, that's been compiled with dwarf info (e.g -g). this custom executable has not to be related to the focused project. ![](https://i.imgur.com/6XCONPS.png) it even has not to be written in D. For example here I debug an obscure program written using an obscure home-made language ![](https://i.imgur.com/2ZWVD1K.png) (_first time using images since cybershadow added md support so_ [_better res_](https://i.imgur.com/OYLmu8q.png) _here as I dont know how to make a clickable thumbnail_) as long as dwarf info are there this should work. Breakpoints will have for effect to load the source file. If the source file is loaded in dexed before debugging and breakpoints are put before pressing the power button, they will be handled. Signals will be handled too. they give a dialog on encounter. It proposes to cancel the break (i.e continue) or accept it to do things such as: add more bp, evaluate expressions, change the CPU register values, etc. (note: **LINUX ONLY**)
Re: Dexed debugger UI now supports inspection of the variables based on mouse motion
On Monday, 12 October 2020 at 06:36:13 UTC, Imperatorn wrote: On Tuesday, 22 September 2020 at 23:39:39 UTC, Basile B. wrote: On Sunday, 20 September 2020 at 17:13:35 UTC, Imperatorn wrote: https://forum.dlang.org/post/skqjdvgmwpqdqbpxs...@forum.dlang.org On Thursday, 13 February 2020 at 13:24:58 UTC, Basile B. wrote: On Thursday, 13 February 2020 at 09:06:26 UTC, Basile B. wrote: [...] related commit https://gitlab.com/basile.b/dexed/-/commit/7a049959214db2e8818131b6943724e2b3a15ee5 Nice work! Thanks. Since the announce I've added formatting [1] and improved expression extraction. [1] https://imgur.com/a/91sZlTi Looks awesome. Hope to get it (debugging) working on Windows It's possible to test on windows [1] now. Feedback would be appreciated as I dont have a Windows box. I dont really expect feeback on the widget *itself* as if it works, the experience should be the same as on Linux, i.e same flaws. To be honest nowadays I just use the popup to detect what is null or not, e.g on access violation. Note that automatic break on exception requires to debug in two steps [2] because the first time the active frame is too deep (it's the one of _d_throw_dwarf (dmd) or _d_throw_exception (ldc)) so you need to inspect the full back trace, but a BP on source loc pointed by item #2 or #3 and relauch again. [1] https://gitlab.com/basile.b/dexed/-/merge_requests/15#note_428820947 [2] https://gitlab.com/basile.b/dexed/-/issues/52
Re: Dexed debugger UI now supports inspection of the variables based on mouse motion
On Sunday, 20 September 2020 at 17:13:35 UTC, Imperatorn wrote: https://forum.dlang.org/post/skqjdvgmwpqdqbpxs...@forum.dlang.org On Thursday, 13 February 2020 at 13:24:58 UTC, Basile B. wrote: On Thursday, 13 February 2020 at 09:06:26 UTC, Basile B. wrote: [...] related commit https://gitlab.com/basile.b/dexed/-/commit/7a049959214db2e8818131b6943724e2b3a15ee5 Nice work! Thanks. Since the announce I've added formatting [1] and improved expression extraction. [1] https://imgur.com/a/91sZlTi
Re: Dexed debugger UI now supports inspection of the variables based on mouse motion
On Thursday, 13 February 2020 at 09:06:26 UTC, Basile B. wrote: I don't know why I havent implemented this earlier as it was quite simple. It's basically the same as when you evaluate a custom expression excepted that you use the mouse position to extract a (more or less, TBH) precise unary expression. https://imgur.com/a/e4urRY9 Only problem is that GDB requires explicit dereferences, that are normally automatic in D semantic, so big chain of identifiers wont work and display '???'. Example: for D :a.d.c.somevar GDB needs : (*a).(*d).(*c).somevar if a,d and c are classes or struct pointers. So far dexed will display __ exp: a.d.c.somevar --- (result of -data-evaluate $exp) --- (result of -data-evaluate *$exp) __ so only one dereference. And in the a.d.c.somevar example this would not work. related commit https://gitlab.com/basile.b/dexed/-/commit/7a049959214db2e8818131b6943724e2b3a15ee5
Re: Deprecation: Symbol std.traits.EnumMembers(E) if (is(E == enum)) is not visible from module enumeration because it is privately imported in module range
On Tuesday, 27 February 2018 at 16:08:02 UTC, Marc wrote: On Tuesday, 27 February 2018 at 16:07:06 UTC, Marc wrote: How do I remove this warning? I got this after the update to v2.079.0-beta.2 this is the line of warning import std.range : EnumMembers; enum countOfMembers(E) = EnumMembers!E.length; you imported the wrong module. EnumMembers in the std.traits. import std.traits : EnumMembers enum countOfMembers(E) = EnumMembers!E.length;
Re: program compiled with -g flag give no debugging symbols found on gdb.
On Tuesday, 27 February 2018 at 18:20:33 UTC, Marc wrote: What am I missing? I compiled na application with -g flag but when I do: gdb --args myapp.exe foo I get: Reading symbols from myapp.exe...(no debugging symbols found)...done. What am I missing? because for Windows no DWARF2 debug infos are generated, which are the ones GDB recognize. By default they are to the CodeView (CV) format for win32, so only cdb can be used. For win64 and mscoff32 it's yet another format (PDB). People use https://github.com/rainers/mago and https://github.com/rainers/cv2pdb to convert infos in DlangIDE and Visual D.
Hopper for low level D debug
Hopper https://www.hopperapp.com/ Is not so bad for low level debugging (à la IDA). The symbols are not demangled however. I've recently used it to check a call to SDL in a D app: https://imgur.com/a/vsJiu The integrated debugger is actually using GDB (at least on linux).