Re: Debug dmd2 using gdb 7.6 on windxp
On 28.10.2014 19:34, Zaher Dirkey wrote: On Friday, 24 October 2014 at 11:21:20 UTC, Martin Krejcirik wrote: What compiler are you using ? Maybe gdc can produce debug info compatible with gdb on Windows. If that fails, you have to use visualD, which works great. I used last one DMD2 gdc made some conflicts versions with my mingw, so i will retry it. about VisualD, is it need Visual Studio paid version? it is not worked with Express version :( Indeed, Visual D does not work with the Express versions because they don't support extensions. Instead, you can use the free Visual Studio Shell. See the installation hints here: http://rainers.github.io/visuald/visuald/Installation.html I liked D i will keep trying to use it :)
Re: Debug dmd2 using gdb 7.6 on windxp
On 31.10.2014 11:31, Zaher Dirkey wrote: Failed to install VS2010 i have links to download but icons not appears, So i downloaded VS2080 and VisualD (VisualD in c:\programs\visuald), Create new D project in c:\temp\testd (no spaces) but then i have Error in compiling -- Rebuild All started: Project: testd, Configuration: Debug Win32 -- Building Debug\testd.exe... "Debug\testd.exe_cv" not created! Building Debug\testd.exe failed! Details saved as "file://c:\temp\testd\testd\testd\Debug\testd.buildlog.html" == Rebuild All: 0 succeeded, 1 failed, 0 skipped == I guess you are using the VS shell. As explained in the installation instructions [1], VS 2008 Shell is missing the file msobj80.dll that is needed for the debug info conversion. You need to extract that from other products as the Express version. I rather recommend using the VS 2013 Shell instead, it doesn't need additional files. [1] http://rainers.github.io/visuald/visuald/Installation.html
Re: Debug dmd2 using gdb 7.6 on windxp
On 31.10.2014 16:09, Zaher Dirkey wrote: Also there is another problem i fixed, it is cv2pdb that come with VisualD, it is win64 so i installed original one form http://dsource.org/projects/cv2pdb Strange, the project does not even have an x64 configuration. It seems building with VS2013 sets the "required OS version" to 6, which is too large for XP. I'll change this...
Re: Debug dmd2 using gdb 7.6 on windxp
On 03.11.2014 15:31, Zaher Dirkey wrote: We need to add to the environment _NT_SYMBOL_PATH=srv*c:\DownstreamStore*http://msdl.microsoft.com/download/symbols Do you mean this has an influence on using cv2pdb? I would be surprised. For the Visual Studio debugger you can also set this path in Tools->Options->Debugging->Symbols. Newer versions of VS also have the symbol servers pre-configured.
Re: Debug dmd2 using gdb 7.6 on windxp
On 03.11.2014 15:50, Zaher Dirkey wrote: @ljkp I retried with the CDB, Not worked, maybe i have bad configuration for cdb debugger in CodeBlock. do i need to add like Arguments or Initialization commands? I'm not sure it was obvious but cdb is a command line version of the Microsoft windows debugger (windbg) and is not compatible with gdb. Both windbg and cdb should work with dmd compiled executables (after conversion with cv2pdb for Win32), but I guess these have not been tried lately because the VS experience is so much better... You might also be interested in switching the debug engine in the project settings to "Mago". This is a debug engine written for the D programming language, so, for example, you don't have to fall back to C syntax for watch expression.
Re: Debug in Eclipse
On 07.02.2015 16:23, karl wrote: - Visual D seems to require a full VisualStudio license, being a plugin. Microsoft just released Visual Studio Community, a free version similar to the Professional version, just limited to small companies. There has always been Visual Studio Shell, the IDE stripped of Microsoft languages, but open for extensions.
Re: VisualD/cv2pdb doesn't display AA's properly in the watch window.
On 18.02.2016 01:36, Lewis wrote: Test code (in a newly created project): import std.stdio; int main(string[] argv) { writeln("Hello Blah!"); string[string] testAA = null; testAA["test1"] = "Hello"; testAA["test2"] = "Goodbye"; testAA["blah"] = "string"; testAA["bloop"] = "another string"; testAA["words"] = "test string"; int[] testArray = null; testArray ~= 3; testArray ~= 10; testArray ~= 11; testArray ~= -2; testArray ~= 14; readln(); // Breakpoint on this line return 0; } When I check the watch window, I see the following: http://imgur.com/mxOxitP I'm using DMD 2.069.0. The project is set to use the VS debugger and cv2pdb. I'm using VS2015, with native compatibility and edit and continue enabled: http://imgur.com/6mBDtN4 The debugger displays the dynamic array just fine. It correctly identifies the AA as an aa2, complete with types, and knows its size. It just doesn't display its contents correctly. I've tried reinstalling VisualD with no luck. I've checked the autoexp.dat and the VisualD entries are there as expected. I tried mucking with autoexp.dat a bit to see if I could make it work myself, but to no avail, although that tells me VS is indeed using autoexp.dat as I'd expect. Any ideas what's going on? My suspicion is that something in D's representation of AAs changes slightly, and now the autoexp.dat just needs a tweak, but I don't know nearly enough to know what to fix myself. Thanks in advance! cv2pdb has not been updated to the new AA implementation in dmd 2.068 (http://dlang.org/changelog/2.068.0.html#aa-open-addressing) yet. That's why the type information generated by cv2pdb does not fit and autoexp.dat cannot extract the info. IIRC mago has been updated, so you might want to use this debugger engine instead.
Re: VisualD/cv2pdb doesn't display AA's properly in the watch window.
On 28.02.2016 23:43, Lewis wrote: As an aside, I noticed a quirk when viewing AAs with Mago in VS. If I have an AA of strings to structs, I can see all the keys and struct addresses no problem. However, I can't drill down further and inspect the contents of an individual struct. That being said, I can create a second watch of the form 'testAA["key"]', and now I can see the contents of that struct. Just curious if there is a technical or design limitation preventing this, or if it just never got implemented. If it's the latter, may I humbly add this as a feature request for whenever yourself or another developer who knows Mago has time? I'm guessing I'd just add an issue on the github page? I think this used to work, so I'd consider this a bug. As mago is very much considered a part of Visual D, you might want to file a bug report here for component "visuald": https://issues.dlang.org/
Re: GSoC
You probably have noticed by now, but just in case: you have posted to a very specialized forum that not a lot of people monitor. You might want to repost on the general forum: https://forum.dlang.org/group/general On 11.03.2016 21:52, Saurabh Mishra via Digitalmars-d-debugger wrote: I am interested in working with you this summer as a GSoC student. I have good knowledge of Python, Javascript and C++ (related to the mentioned pre-requisites) as well as in HTML, CSS and SQL. I feel that I fulfill the pre-requisites for working with you. I am also a part of Programming and Algorithm Group (PAG) , IIT Roorkee which is a group of coder who works on development on coding environment within campus . Regarding the GSoC application, please guide me on how to get started. Looking forward to hearing from you. Thanks and Regards, Saurabh Mishra
Re: Debugging D in windows
On 15.06.2016 19:53, moe wrote: Hi, I am trying to debug in windows. So far I am trying to use windbg like described here: http://dlang.org/windbg.html However, in windbg when using "g _Dmain" I get an error message: "No Debuggee specified". Can anybody tell me what I am missing here? I could not find anything online and I can not find any option to specify a debugger. If you know about better ways to debug in windows, please let me know. Forget the version of windbg that comes with dmd. It must be one of Walter's nastier jokes. If you build an executable with -m64 or -m32mscoff and -g you'll get MS compatible debug information in a PDB file. This works with most debuggers like Visual Studio, more recent versions of windbg and others. Use option -gc to get slightly changed debug info that works better with the debugger as they assume to be debugging C++. If you need to build with -m32, the resulting debug info is some ancient CodeView format. This can converted by cv2pdb (https://github.com/rainers/cv2pdb) to a PDB file or debugged directly by mago (http://dsource.org/projects/mago_debugger). These tools are also part of the Visual D installation (http://rainers.github.io/visuald/visuald/StartPage.html).
Re: Debugging D in windows
On 16.06.2016 22:56, moe wrote: On Thursday, 16 June 2016 at 07:40:17 UTC, moe wrote: On Wednesday, 15 June 2016 at 21:05:43 UTC, moe wrote: Thanks for the info! I will try it tomorrow, when I have some time and give some feedback then. Ok, I have tried your suggestions. And I also followed these instructions: http://dlang.org/dmd-windows.html#environment I can't get passed this error: LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib' --- errorlevel 1104 I have also tried to change the environment variables to: LIB=C:\dmd2\lib;\dm\lib;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64 so that a path to the 'LIBCMT.lib' is included. I still seam to be missing something, but I can't figure out what. Can you give me one more hint? I still can't get past this error. It might be worth mentioning that the problem only occurs when building for 64bit with the -m64 flag. Is this a known issue? Does D have problems with 64bit on windows? The 64-bit version uses the linker and the runtime of the Visual C installation. Check the [Environment64] section in sc.ini in the dmd2\windows\bin folder: it should set the LIB environment variable to the library folder of your Visual C installation. The dmd installer usually does this automatically, but might have failed for some reason or you have opted out of detecting it. In the latter case you should open the "VS x64 Native Tools Command Prompt" to invoke dmd.
Re: [bug] error compiling dserver.d from sample
On 28.04.2017 23:23, Yohan SEROT wrote: hello, i try to compile dserver.d but i got this error : [...] Error: linker exited with status 150912056 From a french noob This is probably the wrong newsgroup for questions like this, you should use https://forum.dlang.org/group/learn instead. Regarding dserver.d: it has been updated in github recently, see https://github.com/dlang/dmd/tree/master/samples. It also needs a different command line to build, see e.g. https://github.com/dlang/dmd/blob/master/samples/win32.mak#L53
Re: For.Bin or.Exe files, how does a linker generate line numbers in debug information?
On 17.06.2017 04:17, moecmks wrote: I come from China, my English is not very high. Please forgive me. First provide the context @:debugger,IDA 6.8 @:this is my source file , only this one. import std.stdio; void main () { writeln ("Hello World"); } I've found that for.Obj, using the -c -debug -gc -m32 command always generates line number information that is seen by the debugger However, as long as the connection is exe or bin, the debugger can only see variable symbols, but no line numbers can be seen,I don't know if I've done anything wrong 0_0 this is my linker's command:$(LINK) /CO:4/DEBUG /CODEVIEW /DEBUGLINES /DEBUGMODULES:$(OBJPATH)\hello.obj $(OBJPATH)\hello.obj The debug information emitted by compiling with -m32 follows a very old CodeView 4 specification that isn't well understood by current debuggers. With cv2pdb (https://github.com/rainers/cv2pdb/releases) you can convert this debug information into a PDB file following newer standards but you'll need some components from the Microsoft tool chain to execute it. Alternatively you can compile with -m32mscoff or -m64 that will use the Microsoft linker and the MS C runtime. This will generate a PDB file directly.
Re: For.Bin or.Exe files, how does a linker generate line numbers in debug information?
On 17.06.2017 16:04, moecmks wrote: Because I used VS2012 to compile your code. There are two major errors that can not be compiled @1:Syntax errors during compilation @ for partial structure construction, grammatical errors are reported If (at = = DW_AT_data_member_location) { Stack[stackDepth++] = Location (Location:: Abs, 0, 0); } @2:Symbolic parsing during link @decodeLocation, interpretDWARFLines, and so on functions are not implemented The older project files are no longer maintained, I'm usually compiling with VS2013. @ I went to your project's Github repository, searched for these functions, added several.Cpp files added to the VS project, entered, compiled successfully, and then cv2pdb, some, EXE, and got the pdb file Then I used IDA to load the PDB file and found that not only can I see the debug line number, but also the specific source code, which is exactly what I want. I hope I've fixed these files in the repository now, too. I cannot try it, though, as I don't have VS2012 installed anymore. You've got my attention, great programmer! I hope I can ask you some questions later 0_0 You're welcome.
Re: Visual D no bp's on x64
On 18.06.2017 16:17, Mike B Johnson wrote: So, there is some issue with x64 and visual d's debugging in visual studio. That is the only file in the project. If it works on your system, keep trying until it doesn't! As you expected, its not simple to reproduce. I have not managed to do so. Could you specify a few more details: - Visual D version? - VS version? - Which Configuration selected? - dmd version? - ldc version (in case you switched to "LDC Debug")? - selected debug engine? Slightly unrelated, but one thing that often bothers me: if you open the project configuration dialog, VS doesn't always show the current configuration (but the last edited one), so you edit options that don't seem to have any effect.
Re: Visual D no bp's on x64
On 18.06.2017 16:50, Rainer Schuetze wrote: On 18.06.2017 16:17, Mike B Johnson wrote: So, there is some issue with x64 and visual d's debugging in visual studio. That is the only file in the project. If it works on your system, keep trying until it doesn't! As you expected, its not simple to reproduce. I have not managed to do so. Could you specify a few more details: - Visual D version? - VS version? - Which Configuration selected? - dmd version? - ldc version (in case you switched to "LDC Debug")? - selected debug engine? Slightly unrelated, but one thing that often bothers me: if you open the project configuration dialog, VS doesn't always show the current configuration (but the last edited one), so you edit options that don't seem to have any effect. I could produce an issue when starting the mago debugger for the first time after firing up VS2015: it showed an error, though, instead of not doing anything at all. Maybe it's a different effect of the same problem. I have added a work around that fixes it for me: https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts BTW: the output window should show whether symbols for your application have been loaded. If not, you get the behavior that you reported.
Re: Visual D no bp's on x64
On 18.06.2017 20:25, Mike B Johnson wrote: Didn't work ;/ All I get on the output wndow is " C:\Windows\System32\dbghelp.dll unloaded. The thread 0x1ea4 has exited with code -1 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). " It seems the debug engine is only attached to the process when it starts terminating. Nothing cut off at the top? Strange. Please try switching to the Visual Studio debug engine on the project debugger configuration page. This still uses mago as the D expression evaluator, but has all the other features of the VS debugger. It's actually the new and preferred way to run the debugger since the last Visual D release, especially with mixed languages.
Re: Visual D no bp's on x64
On 20.06.2017 02:05, Mike B Johnson wrote: On Sunday, 18 June 2017 at 21:02:12 UTC, Rainer Schuetze wrote: On 18.06.2017 20:25, Mike B Johnson wrote: Didn't work ;/ All I get on the output wndow is " C:\Windows\System32\dbghelp.dll unloaded. The thread 0x1ea4 has exited with code -1 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). " It seems the debug engine is only attached to the process when it starts terminating. Nothing cut off at the top? Strange. Please try switching to the Visual Studio debug engine on the project debugger configuration page. This still uses mago as the D expression evaluator, but has all the other features of the VS debugger. It's actually the new and preferred way to run the debugger since the last Visual D release, especially with mixed languages. Doesn't work. Nothing is cut off. the x86 version is loading a bunch of symbols so maybe it is just a path issue? Is so then it should print a proper error message for it. I'll try to play around with the paths and see. Did you have success debugging your x64 builds? I've committed a small change to the mago debugger, maybe it helps. There is a new installer here: https://github.com/dlang/visuald/releases/tag/v0.45.0-rc1 If that still fails: Does debugging a C++ application work? If it does, you could try exchanging the debug executable in the C++ project with the D executable and see if that can be debugged.
Re: Visual D no bp's on x64
On 18.06.2017 20:25, Mike B Johnson wrote: I could produce an issue when starting the mago debugger for the first time after firing up VS2015: it showed an error, though, instead of not doing anything at all. Maybe it's a different effect of the same problem. I have added a work around that fixes it for me: https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts BTW: the output window should show whether symbols for your application have been loaded. If not, you get the behavior that you reported. Didn't work ;/ All I get on the output wndow is " C:\Windows\System32\dbghelp.dll unloaded. The thread 0x1ea4 has exited with code -1 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). " After installing VS2017 on a fresh Win10 install I could reproduce this issue: the mago debug engine failed to load the symbols when only VS2017 is installed, because the COM-CLSID to load msdia140.dll changed. Switching to the VS debug engine worked, though. Should be fixed in the next release.
Re: Visual D no bp's on x64
On 31.07.2017 19:51, Johnson Jones wrote: On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze wrote: On 18.06.2017 20:25, Mike B Johnson wrote: [...] Didn't work ;/ All I get on the output wndow is " C:\Windows\System32\dbghelp.dll unloaded. The thread 0x1ea4 has exited with code -1 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). " After installing VS2017 on a fresh Win10 install I could reproduce this issue: the mago debug engine failed to load the symbols when only VS2017 is installed, because the COM-CLSID to load msdia140.dll changed. Switching to the VS debug engine worked, though. Should be fixed in the next release. I installed a fresh VS2017 and the latest beta visual D and same issues. As of today, was this suppose to be fixed? It hasn't been released until now: https://github.com/dlang/visuald/releases/tag/v0.45.0
Re: long strings seem to only display ""
On 06.08.2017 05:34, FoxyBrown wrote: Was having a strange debug issue until I checked the visualizer on the string and realized it was just a long string ;/ mago is showing long strings as "" making one think they are empty. instead, the first n chars should be shown with an ellipse is e.g., "This is a very long str"... I noticed this recently, too, but didn't get around to fixing it. wstring and dstring are ok, but string is limited to 200 characters. Should be fixed in the next release.
Re: Visual D structs/classes not showing in debugging (reprise)
On 06.08.2017 19:03, Johnson Jones wrote: Rainer, could you explain to me again why structs and classes are not properly shown in the debugger? The problem is that the debug information is not included by dmd in the final executable if it has been written to a library (as with your gtkd library). This is https://issues.dlang.org/show_bug.cgi?id=4014, which should be solved in dmd master. You might want to give the nightly build a try: http://nightlies.dlang.org/dmd-nightly/dmd.master.windows.7z You must add -gf to the "additional command line options" in the project configuration.
Re: Visual D no bp's on x64
On 06.08.2017 05:21, FoxyBrown wrote: On Sunday, 6 August 2017 at 03:12:22 UTC, FoxyBrown wrote: On Thursday, 3 August 2017 at 20:22:56 UTC, Johnson Jones wrote: On Thursday, 3 August 2017 at 07:06:06 UTC, Rainer Schuetze wrote: [...] Thanks! Seems to be working. well, in x86 I still get a few BP's that won't be hit every once in a while(well, happened for the first time since I've used the new release). The code looks like while(i < data.length && data[i] != '>' && data[i] != '"' && data[i..i+token2.length] != token2) i++; if (data[i] == '>') { continue; } I put a BP on the if and when ran it says it won't be hit. I have a BP right above it and below it and it works fine. says "The BP will not currently be hit. No symbols have been loaded for this document.". I do not know why symbols really matter for BP's? If I change the if statement to if (data[i] == '>') { continue; } it works ;/ Oops, it "works". The BP icon is no longer a hollow read disk but it is simply not hit ;/ I know all this doesn't help much but it all seems to be related to the previous bugs. It would be good if you could post the full function, even better a complete compilable file exposing the problem. I suspect dmd just doesn't produce proper debug information. For example "continue" is often optimized away due to some branches even removed in debug code.
Re: Visual D structs/classes not showing in debugging (reprise)
On 06.08.2017 21:41, FoxyBrown wrote: [gdk.Event.Event]D0006: Error: Type resolve failed This looks like it is showing the derived or the base type. If it is the former the name is read from memory and it is possible that is not available in the current binary. object@ObjectD0002: Error: Syntax error This looks like you have compiled part of the debug info (e.g. the gtk libraries) for the VS debugger (that doesn't like '.' in type names so they are replaced with '@'), but use the mago debugger. Please check the Compiler->Debug->Debug info option. Unfortunately "suitable for selected debug engine" doesn't make sense for libraries, so this should be chosen appropriately. This could also cause the problem above. but other than that I'm seeing stuff, and that is what's important. I'll play around with it for a few days and see. It it's working like it looks like it's working, it's gonna make things a hell of a lot easier.
Re: Visual D structs/classes not showing in debugging (reprise)
On 07.08.2017 04:25, Johnson Jones wrote: https://ibb.co/kaJAwa That shows a screen shot of the behavior. Not sure why some type are not showing while others are. They are all from gtkD. Most seem to be window. Looking at window, it looks like the only field defined is /** the main Gtk struct */ protected GdkWindow* gdkWindow; It would be nice if protected fields were shown. The real problem is that it looks like getters and setters are shown to return the data and, of course Visual D has no way to know what is what. e.g., /** the main Gtk struct as a void* */ protected override void* getStruct() { return cast(void*)gdkWindow; } or public static GType getType() { return gdk_window_get_type(); } and these are not marked in any way. I'm not sure what Visual D can do to help this situation. When debugging C++, you can call functions in the watch window. I'm hoping this will work for D, too, someday. Unfortunately, it seems with the Concord debugger integration it needs a very different approach to expression evaluation than what is currently used. A slight complication is that member functions are never zero argument function, because the this pointer has to be passed. So it always needs to respect the proper ABI to call a function. It's obvious to a human that the above functions are effectively wrappers around an internal field. I'm not sure if Visual D can determine functions that return non-void and take 0 args(i.e, getters, specially if their name starts with get) and basically treat them as a field and call the function to get their value that is inserted in the list as if it were a field seamlessly? @property functions would be the appropriate members, though that attribute is more or less deprecated. If it could, it would at least help fill out the information listed a bit rather than show {}. Then we can parse down through the data structure and see more of whats going on. e.g., public static string Name() { return "xyc"; } should ultimately, in the locals/watch/autos, be treated as if it were a field of type string with name `Name`. Not sure why a static function should be considered a field ;) @property members would fit in, though. The value, of course, can only be gotten by calling the function, which I'm not sure if the debugger can do or not while debugging and sitting on a BP?(it should, since it should know the address and these functions almost surely are safe to call in most cases. If not, it just catches the error and displays it. Obviously the function could do bad things like write to disk, etc. Instead, maybe it just list them by name and ignores the value. Maybe double clicking on it then could run the function and insert the data in to the tree. Anyways... So close but so far away ;) See also https://issues.dlang.org/show_bug.cgi?id=16692
Re: VisualD: Intellisense broke?
On 07.08.2017 19:37, Johnson Jones wrote: Tried to do some work this morning and Intellisense is not showing. Not sure what happened. Working fine yesterday. It seems that when I converted my code to automatically generate some fields, the semantic engine is not seeing them ;/ I went from something like struct X { int a; } to struct X { mixin("int a;"); } and now x. doesn't list a. (or rather, I'm using with(x) and a. does nothing (a is a struct in that case)) There surely has to be a better way to get all this stuff to work consistently? It isn't magic that's going on behind the scenes and everything ultimately has to be well defined and meaningful. mixins are magic, as they usually also involve CTFE. Did you enable "mixin analysis" in the intellisense options?
Re: Visual D Map Files
On 09.08.2017 22:16, Johnson wrote: Do generating these at all help with anything? e.g., what does full and/or cross-references do as far as the debugging experience is concerned? Does it add anything that none does as far as dmd, mago, and visual D is concerned? The map files are a human digestible log of what the linker did. It shows you what has ended up in the binary and how much space it takes up. It is not used/needed for the debugger. A machine can do nice things with it, too. Try feeding it into http://thecybershadow.net/d/mapview/
Re: VisualD: ModuleInfo Errors
On 09.08.2017 23:24, Johnson Jones wrote: I routinely get this error when I forget to add a module that I import to the project. It throughs me for a loop because the error doesn't really make sense for what is actually wrong(or does it?): Error 42: Symbol Undefined _D9DLLImport12__ModuleInfoZ (DLLImport.__ModuleInfo) Adding DLLImport.d to the project solves the problem. I guess this is due to the fact that the module does not have a library backing and the __ModuleInfo function isn't generated for it so it doesn't exist anywhere? (Just guessing) The symbol reference to the ModuleInfo is usually caused by an import. It is added to the ModuleInfo of the importing module to ensure properly ordered execution of (shared) static constructors. Only modules that have "static this()" or that import modules that have it are affected. Is there any way Visual D can help with this? Either watch out for the error(I guess this is a dmd problem) and rename it or add a hint about adding it to the project or somehow detect the modules and add them silently to the command line or even auto add them to the project? Visual D already helps a bit by demangling the symbol and adding it to the error message (the part in parenthesis is not emitted by the linker). I don't think silently trying to add modules to the command line is a good idea (follow-up errors can cause even more confusion). Making suggestions regarding missing symbols could be helpful, though. dmd already does that on Posix systems if no "main" is defined.
Re: long strings seem to only display ""
On 06.08.2017 20:32, Rainer Schuetze wrote: On 06.08.2017 05:34, FoxyBrown wrote: Was having a strange debug issue until I checked the visualizer on the string and realized it was just a long string ;/ mago is showing long strings as "" making one think they are empty. instead, the first n chars should be shown with an ellipse is e.g., "This is a very long str"... I noticed this recently, too, but didn't get around to fixing it. wstring and dstring are ok, but string is limited to 200 characters. Should be fixed in the next release. Released now in https://github.com/dlang/visuald/releases/tag/v0.45.1-rc2
Re: Debugging Visual D using Visual D
On 13.08.2017 23:14, Johnson Jones wrote: So, just to let you know, I seemed to be able to setup Visual Studio so that I can debug Visual D(with visual D). To do this: Load the experimental hive: https://blog.agchapman.com/updating-registry-settings-for-visual-studio-2017/ Load the privateregistry.bin file from %localappdata%\Microsoft\VisualStudio\15.0_[instanceid]{RootSuffix}\privateregistry.bin Modify all visual D install dirs with a location one wants to use for the debugged version, there are quite a few. I simply made a sub-dir called debug and copied the original data to that location(and, of course, made a backup). Create a way to copy the debug version of visual D to that directory(a build event, batch file, etc). Then run visual studio with /RootSuffix Exp https://msdn.microsoft.com/en-us/library/bb166560.aspx It should load a new exp visual studio using the new visual D. Now one can copy the dll without issue since they are different versions being used. Thanks for figuring this out. Maybe this can be automated with a combination of a registry import file prepared from the extensions' visuald.pkgdef and loading/unloading the private VS registry via "reg load/unload". The only thing left to do is have it automatically run visual studio on "start". There seems to be no csproj for visualD though so it can't be modified, I guess a post build event could be used. I set Visual D as the startup project and "\devenv.exe" as the target executable to debug for this project. Also, it seems that one can't disable building for a project. Visual D has several projects and I'm so used to building using F6 that I tend to rebuild the whole thing. Is it possible to get some way to disable building for a project in the solution? I just use "Build startup project" to build. Building the whole solution is ok with C#, but usually no good with larger C++ or D projects.
Re: Debugging Visual D using Visual D
On 13.08.2017 23:28, Johnson Jones wrote: One can prevent building the other projects using the configuration manager. Seems to work fine. One problem is that I cannot seem to get breakpoints to work. Same issues as I mentioned before with visual D saying the symbols haven't been loaded for the document. I do not know if it's the cross debugging issue or Visual D's issue though. What configuration are you using? I recently switched to "Debug COFF32" as it produced the slightly better experience and doesn't need the cv2pdb build step. "Debug" should be fine, too, though.
Re: Debugging Visual D using Visual D
On 14.08.2017 16:39, Johnson Jones wrote: On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze wrote: On 13.08.2017 23:28, Johnson Jones wrote: One can prevent building the other projects using the configuration manager. Seems to work fine. One problem is that I cannot seem to get breakpoints to work. Same issues as I mentioned before with visual D saying the symbols haven't been loaded for the document. I do not know if it's the cross debugging issue or Visual D's issue though. What configuration are you using? I recently switched to "Debug COFF32" as it produced the slightly better experience and doesn't need the cv2pdb build step. "Debug" should be fine, too, though. Didn't help. To try it out, simply follow the steps I mentioned about creating a separate debug install and add the build event(modify for your version of VS) \visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe" SomeDSolutionToOpenForTesting.sln /RootSuffix Exp The quick_install.bat just copies the various build files to the visual D debug install directory. e.g., copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll" "C:\Program Files (x86)\VisualD\Debug" What this does, is after a successful build, is copy the VisualD dll to the debug install version and loads up an experimental version of visual studio which uses that version if you updated it's hive, which I outlined above(takes about 3 mins to modify all the entries pointing to the original visual D install dir). After that, build visual D and it should update the debug install, launch exp VS, open a D project and be ready for testing. Then go to the first VS and attach process to the second, add BP's, such as on the backspace switch case, and then go in to the exp VS and hit backspace, it should break, but it doesn't and the BP's say there are no symbols loaded. That's how I do it for VS2013 and VS2015 aswell (without the complications of the private registry). I use the Visual D debug output directory directly, so no copying necessary. I tried it for VS2017 too, and it worked for me, too. There is obviously a pdb file. I've copied it to the debug install dir and added the debug dir as a symbols directory so there is no reason why visual studio can't find it. I've also tried different debuggers(mago, visual studio, etc). Given that this looks eerily similar to the BP problem I've experienced in the past with visual D doing normal projects(no cross debugging), it makes me believe it is a bug in visual D. Remember when I said I couldn't get any BP's for x64? You fixed that, then I've had instances where I couldn't get any for x86 after the fix. Please note that even with the (private) registry patched, it still loads Visual D twice, once from the debug directory, and once from the installation folder (see the module list). I suspect this happens because the global extension folder in %VSInstallDir%\Common7\IDE\Extensions is still scanned. Breakpoints in viewfilter.d still point to the debug DLL and work for me, though.
Re: Debugging Visual D using Visual D
On 15.08.2017 19:31, Johnson wrote: On Tuesday, 15 August 2017 at 07:01:34 UTC, Rainer Schuetze wrote: On 14.08.2017 16:39, Johnson Jones wrote: On Monday, 14 August 2017 at 06:36:22 UTC, Rainer Schuetze wrote: On 13.08.2017 23:28, Johnson Jones wrote: One can prevent building the other projects using the configuration manager. Seems to work fine. One problem is that I cannot seem to get breakpoints to work. Same issues as I mentioned before with visual D saying the symbols haven't been loaded for the document. I do not know if it's the cross debugging issue or Visual D's issue though. What configuration are you using? I recently switched to "Debug COFF32" as it produced the slightly better experience and doesn't need the cv2pdb build step. "Debug" should be fine, too, though. Didn't help. To try it out, simply follow the steps I mentioned about creating a separate debug install and add the build event(modify for your version of VS) \visuald-0.45.1-rc2\bin\Debug\quick_install.bat & "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe" SomeDSolutionToOpenForTesting.sln /RootSuffix Exp The quick_install.bat just copies the various build files to the visual D debug install directory. e.g., copy /Y "\visuald-0.45.1-rc2\bin\Debug COFF32\VisualD.dll" "C:\Program Files (x86)\VisualD\Debug" What this does, is after a successful build, is copy the VisualD dll to the debug install version and loads up an experimental version of visual studio which uses that version if you updated it's hive, which I outlined above(takes about 3 mins to modify all the entries pointing to the original visual D install dir). After that, build visual D and it should update the debug install, launch exp VS, open a D project and be ready for testing. Then go to the first VS and attach process to the second, add BP's, such as on the backspace switch case, and then go in to the exp VS and hit backspace, it should break, but it doesn't and the BP's say there are no symbols loaded. That's how I do it for VS2013 and VS2015 aswell (without the complications of the private registry). I use the Visual D debug output directory directly, so no copying necessary. I tried it for VS2017 too, and it worked for me, too. Ok, so, what I realized was that I was still using the release version of visual D to try to attach to the debugged version. I guess I should use the release version to attach to the debug version and the exp debug version to attach to the another exp debug version, or just install the debug version as default(I was trying to avoid that since I use it for other projects right now). I set it up and added C:\Program Files (x86)\VisualD to the symbols search list but no luck. Seems VS is simply not loading the pdb. (I've got it listed in several locations but it never shows up under modules) There is obviously a pdb file. I've copied it to the debug install dir and added the debug dir as a symbols directory so there is no reason why visual studio can't find it. I've also tried different debuggers(mago, visual studio, etc). Given that this looks eerily similar to the BP problem I've experienced in the past with visual D doing normal projects(no cross debugging), it makes me believe it is a bug in visual D. Remember when I said I couldn't get any BP's for x64? You fixed that, then I've had instances where I couldn't get any for x86 after the fix. Please note that even with the (private) registry patched, it still loads Visual D twice, once from the debug directory, and once from the installation folder (see the module list). I suspect this happens because the global extension folder in %VSInstallDir%\Common7\IDE\Extensions is still scanned. Well, I tried a bunch of stuff and nothing seems to work. In the modules list, VisualD.pdb is not even listed(vdextensions is but for some path like C:\s\l\... which doesn't exist on my pc). `dumpbin /headers` Dump of file visualD.pdb visualD.pdb : warning LNK4048: Invalid format file; ignored I've tried launching the experimental VS which uses the debug version to debug another experimental instance but it too has the same problem. procmon shows that visualD.pdb isn't even searched for(at least it's now showing up). This is all with debug coff as there is no pdb in for the standard debug. Here's a link to the pdb. https://ufile.io/eprlv Maybe you can run dumpbin /headers on yours and see if errors out or not. If not, then it is something in the generation of it on my side(is it using cv2pdb(207,872 bytes?)). Thanks. dumpbin cannot display PDB files. You can use cvdump.exe from https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump to do this. Your pdb file looks alright. If you compile "Debug COFF32" conversion with cv2pdb should not be done, I guess it won't even be able to find any debug info. The "Debug" configuration should create the P
Re: Debugging Visual D using Visual D
On 16.08.2017 04:49, Johnson wrote: VisualD.dllC:\Program Files (x86)\VisualD\Debug\VisualD.dll N/AYesSymbols loaded.C:\Program Files (x86)\VisualD\Debug\VisualD.pdb2290.45.1-rc212/31/1969 7:00 PM13FB-143C*[8972] devenv.exe VisualD.dllC:\Program Files (x86)\VisualD\VisualD.dllN/A YesCannot find or open the PDB file.2710.45.1-rc2 12/31/1969 7:00 PM18D4-1904E000*[8972] devenv.exe I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset. So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such. I could try to use another, different exp instance(different registry) but I feel the same problem might occur. But I guess it's better than nothing. Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching. I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration). I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet.
Re: Debugging Visual D using Visual D
On 16.08.2017 08:32, Rainer Schuetze wrote: On 16.08.2017 04:49, Johnson wrote: VisualD.dllC:\Program Files (x86)\VisualD\Debug\VisualD.dll N/AYesSymbols loaded.C:\Program Files (x86)\VisualD\Debug\VisualD.pdb2290.45.1-rc212/31/1969 7:00 PM13FB-143C*[8972] devenv.exe VisualD.dllC:\Program Files (x86)\VisualD\VisualD.dllN/A YesCannot find or open the PDB file.2710.45.1-rc2 12/31/1969 7:00 PM18D4-1904E000*[8972] devenv.exe I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset. So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such. I could try to use another, different exp instance(different registry) but I feel the same problem might occur. But I guess it's better than nothing. Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching. I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration). I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet. I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching: 1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\privateregistry.bin to make sure to start from scratch 2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\Extensions\Rainer Schuetze\VisualD" 3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL 4. start "devenv /RootSuffix Exp" 5. enable "Visual D" in the "Extensions and Updates..." dialog 6. restart VS This even doesn't load the DLL twice for me.
Re: Debugging Visual D using Visual D
On 16.08.2017 16:48, Johnson wrote: On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze wrote: On 16.08.2017 08:32, Rainer Schuetze wrote: On 16.08.2017 04:49, Johnson wrote: VisualD.dllC:\Program Files (x86)\VisualD\Debug\VisualD.dll N/AYesSymbols loaded. C:\Program Files (x86)\VisualD\Debug\VisualD.pdb229 0.45.1-rc212/31/1969 7:00 PM13FB-143C* [8972] devenv.exe VisualD.dllC:\Program Files (x86)\VisualD\VisualD.dll N/A YesCannot find or open the PDB file.271 0.45.1-rc2 12/31/1969 7:00 PM 18D4-1904E000*[8972] devenv.exe I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset. So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such. I could try to use another, different exp instance(different registry) but I feel the same problem might occur. But I guess it's better than nothing. Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching. I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration). I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet. I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching: 1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\privateregistry.bin to make sure to start from scratch 2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\Extensions\Rainer Schuetze\VisualD" 3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL 4. start "devenv /RootSuffix Exp" 5. enable "Visual D" in the "Extensions and Updates..." dialog 6. restart VS This even doesn't load the DLL twice for me. This isn't working for me, even though it looks like it should. Those values in the pkgdef are exactly the ones I replaced in the privateregistry hive, but it seems that for some reason it is not being used ;/ (since my changes are not propagating to it) This should work as this is really no different that what I was doing except it is more of the correct way. I'm not sure what's going on but I'll try and figure it out. I probably need to use a clean instance of VS It seems I have something weird going on. I have 15.0 15.0_4d0b469e 15.0_4d0b469eExp 15.0Exp which is empty except for a path containing VSTemplateStore.pkgdef and I don't believe this existed yesterday. I think I just created it with the util I used as I was trying to reset the exp instance(which I thought was the 3rd one). I'm not sure where the others came from but I'm going to create a new rootsuffix and try everything on that. I guess the 15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not loading it ;/ Ok, I ran CreateExpInstance /create /VSInstance=15.0 /RootSuffix=VisualDExp and it created a 15.0VisualDExp dir. So, looks like the 15.0Exp was what I just created and it wasn't being used when I ran /RootSuffix=Exp.. which I guess, because it didn't exist, just used the original data. I ran devenv.exe /RootStuffix VisualDExp and it created 15.0_4d0b469eVisualDExp So, something is funky. I guess 15.0_4d0b469e is the version. It loads, though, Visual D, so it is picking up the extensions from the original. This seems to be a problem with Visual Studio ;/ Yeah, so, tried with a fresh exp copied all the stuff you mentioned, checked the files and same thing. I'm using enterprise on windows 10 creators so there might be bugs. It's clearly not loading the package changes I made so either it's bugged or it's loading them from a different place. I'll try again tomorrow and see if things change ;/ Starting with VS2017, it's supposed to be possible to have different copies of VS installed. I guess the additional hex value after 15.0 is represents each of these different installations. I don't run "CreateExpInstance", I just start "devenv /RootSuffix Exp" (or another suffix) which creates 15.0_ade21380Exp for me. There is no 15.0 folder on my AppData directories. I'm on Win10.0.14393 (pre-creator), VS 2017 community.
Re: Debugging Visual D using Visual D
On 16.08.2017 21:18, Johnson Jones wrote: What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory. The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes. You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though. If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions.
Re: Debugging Visual D using Visual D
On 17.08.2017 19:05, Johnson wrote: On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote: On 16.08.2017 21:18, Johnson Jones wrote: What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory. The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes. You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though. If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions. I completely removed the `Extensions\Rainer Schuetze` directories in all visual studio folders that I know of: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\IDE\Extensions C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp Running visual studio still loads Visual D. It seems that it doesn't even use the visuald.pkgdef. Obviously I have those entries in the registry. Which it seems it pulls from and either doesn't use the extensions folder at all on my system or is overridden by the registry entries? If that's the case, how can it be worked around? If not, what else might it be? If visuald.pkgdef is suppose to be what visual studio uses to load visual D as an extension, does it import that in to the registry and then use the registry or does it always use the pkgdef file?(which doesn't seem to be the case, as, again, visual D is loading with visual studio without any of those pkgdef's) What I'm afraid of is that deleting the registry keys will not do any good, they will just be re-imported by loading the pkgdef(or not, in which case Visual D won't be found at all) and then the main registry keys will be used for the Exp, like it is now. Basically visual studio is not loading the pkgdef files either at all or only once, or every time but not allow them to overwrite the registry keys, or something else is going on that I can't seem to figure out. I think you are right that VS imports the settings from the pkgdef only once, then uses the registry only. Maybe try deleting the cache files in "%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".
Re: Debugging Visual D using Visual D
On 18.08.2017 00:14, Johnson Jones wrote: On Thursday, 17 August 2017 at 21:18:35 UTC, Johnson Jones wrote: On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze wrote: On 17.08.2017 19:05, Johnson wrote: On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote: On 16.08.2017 21:18, Johnson Jones wrote: What's strange is that with your changes, privateregistry seems to use them... but it still loads the old(I think) visualD because when I try the debug the BP's are not hit and the module shows the original visualD directory. The Visual D installer adds the extension to the VS installation ("c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD") so it is immediately available for all users and suffixes. You can move it to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though. If you run "devenv /RootSuffix Exp /Log" VS writes a log into "%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions. I completely removed the `Extensions\Rainer Schuetze` directories in all visual studio folders that I know of: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\IDE\Extensions C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp Running visual studio still loads Visual D. It seems that it doesn't even use the visuald.pkgdef. Obviously I have those entries in the registry. Which it seems it pulls from and either doesn't use the extensions folder at all on my system or is overridden by the registry entries? If that's the case, how can it be worked around? If not, what else might it be? If visuald.pkgdef is suppose to be what visual studio uses to load visual D as an extension, does it import that in to the registry and then use the registry or does it always use the pkgdef file?(which doesn't seem to be the case, as, again, visual D is loading with visual studio without any of those pkgdef's) What I'm afraid of is that deleting the registry keys will not do any good, they will just be re-imported by loading the pkgdef(or not, in which case Visual D won't be found at all) and then the main registry keys will be used for the Exp, like it is now. Basically visual studio is not loading the pkgdef files either at all or only once, or every time but not allow them to overwrite the registry keys, or something else is going on that I can't seem to figure out. I think you are right that VS imports the settings from the pkgdef only once, then uses the registry only. Maybe try deleting the cache files in "%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions". Ok, It seems to be caching. I deleted everything in the main registry related to visualD and ran visual studio and it was still there! Searched on line and came up with devenv updateconfiguration, reran VS, and VisualD was no longer there! Ran experimental and it's still there! Used the same process to remove it from Exp. So, this surely has to be caching, although I removed all the cache files I could fine from both versions. As of this point there is nothing related to visualD in the registry nor the VS folders as far as I can tell and both versions are not finding visualD. I will copy the modified pkgdef file to the exp dir and run it: Did nothing, Vi sual D didn't load! Copied the original pkgdef, no go. Seems Visual studio is not using the pkgdef in C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer Schuetze\VisualD I put the extensions folder in all the visual studio versions in that base dir and it didn't help(so it's not using any directory in C:\Users\Main\AppData\Local\Microsoft\VisualStudio). Of course, at this point it means something is fubar'ed. I went ahead and installed latest VD so I could get some work done. Seems like no problem. So either visual studio is not doing what it's suppose to or it has more cache files laying around that I failed to delete, unless you see something different? [Just me going step by step for reference: I should mention that after installing the latest, Visual D also gets installed in the Exp version ;/ so it "magically" propagated to it. The evidence seems to point to visual studio simply loading visual D from the system registry and completely bypassing everything else. It doesn't even look at the pkgdef's(or looked at them once and installed them, then uses the registry thereafter). Does the visualD installer install registry keys? or just the pkgdef file and then somehow informs VS and then VS does it? My guess is that Visual D installs the registr
Re: Problem with BP's
On 18.08.2017 00:41, Johnson Jones wrote: I was doing something strange ;/ I had code like mixin(import("Myfile.d")); CallSomeFunctionInMyFile(); And no BP's could be hit in side the function call. D would say that there was an error in the symbols for the project. debugging mixins is not really supported by the compiler. It generates source filenames that don't exist. but making MyFile.d a module(adding module MyFile; at the top) and doing import Myfile; CallSomeFunctionInMyFile(); Allowed the breakpoints to be hit. That would the normal usage, too. I guess this is a related problem with mixin debugging, which still doesn't work for me. In a sense, it might be a good why to debug them because the file exists already and one doesn't have to have it generated by the compiler to debug. This should help get the symbols and line numbers correct and the line mappings. Might help make a seemless way to debug them. e.g., any BP's in Myfile.d have to be translated to the original file they are mixed in at and vice versa when debugging them(open Myfile D).
Re: Problem with BP's
On 18.08.2017 02:05, Johnson Jones wrote: On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote: On Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones wrote: I was doing something strange ;/ I had code like mixin(import("Myfile.d")); CallSomeFunctionInMyFile(); And no BP's could be hit in side the function call. D would say that there was an error in the symbols for the project. but making MyFile.d a module(adding module MyFile; at the top) and doing import Myfile; CallSomeFunctionInMyFile(); Allowed the breakpoints to be hit. I guess this is a related problem with mixin debugging, which still doesn't work for me. In a sense, it might be a good why to debug them because the file exists already and one doesn't have to have it generated by the compiler to debug. This should help get the symbols and line numbers correct and the line mappings. Might help make a seemless way to debug them. e.g., any BP's in Myfile.d have to be translated to the original file they are mixed in at and vice versa when debugging them(open Myfile D). Hmm, maybe that wasn't the fix, still getting the error in some cases: The error is "Unexpected symbol reader error while processing test.exe" It might have been coincidence that the above change worked or it might be that it only partially fixed it. What's strange about it is that delegates inside the function I'm calling are hit but code in the root of the function are not. void CallSomeFunctionInMyFile() { addDelegate(() { foo(); }); foo(); } The first foo will break on a BP assinged to it but the second one won't. You can try switching to the disassembly view to see where the compiler generated debug line numbers. It assumes line numbers and code offsets are always ascending. Maybe assumption doesn't hold here.
Re: Problem with BP's
On 20.08.2017 20:26, Johnson Jones wrote: On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote: On 18.08.2017 00:41, Johnson Jones wrote: I was doing something strange ;/ I had code like mixin(import("Myfile.d")); CallSomeFunctionInMyFile(); And no BP's could be hit in side the function call. D would say that there was an error in the symbols for the project. debugging mixins is not really supported by the compiler. It generates source filenames that don't exist. Yes, but in this case, it does exist! Which is why I'm saying it might be a useful feature! mixin(import(filename)) is essentially a direct insertion of filename in to the D source. Even though it internally goes through the mixin analysis of the code, it passes right through. So, If VisualD knew that, it could just link up filename in to the source and allow debugging of it. If dmd outputted all string mixins to files, then the same logic would apply. e.g., it would rewrite mixin("Hello World"); to mixin(import(temp342.d)); and temp342.d would contain "Hello World". Or it could just create a special module for it then import that directly like below, which would probably allow it to nearly work with Visual D. Visual D would just then have to know what is going on so it could dive in to the "sub-file". What I'm getting at is that it seems like very little work would have to be done to get string mixins to be debuggable... instead of trying to write some specialized mixin debugger. Dmd and Visual D already do all the heavy lifting, they just need to communicate with each other enough to make it happen. There have been a couple of implementations of this, e.g. https://github.com/dlang/dmd/pull/426 and the patch in https://issues.dlang.org/show_bug.cgi?id=5051, but didn't get merged.
Re: Debugging Visual D using Visual D
On 20.08.2017 20:32, Johnson Jones wrote: On Friday, 18 August 2017 at 06:37:44 UTC, Rainer Schuetze wrote: Glad you figured it out. I had to enable Visual D in the extension manager when using the local pkgdef. Visual D installs for all users, so I think just installing into the users AppData is not an option. VS 2017 doesn't seem to inspect the "All Users" folders. The installer is not supposed to write to the system registry for VS2017 related components. I see some bad entries for mago and two entries for marshalling some data, though, but they don't seem to have an impact on extension detection (IIRC they are needed during build). It writes a few clsID's I think. about 2 or 3, let me check... Computer\HKEY_CLASSES_ROOT\TypeLib\{002a2de9-8bb6-484d-9903-7e4ad4084715} C:\Program Files (x86)\VisualD\vdserver.tlb Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002A2DE9-8BB6-484D-980E-7E4AD4084715} C:\Program Files (x86)\VisualD\visuald.dll These are the ones referred to above that might be used during building. Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002a2de9-8bb6-484d-aa05-7e4ad4084715} C:\Program Files (x86)\VisualD\DParser\DParserCOMServer.exe This one is needed to start the semantic engine as a local COM server. Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{97348AC0-2B6B-4B99-A245-4C7E2C09D403} C:\Program Files (x86)\VisualD\Mago\MagoNatDE.dll Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MagoDebugger In theory Mago is not a VS debug engine, but a system wide COM component that can be used by other debugger frontends, too. I haven't seen another application using it, though. Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD I also had to reinstall VisualD because for x64 the debugger would not run. That probably came from me deleting one of those directories(the ones referring to mago I guess). So, I'm not sure if some of those keys are interfering with getting isolation between the VS versions or what, but it seems that Visual Studio load the registry version first before the extension package and also then caches it. This makes it impossible to actually use the isolated visual D even when everything is setup right as far as the pkgdef's. IMO all of these registry keys should have no influence on extension loading.
Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On 21.08.2017 05:24, Johnson wrote: On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote: All of a sudden I'm getting this error. All I did was comment out a huge block of code so I could check something. The code compiles but the pdb conversion gives me that error ;/ Uncommenting out the code allows it to work again. I can't see why the code I'm commenting out would give that error ;/ Deleting the code also produces the same result. It seems to be in use with GTK and event handlers. The handlers are completely isolated yet are somehow causing the problem. You won't believe this, I'm sure, but //Dialog.addOnDestroy((Widget w) { }); causes the error! Must be some serious bug! Uncommenting allows the code to build fine. I tried restarting visual D with no luck ;/ This just started happening too and a few hours ago I upgraded VS, so maybe the msobj140.dll changed and broke cv2pdb? I copied it to the cv2pdb dir so it should have no trouble finding it. I've also cleaned the dir. It seems it's doing it on about everything I change. Going to reboot to see if that helps. Unfortunately, the VS2017 15.3.1 update seems to cause quite some trouble. Bad linker (breaks TLS), bad vcvars*.bat (change current directory), and this issue, too. I guess they changed something about the (undocumented) interface to the respective DLLs.
Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On 22.08.2017 01:27, Johnson wrote: On Monday, 21 August 2017 at 06:16:49 UTC, Rainer Schuetze wrote: On 21.08.2017 05:24, Johnson wrote: On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote: [...] This just started happening too and a few hours ago I upgraded VS, so maybe the msobj140.dll changed and broke cv2pdb? I copied it to the cv2pdb dir so it should have no trouble finding it. I've also cleaned the dir. It seems it's doing it on about everything I change. Going to reboot to see if that helps. Unfortunately, the VS2017 15.3.1 update seems to cause quite some trouble. Bad linker (breaks TLS), bad vcvars*.bat (change current directory), and this issue, too. I guess they changed something about the (undocumented) interface to the respective DLLs. ;/ That sucks ;/ I guess I might just have to install VS2015, or does that have issues too? Any idea what might be the best VS version that is most compatible with Visual D? VS2013 and VS2015 should both be fine. Building Visual D is also tested on Appveyor for both, too: https://ci.appveyor.com/project/rainers/visuald
Re: Debugging phobos with VisualD
On 13.09.2017 14:06, Igor wrote: I seem to have corrupted something within my installation and I can't find how to fix it. I am convinced that earlier I was able to setup a breakpoint within some phobos module that I used and step through phobos code from my project but that doesn't work any more. Does anyone know how I can make that work again? As phobos is released without debug information, functions built into the library cannot be debugged as is. Templates should be debuggable unless the compiler can deduce from the source code that they have been instantiated in phobos, too. As a workaround you can rebuild phobos as part of the project by enabling "Build and use local version of phobos with same compiler options" in the linker options of the debug configuration.
Re: Add breakpoint conditions
On 24.09.2017 01:34, Joseph wrote: It would be nice if we could use the breakpoint conditions like only breaking after hit N times. The error message as D does not support them, but I'm sure it can! With a little love, anything is possible! This works with the mago Concord extension for the VS debugger, see http://rainers.github.io/visuald/visuald/Debugging.html#concord
Re: Visual D does not always break in function that threw.
On 27.09.2017 09:19, Psychological Cleanup wrote: On Wednesday, 27 September 2017 at 04:40:59 UTC, Psychological Cleanup wrote: It usually breaks at the calling site. The error message gives the correct module and line number but this is not the line number show in visual studio. The function does not show up in the call stack either making it difficult to debug. I'm referring to templated functions as it might not do it with normal functions. This is usually caused by the druntime functions implementing the throw not being compiled with debug info and standard stack frames. That way the debugger doesn't know how to walk the stack. You can work around this by compiling a "private" version of the D runtime by enabling "build and use local version of phobos with same compiler options" on the linker configuration page. Sometimes it also helpful to load symbols of the Windows DLLs shown in the call stack (e.g. kernel32.dll or ntdll.dll) from the Microsoft symbol server. Also, when in a C callback(using a D function), it seems that it confuses the debugger and no stack entry is shown nor are the autos or watches. The debugger just kinda goes blank now showing anything helpful like it should. Not sure about this one. Can you show an example?
Re: Crash in BP
On 02.11.2017 21:01, Mika wrote: Hi , i have a question. When i use ollydbg in some programs says the entry point is not the original ,when i attach them they not have problems , but if i wanna put a bp in any part of the program, the program crash. i don't know what i need to learn, is this a unpacking problem ?, ¿ if is this , how i need to learn to solve ? thanks for read, and srry for my bad english <3 Is this related to debugging D programs? Are you building with the default dmd tool chain or use the "-m32" switch? You should convert the debug information with cv2pdb in that case: https://github.com/rainers/cv2pdb/releases
Re: Messed up debug symbols GDB/GDC
On 07.12.2017 20:08, kk wrote: Hey so I recently got back into D a bit, but I'm having a bit of trouble with debugging. So for this minimal test file: void main() { int x = 5; int y = x * 20; float b = 6.7432143; b *= 2; } Compiled with gdc (Ubuntu 7.2.0-8ubuntu3) 7.2.0 $ gdc -g test.d -otest I get this output in gdb (gdb) b main Breakpoint 1 at 0x104f9: file /usr/lib/gcc/x86_64-linux-gnu/7/include/d/__entrypoint.di, line 44. (gdb) r Starting program: /home/kyoji/ProgrammingTests/dlang/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main (argc=1, argv=0x7fffdd78) at /usr/lib/gcc/x86_64-linux-gnu/7/include/d/__entrypoint.di:44 44 return _d_run_main(argc, argv, &_Dmain); (gdb) n 45 } (gdb) __libc_start_main (main=0x555644ea , argc=1, argv=0x7fffdd78, init=, fini=, rtld_fini=, stack_end=0x7fffdd68) at ../csu/libc-start.c:342 342 ../csu/libc-start.c: No such file or directory. (gdb) [Inferior 1 (process 11211) exited normally] -- Sometimes if I reformatted the text, it would print a random line, such as 'b *= 2' but it was more less random. I also did try forcing different dwarf versions, but it was the exact same result. If I need to post anymore info please let me know. Thanks! I'm not a GDC/gdb user, but with "b main" you are breaking into the automatically generated C main function, not D's main. Try "b Dmain" or "b _Dmain" or use the source line.
Re: VisualD temp D variables showing up
On 29.12.2017 12:25, Amorphorious wrote: I am computing equations involving ^^ and about 90%, around 40, temp variables are showing up in the locals window. __powtmp5173 .712227326 double __powtmp5174 .3275114687 double __powtmp5175 1 double dist 2.017358817 double __powtmp5176 -.2647196372 double __powtmp5177 1.225902886 double __powtmp5178 .67 double __powtmp5179 5.563024167e-309 double __powtmp5180 3.613877664e-308 double __powtmp5181 1.424047271e-305 double __powtmp5182 0 double __powtmp5183 2.125183105 double __powtmp5184 3.124453764e-307 double __powtmp5185 2.769750648e+266 double __powtmp5186 1.700051445e-313 double __powtmp5187 2.826759824e-307 double __powtmp5188 1.447097644e-305 double __powtmp5189 1.295163447e-318 double __powtmp5190 1.447097644e-305 double etc. How can I remove these? I do not need to see them. If you are using mago as the debug engine (either by explicitly selecting it or via the debugger plugin; the source language in the call stack displays "D" in both cases), then you can disable them being displayed in Tools->Options->Debugger->Mago->Hide compiler generated symbols.
Re: VisualD temp D variables showing up
On 29.12.2017 13:05, Amorphorious wrote: Also, tuple display is quite verbose, can it be removed too? + [0] {__expand_field_0=-.08063807692, __expand_field_1=.4066909153, __expand_field_2=.91} std.typecons.Tuple!(double, double, double).Tuple Currently the field names are always shown. Even though this looks like a library artefact, it seems the field names are actually compiler generated, too. To the debugger, these are plain structs, but when displaying the single-line "quick-view", the internal names starting with "__" could be hidden, too, while still showing the values.
Re: VisualD temp D variables showing up
On 29.12.2017 14:46, Amorphorious wrote: Also, when I put a BP on an if statement it is not hit and Visual D says that no symbols have been loaded for the document. If I put the BP on a line that isn't an if statement, it hits the BP fine. I don't think this is a general rule, as it's working most of the time in my experience. I sometimes hit similar issues, but it's usually difficult to reduce them to manageable size. dmd is sometimes not so great at generating line number info. Can you post an example to bugzilla?
Re: Bug in VD
This works for me with dmd 2.081 for -m64 and -m32mscoff void foo() { string[] x = ["1"]; foreach(string a; x) { auto b = a; } string[] y = ["2"]; foreach(string a; y) { auto b = a; } } Please show a full example and add some details about your environment (e.g. compiler version, VS version, target architecture). On 15/09/2018 00:25, Josphe Brigmo wrote: When having two loops it seems the variables are never show if the name is already used: foreach(string a; x) { // a not shown in the locals or autos} foreach(string a; y) { // a not shown } renaming one of them to b, say, works as long as be wasn't used somewhere else.
Re: Natvis, CV8, dAssocArray
On 25/09/2018 22:08, Void-995 wrote: I almost finished my -gc for Natvis experiment (to use MS C++ Debugger from VS Code, fully translating type names from what comes from DMD frontend to valid C++ type name so Natvis works), but then I encountered dAssocArray, which has form of: void* as CodeView structure member, KeyType __key_t and ValueType __val_t as nested types. As for someone who just found about CodeView today: what is nested type, what is the deal with void*, what to do with __key_t and __val_t to get values. Nested types are types declared in another type, e.g. in C++ struct dAssocArray { typedef int __key_t; typedef long __val_t; void* ptr; }; The AA data structures are not exposed by the compiler, but the mago debugger rebuilds them from these types.
Re: Natvis, CV8, dAssocArray
On 26/09/2018 09:45, Void-995 wrote: On Wednesday, 26 September 2018 at 07:37:26 UTC, Rainer Schuetze wrote: On 25/09/2018 22:08, Void-995 wrote: I almost finished my -gc for Natvis experiment (to use MS C++ Debugger from VS Code, fully translating type names from what comes from DMD frontend to valid C++ type name so Natvis works), but then I encountered dAssocArray, which has form of: void* as CodeView structure member, KeyType __key_t and ValueType __val_t as nested types. As for someone who just found about CodeView today: what is nested type, what is the deal with void*, what to do with __key_t and __val_t to get values. Nested types are types declared in another type, e.g. in C++ struct dAssocArray { typedef int __key_t; typedef long __val_t; void* ptr; }; The AA data structures are not exposed by the compiler, but the mago debugger rebuilds them from these types. Makes sense. I've tried to move them to "member" but they obviously did not point anywhere, which is logical if that is just "typedef". Is there any way to expose real key/values from backend or get them via some Natvis magic? That's basically only thing that stops from using MS C/C++ plug-in for debugging from VS Code. Natvis support may be valuable for Linux and Mac as well, as they've added minimal support for Natvis to GDB and LLDB via their plug-in. Not sure if you can define new structs in NatVis, but the void pointer points to rt.aaA.Impl which contains an array of Buckets, and their entry member points to a std::pair<__key_t,__val_t>.
Re: Natvis, CV8, dAssocArray
On 27/09/2018 18:52, Void-995 wrote: On Wednesday, 26 September 2018 at 18:48:27 UTC, Void-995 wrote: On Wednesday, 26 September 2018 at 18:06:48 UTC, Rainer Schuetze wrote: Not sure if you can define new structs in NatVis, but the void pointer points to rt.aaA.Impl which contains an array of Buckets, and their entry member points to a std::pair<__key_t,__val_t>. Thanks, I did something like that meanwhile: https://www.dropbox.com/s/h70m4v63jxp79g1/d.natvis?dl=0 Need to take a look at other ideas as well. Of course it won't hurt to clean that up, but this one works. My C++ naming for NatVis experiment has been failed right now. Somewhere around memory allocations which are all that kind of spaghetti right now in backend of DMD. But! For x86_mscoff and x86_64 associative arrays are named just as `dAssocArray`, while slices are using full/real name from D. It's pretty easy to get it to be named as `dArray`, just as it was before. Of course, adding additional nested type to allow NatVis to know about actual type would be great as well, as for no reason it ignores pointer type and thinks it's `void*`, so we would need an additional cast in NatVis. With that simple change, next NatVis file would totally work as you expect: https://www.dropbox.com/s/t5yejma3w7cbna9/dlang.natvis?dl=0 Which might be a best we can get to make VS Code experience on Windows with DMD and debugging more comfortable. I hope it will be useful addition to D ecosystem for others as well. Reminds me of autoexp.dat, the predecessor of NatVis. With a little help from cv2pdb I managed to show slices and AAs in the C++ debugger aswell, but it was horrible to figure out as the debugger crashed if there was something unexpected in the visualizer macros, needing a bunch of workarounds. I guess this has improved with NatVis, has it? You could also capture the type of template arguments in the type name. Doesn't NatVis feature this, too? That should allow casting the slice pointer (though the debug info should be correct, too). autoexp.dat macros were also pretty slow, so showing a larger AA could cause the debugger to grind to a halt. How does NatVis perform? For a more advanced problem: show the value of `aa["7"]` in the watch window ;-)
Re: Visual D issues
On 11/10/2018 06:34, James Japherson wrote: > I've been having a lot of issues with visual D. I'm not sure if it's > just dysfunctional, has a few bugs, new bugs were introduced, or what > has happened. Some things have always been like then. I have a potential > solution though. > > I will invest quite a bit of time documenting the issues I have using > video, pictures and text, explaining why these problems are bad and even > give the source code so you can use it to help fix these problems. > > Most of these problems seem like bugs, some are inadequacies, some are > probably just incomplete features, some may be expected behavior for > some peoples workflow but doesn't work in mine. > > If I do this will you be willing to take a serious look in to these > problems and try to resolve them if we can come to an agreement that > they are problems? (and that might simply be that it is an issue on my > side if everything works as they are suppose to on yours) > > Why I'm asking is that I am extremely unproductive in D because of it's > arcane debugging problems that I seem to run in to quite often. I'm sure > if these problems could be fixed(or the major ones), I'd be far more > productive and enjoy the experience more too. > > But there is no point in me doing this if you won't or can't invest the > time(it's not a demand or insult, I just don't want to waste my time). > > I've already brought up many of these problems so you basically know > about them more or less. I realize it's hard to really know what's going > on much less fix them without really seeing the problem and knowing why > it is a problem(most of these problems have solutions but the > solutions/work-arounds are extremely time consuming compared to what the > debugger/ide can do). This is why I would invest the time to really show > these problems in detail and explain why the alternative is better(and > these things are not arcane issues I have, at least most of them). > > I realize some of these problems are not solvable in any satisfiable > sense but some are definitely needed for efficiency. Some of the harder > ones could be long term goals to work on a little at a time so they > eventually get fixed. > > Since I'm not proficient and already have too much on my plate, I can't > learn the inner workings of Visual D and try to fix these things myself, > hence why you'll have to do it if you choose to. Pedantically, Visual D has only very little influence on the debug experience, it is a combination of the compiler-generated debug information, the VS debugger and the mago debugger-plugin or mago debug-engine depending on what engine you select. > > Of course, you have none to lose to pretend that you'll invest your > time... but I hope you wouldn't do that to me. No big deal if you really > don't want to or can't. Life is more important, but if these fixes can > persist(not regress) then they should make programming in Visual D much > more friendly for most people that use it in the future. I'm interested in making the debug experience better, but I can't promise I can solve all issues. Visual D and mago are still more-or-less one-man-projects I do in my spare time. Videos are good if the issue is hard to demonstrate or not easily reproducible. Small reproducible test cases are often a lot easier to get started, though. Please post issues to https://issues.dlang.org, so they don't get lost in forum discussions.
Re: Override tostring in VisualD?
On 11/10/2018 02:03, James Japherson wrote: > I'm trying to customize the debug display values. > > I've overridden toString in my types but they are not effecting the > displayed values. It simply displays a sort of json of the type. (which > happens to be real long and contains a lot of indirections, I want to > shorten it to something meaningful like displaying the relevant values) > > Is there any? > The mago debug engine/expression evaluator plugin does not have a visualizer language to adapt the display of specific types as C++ has. The expression evaluator plugin that is used with the VS debug engine can evaluate "obj.toString()" in the watch window, though. Unfortunately, slice return values such as strings cannot be displayed for 64-bit code due to the non-standard extern(D) ABI.
Re: Debug variables showing when not in scope in Visual D
On 28/10/2018 18:35, Michelle Long wrote: > Debug variables are showing when not in scope. Is it possible to remove > them? They also show before they are actually defined in the source code. > > > > int x = 0; < BP here, y and z are shown in the locals. > > int y = 3; > { > int z = 4; > } > > // z is when when here. > > > One ends up with a huge list of variables of all the locals when they > don't even "exist". I'm using the Mago debugger. That used to work for dmd, but it seems to have regressed (still works for try/catch blocks). IIRC LDC does not emit appropriate debug information.
Re: Debug variables showing when not in scope in Visual D
On 29/10/2018 08:32, Rainer Schuetze wrote: > > > On 28/10/2018 18:35, Michelle Long wrote: >> Debug variables are showing when not in scope. Is it possible to remove >> them? They also show before they are actually defined in the source code. >> >> >> >> int x = 0; < BP here, y and z are shown in the locals. >> >> int y = 3; >> { >> int z = 4; >> } >> >> // z is when when here. >> >> >> One ends up with a huge list of variables of all the locals when they >> don't even "exist". I'm using the Mago debugger. > > That used to work for dmd, but it seems to have regressed (still works > for try/catch blocks). IIRC LDC does not emit appropriate debug information. > Sorry, I slightly misremembered. The respective debug information is only emitted by dmd if there are multiple declarations with the same variables in different scopes in the same function. This still works fine.
Re: Debug variables showing when not in scope in Visual D
On 30/10/2018 16:38, Michelle Long wrote: > On Monday, 29 October 2018 at 07:39:14 UTC, Rainer Schuetze wrote: >> >> >> On 29/10/2018 08:32, Rainer Schuetze wrote: >>> >>> >>> On 28/10/2018 18:35, Michelle Long wrote: Debug variables are showing when not in scope. Is it possible to remove them? They also show before they are actually defined in the source code. int x = 0; < BP here, y and z are shown in the locals. int y = 3; { int z = 4; } // z is when when here. One ends up with a huge list of variables of all the locals when they don't even "exist". I'm using the Mago debugger. >>> >>> That used to work for dmd, but it seems to have regressed (still works >>> for try/catch blocks). IIRC LDC does not emit appropriate debug >>> information. >>> >> >> Sorry, I slightly misremembered. The respective debug information is >> only emitted by dmd if there are multiple declarations with the same >> variables in different scopes in the same function. This still works >> fine. > > Can Visual D detect scopes while debugging? E.g., if one is at some line > can it determine properly the scope of things? e.g., what symbol is in > the current scope and what is not? > > Or is this all up to dmd? If dmd is the cause of most of these debugging > issues, should dmd give as much info as it can so the debugging > experience can be optimal? It makes no sense for a compiler to make the > debugging experience more difficult because debugging is naturally part > of the equation. > I'd consider it a dmd issue and created an enhancement request: https://issues.dlang.org/show_bug.cgi?id=19349
Re: Can't set BP in middle of line
On 30/10/2018 16:21, Michelle Long wrote: > statement1; statement2; > > Would be nice to easily be able to set a BP just on statement2 without > having to add a new line. > I haven't seen this with the VS native debugger and C++, so I doubt it is feasible.
Re: Visual D show the opening bracket info for closing bracket
On 30/10/2018 17:19, Michelle Long wrote: > For some languages the IDE will show info about a closing bracket so one > knows how it is grouped. > > The idea is that either a shadow comment is added or a popup when > highlighted/selected is shown over the closing bracket which displays > the first non-empty line above the opening bracket: > > statement > { > > } // statement > > // statement is a shadow comment(not part of the source, grayed out a > bit, or a popup) > > Helps a lot with lots of nesting and one doesn't have to manually add > them which isn't robust. > Recent versions of VS also shows similar information when hovering the indentation guides. I've created an enhancement request: https://issues.dlang.org/show_bug.cgi?id=19350
Re: Can't set BP in middle of line
On 03/11/2018 17:31, Michelle Long wrote: > On Saturday, 3 November 2018 at 08:10:37 UTC, Rainer Schuetze wrote: >> >> >> On 30/10/2018 16:21, Michelle Long wrote: >>> statement1; statement2; >>> >>> Would be nice to easily be able to set a BP just on statement2 >>> without having to add a new line. >>> >> >> I haven't seen this with the VS native debugger and C++, so I doubt it >> is feasible. > > Supposedly it is possible. When you put a BP it has a "char" value which > is usually set to 1. (you can see it in when you hover over the BP). > > Supposedly setting the value to something else allows one to do BP's in > the middle of lines. It may be only valid for certain languages though > but it is doable in some cases as you can find information online about > people doing it. > > https://stackoverflow.com/questions/36166205/setting-a-breakpoint-in-the-middle-of-a-line-with-multiple-statements These examples are with the debugger for managed code (e.g. C#), not the debug engine for native applications. I haven't yet seen any compiler (C++ or D) emit CodeView debug information that contains more than the line number.
Re: GDB demangling
On 03/12/2018 12:29, ANtlord wrote: > You can see some readable messages like > > #23 > dsymbol.modulecache.ModuleCache.addImportPaths(const(immutable(char)[][])) > (this=, paths={[0] = "/usr/include/dmd/phobos/"}) > > and some unreadable > > #22 > _D7dsymbol11modulecache11ModuleCache14addImportPathsMFxAAyaZ8scanFromMFxQqZv > (this=, root="/usr/include/dmd/phobos/") > > So please make me clear with the state of the demangling. Is it supported? The mangling has changed with dmd 2.077 to reduce the size of symbols. There is a patch for gdb/libiberty but it hasn't been merged yet AFAICT: https://github.com/ibuclaw/gdb/pull/8
Re: GDB demangling
On 04/12/2018 09:28, ANtlord wrote: > On Monday, 3 December 2018 at 22:36:43 UTC, Rainer Schuetze wrote: > >> There is a patch for gdb/libiberty but it hasn't been merged yet >> AFAICT: https://github.com/ibuclaw/gdb/pull/8 > > What is the state of the PR? As far as I see hasn't been updated since > 10 May. Some paperwork had to be done with the FSF but that is completed. I guess Iain will merge the PR before the next major update. Also, can't we use D code in gdb? I doubt this is allowed before GDC is part of the official GNU compiler suite. This is expected to happen early next year. It helps to synchronize the > demangling with the latest changes. Or it's impossible because GDB's > demangling should support several versions of dlang compiler? The new mangling is a superset of the old mangling, so demangling works for both old and new versions.
Re: Which debugger can explain InvalidMemoryOperationError?
On 17/01/2019 23:12, Victor Porton wrote: > On Thursday, 17 January 2019 at 16:37:55 UTC, Victor Porton wrote: >> After main() of my program finishes, I have this error message: >> >> core.exception.InvalidMemoryOperationError@core/exception.d(700): >> Invalid memory operation >> >> Which debugger (preferably with a GUI interface) do you suggest to >> investigate this error? >> >> I tried DDD and KDbg. >> >> In DDD when I set `catch throw InvalidMemoryOperationError` or `catch >> throw core.exception.InvalidMemoryOperationError`, the exception is >> not called nevertheless. >> >> In KDbg, I don't see any way to set an exception breakpoint, at all. >> >> I use LDC2. > > I've tried it with plain GDB 8.2. > > The following does not work: > > catch throw InvalidMemoryOperationError > catch throw core.exception.InvalidMemoryOperationError > > Despite of the above commands, the exception is not caught and so I am > unable to see the callstack which has led to the exception. > > Please help me to find a way to see the callstack in order to be able to > debug my software! You might want to set a breakpoint on function onInvalidMemoryOperationError. Probably this is the function that is throwing the error. Debugging experience will likely improve if you build the runtime library with debug information. (see https://wiki.dlang.org/Building_under_Posix).
Re: Visual D debugger crashes when expanding empty array
On 14/09/2019 21:40, Bert wrote: > Creating pointers to dynamic arrays, when the array length is 0 and the > ptr is 0 expanding it's elements will crash Visual Studio. That's the automatic dereferencing for pointers going wrong. Fixed for the next version.
Re: Thread names in Visual Studio and Mago
On 15/09/2019 20:11, Random D user wrote: > I've been trying to set thread names for debugging, but it seems Mago > just ignores all names. > > Using WinAPI function SetThreadDescription() I can get thread name to > show up in other programs (such as the very sleepy profiler), but not in > Visual Studio and Mago debugger. I also tried the exception method as > described here: > https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019 SetThreadDescription works for me (in VS2019). If you are using the visualdproj project, do not use "Mago" as the debugger, the "Visual Studio" debugger work better and have D support through a mago based expression evaluator extension. > > > core.thread.Thread also seems broken in terms of thread name. It seems > to just set a local name for the thread, but not communicate that to the > os. I suppose threads in Windows are nameless outside of debugging, so > perhaps that was just a poor d-runtime design choice. > Anyway, Mago doesn't seem to look up the d-runtime name either. > > Is there a way to show thread names in Visual Studio Mago? or is it just > unsupported. > > Also it would be cool if the d runtime would name it's threads, so that > it would be easier and faster to pick the correct one. > Please report to https://issues.dlang.org/
Re: Thread names in Visual Studio and Mago
On 18/09/2019 19:55, Random D user wrote: > On Wednesday, 18 September 2019 at 07:30:21 UTC, Rainer Schuetze wrote: >> >> >> On 15/09/2019 20:11, Random D user wrote: >>> I've been trying to set thread names for debugging, but it seems Mago >>> just ignores all names. >> >> SetThreadDescription works for me (in VS2019). >> >> If you are using the visualdproj project, do not use "Mago" as the >> debugger, the "Visual Studio" debugger work better and have D support >> through a mago based expression evaluator extension. > > Yes, I'm using VS2019. > Interesting. I indeed have been using Mago (pretty old project files too). > I did not know that "Mago" was the wrong debugger to use. I think it > used to be so that it was the preferred and more feature complete (i.e. > correct) debugger. It was preferred before the debugger extension existed (2017), and the latter only works for VS2012 and later (unlikely to be an issue now). I guess I should add that info to the combo box somehow. > > Thanks. > And what it's worth, I think you're doing high value work with Visual D, > much appreciated. > Thanks.
Re: Visual D Debugger long array expansion indexing fix
On 17/09/2019 22:04, Brett wrote: > On Tuesday, 17 September 2019 at 17:19:22 UTC, Brett wrote: >> On Tuesday, 17 September 2019 at 13:48:33 UTC, Brett wrote: >>> does things like [1000...2000] >>> >>> but then lists the values as [0], [1], ... >>> >>> Could it use the absolute values [1000], [1001], etc? >>> >>> That way one doesn't have to do mental arithmetic? >>> >>> Obviously not difficult but I see no reason to not do it. The nice thing about the current implementation is that there is no extra state but the expression to be passed around by the evaluation (a[1001] == a[1000..2000][1]), but I agree that it is a bit confusing. Maybe there is some other solution... >> >> Also, can AA arrays have their keys sorted? Lexicographical should >> work. I see no reason not to sort them, specially when the keys are >> integers, helps locate values in large arrays much easier. This can be a bit expensive for large arrays as all elements need to be read and cached before displaying the first. This is usually done incrementally by the debugger. > > And maybe add a linear index on AA's so it is easier to locate > values(and/or show length). > This would be easier, but probably not so interesting if not also sorted.
Re: Visual D dragging watch variables to memory
On 24/09/2019 01:22, Brett wrote: > Just drags a bunch of info rather than the ptr value. I guess you'll have to report to Microsoft, it's doing that for C++, too. Dragging into the memory dump instead of the address line usually works better.
Re: Visual D not showing variables
On 30/09/2019 22:09, Brett wrote: > I have quite a few variables and some are not showing up in the locals. > If I "alias" them they show up. Also alias do not show up. The variables > I'm using that do not show up are seem outer variables. I had to create > a function to do some multiple processing and some variables became > outer and now I do not see them in local. I thought this was fixed? > Only variables actually used in a nested function are captured and can be displayed as part of the locals. You can see the captures by unchecking "hide compiler generated symbols" on the mago options page.
Re: Visual D values and pointers taking lots of space
On 30/09/2019 22:09, Brett wrote: > In the debugger windows, pointers and values in hex take a lot of space. > In 64-bit this can take up a lot of room. Can there be an option to > remove the extra zero's? That's how the values are displayed for C++, too. That way you can see the size of the data type, too. > Basically any leading zeros on any numerical values should be removed. I agree, an option might be good. > > Also maybe hex values could use h instead of 0x, saving an extra char. I > realize it might cause problems with copying values but it could be > optional too. Although a h suffix is also supported when entering values, 0x is the way the language expects the values to be specified, so I'd rather stick with that.
Re: Visual D seems to have a new bug
On 01/10/2019 06:05, Brett wrote: > Variables are not showing properly. Specifically the trouble I'm having > is with this pointers. > > I have a simple struct and toString and this shows in the watches/locals > but it expands to not found: > > - this 0x028d3a7d12c8 {0x5da0e220} > - 0x5da0e220 > x D0001: Error: Expression couldn't be evaluated > > simply doing auto This = this; > > This works. > > I've noticed other weird issues in the watches and locals not showing > variables. > A test case would be helpful... I can only suspect that 'this' is stored in some register, but that it is not reflected in the debug information. It looks like your struct contains a pointer, maybe the value shown doesn't point to existing memory? Does `This` show the same pointer values, but proper fields?
Re: Visual D seems to have a new bug
On 01/10/2019 17:41, Brett wrote: > On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze wrote: >> >> >> On 01/10/2019 06:05, Brett wrote: >>> Variables are not showing properly. Specifically the trouble I'm >>> having is with this pointers. >>> >>> I have a simple struct and toString and this shows in the >>> watches/locals but it expands to not found: >>> >>> - this 0x028d3a7d12c8 {0x5da0e220} >>> - 0x5da0e220 >>> x D0001: Error: Expression couldn't be evaluated >>> >>> simply doing auto This = this; >>> >>> This works. >>> >>> I've noticed other weird issues in the watches and locals not showing >>> variables. >>> >> >> A test case would be helpful... >> >> I can only suspect that 'this' is stored in some register, but that it >> is not reflected in the debug information. It looks like your struct >> contains a pointer, maybe the value shown doesn't point to existing >> memory? Does `This` show the same pointer values, but proper fields? > > - this 0x016ff0f6b588 {0x0001} P** > + 0x0001 P* > - This {x=131071} P > > auto This = this; > > This is not showing as a pointer, this is a double pointer and seems to > be referring to the first value. > > Not sure if the address is right, probably is, seems the problem is that > this is being treating as a **. > > I don't have any reduced test case now but it should be simple to do or > find the bug I imagine. > > It literally is just > > struct P { long x; auto foo() { auto This = this; } } > > type of thing with a bunch of other stuff that is irrelevant to the > problem. > > It shouldn't matter how P is being used(I am using pointers to P in > arrays P*[] in some cases that may be throwing something off that is > malformed already). > > But clearly since `auto This = this` is correct, this is either 1. A > debugging map error(when it displays this automatically it screws up and > dereferences it twice) or 2. Or most likely 1. > > The reason being is that the code uses this and works fine so it is no > actually dereferencing junk. > > Recently you modified the code to fix a pointer bug with variables in > the watch(null values I believe) and so chances are that screwed up > this. It used to work fine so is a relatively new thing and the bug is > clearly an extra dereferencing issue and only a "visual" problem. > > I cannot easily reproduce the issue, but it might already be fixed by the same patch as the one avoiding crashes with pointers to empty arrays. You can try to replace "c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" (or similar path depending on the VS version) with the Appveyor artifact here: https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts This version also contains some of your recent suggestions.
Re: Visual D seems to have a new bug
On 02/10/2019 07:46, Brett wrote: > On Tuesday, 1 October 2019 at 18:44:37 UTC, Rainer Schuetze wrote: >> >> >> On 01/10/2019 17:41, Brett wrote: >>> On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze wrote: On 01/10/2019 06:05, Brett wrote: > Variables are not showing properly. Specifically the trouble I'm > having is with this pointers. > > I have a simple struct and toString and this shows in the > watches/locals but it expands to not found: > > - this 0x028d3a7d12c8 {0x5da0e220} > - 0x5da0e220 > x D0001: Error: Expression couldn't be evaluated > > simply doing auto This = this; > > This works. > > I've noticed other weird issues in the watches and locals not > showing variables. > A test case would be helpful... I can only suspect that 'this' is stored in some register, but that it is not reflected in the debug information. It looks like your struct contains a pointer, maybe the value shown doesn't point to existing memory? Does `This` show the same pointer values, but proper fields? >>> >>> - this 0x016ff0f6b588 {0x0001} P** >>> + 0x0001 P* >>> - This {x=131071} P >>> >>> auto This = this; >>> >>> This is not showing as a pointer, this is a double pointer and seems >>> to be referring to the first value. >>> >>> Not sure if the address is right, probably is, seems the problem is >>> that this is being treating as a **. >>> >>> I don't have any reduced test case now but it should be simple to do >>> or find the bug I imagine. >>> >>> It literally is just >>> >>> struct P { long x; auto foo() { auto This = this; } } >>> >>> type of thing with a bunch of other stuff that is irrelevant to the >>> problem. >>> >>> It shouldn't matter how P is being used(I am using pointers to P in >>> arrays P*[] in some cases that may be throwing something off that is >>> malformed already). >>> >>> But clearly since `auto This = this` is correct, this is either 1. A >>> debugging map error(when it displays this automatically it screws up >>> and dereferences it twice) or 2. Or most likely 1. >>> >>> The reason being is that the code uses this and works fine so it is >>> no actually dereferencing junk. >>> >>> Recently you modified the code to fix a pointer bug with variables in >>> the watch(null values I believe) and so chances are that screwed up >>> this. It used to work fine so is a relatively new thing and the bug >>> is clearly an extra dereferencing issue and only a "visual" problem. >>> >>> >> >> I cannot easily reproduce the issue, but it might already be fixed by >> the same patch as the one avoiding crashes with pointers to empty arrays. >> >> You can try to replace "c:\Program Files (x86)\Microsoft Visual >> Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" (or >> similar path depending on the VS version) with the >> Appveyor artifact here: >> https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts >> >> This version also contains some of your recent suggestions. > > This did not fix it ;/ I'm not 100% sure I updated correctly but it > seemed correct(The browser remembered the saved dir from last time and I > just used it and overwrote the dll). > > Surely this should be a simple bug to find? Somewhere in the code this > is automatically watched and for some reason it's type is off. > > Do you know the location of that code that you could paste a reference > to? I'll look at it and see if I can see anything. > > I wonder if you could easily modify Visual D so that one could "break" > in to it to do some debugging. It might be much easier. If, for example, > I could run a piece of code that somehow triggers debugging of Visual D > around the code being debugged(a BP of a BP in some sense) then it might > be easier. I realize that it doesn't quite work this way but if I could > just get some VisualD code to pop up in another debugger running > parallel then I could debug some of these problems myself. I have had no > success building visual D myself so if there was a debug build that > worked I could download that and use it. You don't have to compile Visual D, but mago: https://github.com/rainers/mago Ignore the readme, load MagoDbg_2010.sln into VS2013 or newer, and build Expression/MagoNatCC for configuration "Debug Static DE|Win32". Then replace the DLL in the VS debugger folder with bin\Win32\Debug\MagoNatCC.dll. If you hit an issue, you can start a new instance of VS with the mago solution and attach its debugger to the other running VS (devenv.exe). There is actually some automatic dereferencing going on (avoiding extra nesting in watches) here https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L213, https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L315 and https://github.com/rainers/mago/blob/mast
Re: Visual D seems to have a new bug
On 02/10/2019 18:04, Brett wrote: > I was able to build and copy the file and all that but when I attach and > add a BP on, say line 345 below the BP is missing and says symbols are > not loaded. I took all the pdb's and put them in a directory and added > the dir too the symbols dir in the VS options but it is still missing. > Also the "modules" are not showing any symbols for mago... all visual > studio stuff(mainly .net, not sure why they would be showing). > > "This breakpoints will not currently be hit. Symbols not loaded"... > > I use attach to process then find devenv.exe of the target D app(not the > app itself but the visual studio process running it since I imagine that > is the one running the mago dll). > Copying the pdb should not be necessary because it is referenced by the absolute path. I suspect that you have selected "Managed code" only when attaching to the process. You have to select/add "Native code".
Re: Visual D seems to have a new bug
On 01/10/2019 17:41, Brett wrote: > this 0x016ff0f6b588 {0x0001} P** > + 0x0001 P* > - This {x=131071} P > > auto This = this; > > This is not showing as a pointer, this is a double pointer and seems to > be referring to the first value. The double indirection looks bad. I don't think that mago adds indirections, it only removes some to reduce clutter. I suspect that the debug info is broken. The best tool for dumping it is https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe
Re: Visual D seems to have a new bug
On 04/10/2019 01:48, Brett wrote: > On Thursday, 3 October 2019 at 12:04:50 UTC, Rainer Schuetze wrote: >> >> On 01/10/2019 17:41, Brett wrote: >>> this 0x016ff0f6b588 {0x0001} P** >>> + 0x0001 P* >>> - This {x=131071} P >>> >>> auto This = this; >>> >>> This is not showing as a pointer, this is a double pointer and seems >>> to be referring to the first value. >> >> The double indirection looks bad. I don't think that mago adds >> indirections, it only removes some to reduce clutter. >> >> I suspect that the debug info is broken. The best tool for dumping it >> is >> https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe > > > That may very well be because I did just recently update dmd and this is > when I noticed it... I'm not sure if I updated visual d around that time > or not. Could also be due to updates of Visual Studio 2019: I just noticed that a function wasn't showing any locals. These reappear when setting the VC linker debug option to "FULL". If you are using a visualdproj project you currently have to add -L/DEBUG:FULL to the additional command line options to get the same result.
Re: Visual D can't debug programs
On 30/11/2019 19:29, SkyCloud wrote: > I'm a novice in D and VisualD. Just installed VisualD 0.51.0-beta1 (a > version with DMD/LDC compiler: > VisualD-v0.51.0-beta1-dmd-2.089.0-ldc2-1.18.0.exe > ) to Visual Studio 2019 16.3.9. It compiles and runs programs normally, > but when I try to debug with F5 key, make a breakpoint, the program just > starts and executes as there's no debugging mode (like as I pressed > Ctrl+F5). So I can't view variables' values and so on. In C++ projects > the debugger works normally, so the problem is only with VisualD. > > In fact this case is the same to: > https://forum.dlang.org/thread/htjjwfynugdshluam...@forum.dlang.org > But there was Visual Studio Code, not Visual Studio. > > Is it just because my Visual Studio is 16.3, but not 16.2, which the > current version of VisualD was aimed to? So should I just wait untill > the newer version of VisualD will support Visual Studio 16.3? > > As I'm a novice to D/VisualD, I do not know what to do. Please, help. It works here, using VS 2019 16.3.10. What project type and platform are you using? If you use the "Visual D Win32 Application" project template, the preferred selection for the debugger engine in the project configuration "Debugging" page is "Visual Studio". The "Debug Info" should be set to "Mago", though (this probably needs some cleanup as that is confusing for historic reasons). When using the "D/C++ Win32 Application" project template, the actual project type is the same as VC++ and the debugger should be starting just the same.
Re: Visual D can't debug programs
On 01/12/2019 20:19, SkyCloud wrote: > Hi! Thank you so much for the answer. Platform is Windows 7 x64. I > checked all the settings you said but unfortunately nothing works. > > I recorded a short video with my attempts to debug a program. There are > two projects (VisualD and D/C++) with each type and one pure Visual C++ > project. Debugging works only in Visual C++ as I mentioned before. > https://1drv.ms/v/s!Ar5BCn3roz_ahSoJMf5pVZTdHYGY > > I will be glad if you see it and find anything that can help me. As you can step into C main (the function calling _d_run_main), it seems that the debugger is setup correctly and is working, but doesn't accept the breakpoint set in D's main function. I suspect that it doesn't work correctly because your user folder contains non-ascii characters that might be encoded badly in the generated debug info. Try moving the project to a different folder.
Re: VisualD DParserComServer madness(100+)
On 22/02/2020 14:11, BetaDamnit wrote: > https://ibb.co/7R8wsXG > > I have no idea where they come from... I closed down VS hours ago and > just now opened the task manager and saw all of them. > > Taskkill /IM DParserCOMServer.exe /F > > does work but it is not a solution. I suspect that these are remainders of Visual Studio crashing for some reason. The server used to terminate itself after a minute of not being connected to any instance of Visual D, but that seems to no longer work...
Re: Visual D debugger tuple _expand_field
On 20/02/2020 23:03, BetaDamnit wrote: > _expand_field > > takes up a huge amount of space for no reason. I think tuple scan be > safely listed like arrays. We know they are tuples, no need to display > _expand_field=, it just takes up a lot of space in the display for no > reason, specially if there are several elements in the tuple. > This is the result of the compiler lowering the tuple to a number of variables ___field_. No info is generated about this being a structure-like compound. I have added support to the debugger to recombine these variables to an expandable array, but it wasn't actually trivial: https://github.com/rainers/mago/commit/451f856fd70a311460af1153ce1a1647059b5d89 It will be in the next release.
Re: VisualD DParserComServer madness(100+)
On 14/05/2020 11:53, Guillaume Piolat wrote: > On Sunday, 23 February 2020 at 17:24:19 UTC, Rainer Schuetze wrote: >> >> >> On 22/02/2020 14:11, BetaDamnit wrote: >>> https://ibb.co/7R8wsXG >>> >>> I have no idea where they come from... I closed down VS hours ago and >>> just now opened the task manager and saw all of them. >>> >>> Taskkill /IM DParserCOMServer.exe /F >>> >>> does work but it is not a solution. >> >> I suspect that these are remainders of Visual Studio crashing for some >> reason. The server used to terminate itself after a minute of not >> being connected to any instance of Visual D, but that seems to no >> longer work... > > Hi, I have the same problem unfortunately. It makes Visual D barely > usable, and need computer reboot after a while (didn't know about > Taskkill). Does it happen with the dmd-based engine, too?
Re: VisualD Can now execute class/struct methods __debugOverview, __debugExpaanded, __debugTextView to customize display in the debugger
On 05/07/2020 14:10, FunkyD wrote: > Can now execute class/struct methods __debugOverview, __debugExpaanded, > __debugTextView > to customize display in the debugger > > ? How does one use these I can't find anything else about them, not in > the source code. > I have added some documentation here: https://rainers.github.io/visuald/visuald/Debugging.html#customization
Re: VisualD Can now execute class/struct methods __debugOverview, __debugExpaanded, __debugTextView to customize display in the debugger
On 05/07/2020 22:25, FunkyD wrote: > On Sunday, 5 July 2020 at 18:58:50 UTC, Rainer Schuetze wrote: [...] I could not reproduce crashes with your code. > > Also, in the general options it has debug[Overview|Expanded|Visualizer]. > The help seems inconsistent with the various _debug functions. > The __debugVisualizer was an intermediate version of the name, I'll fix that. > There seems to be a bug somewhere. > > I started a different project and copied that code and it works! I > originally had it in another project. The new project has Visual Studio > x86 mixed mode set for the debugger! I thought I read that it must be mago. > > So it seems to work but there seems to be a bug that causes a crash and > does not properly handle. > > > Ok, I changed the old project back from mago to VSx86MM and it works. So > this seems to be an issue with mago. The mago debug *engine* is considered legacy for Visual Studio versions that don't have a recent "Concord" debugger, i.e. 2013 or earlier. Most of its code is shared with the mago debugger *extension*, though, but only the latter supports function execution. > > mago debugger > > can now evaluate class/struct methods/fields __debugOverview, > __debugExpanded, __debugTextView to customize display in the debugger > experimental: can now display ranges similar to arrays > some performance improvements by caching some data while the > debuggee is stopped > > > I assumed mago debugger meant for mago debugger. In any case, the crash > is not good(happens when I go from locals to watch). Might be that some of the new functionality is not properly disabled with the debug engine.
Re: Catching excecptions in the MSVC debugger when running Win64
On 27/04/2021 07:43, Lewis wrote: > Okay, I was able to get the VS debugger to catch exceptions in win64 by > adding a hack to deh_win64_posix.d so that it mimics deh_win32.d. > > I added the following code above the definition of _d_throwc(): > > ``` > import core.sys.windows.windef : DWORD; > extern(Windows) > { > void RaiseException(DWORD, DWORD, DWORD, void*); > } > ``` > > ...and I added the following to _d_throwc() itself, right after it calls > _d_createTrace(): > > ``` > template MAKE_EXCEPTION_CODE(int severity, int facility, int exception) > { > enum int MAKE_EXCEPTION_CODE = (((severity) << 30) | (1 << 29) | (0 << > 28) | ((facility) << 16) | (exception)); > } > enum int STATUS_DIGITAL_MARS_D_EXCEPTION = MAKE_EXCEPTION_CODE!(3,'D',1); > enum DWORD EXCEPTION_NONCONTINUABLE = 1; > RaiseException(STATUS_DIGITAL_MARS_D_EXCEPTION, > EXCEPTION_NONCONTINUABLE, 1, cast(void*)&h); > ``` > > With this, the debugger catches exceptions again. > > This feels like a total hack though. Presumably I'm missing an obvious > better solution? Unfortunately, the dmd backend does not use the standard exception mechanism for win64, but some homegrown one adapted from the linux exception handling. That's why the debugger does not recognize the exceptions. Your solution works for catching exceptions, but catch statements will not work with RaiseException. I guess the best option is to set a breakpoint in _d_throwc. LDC uses C++ exceptions, so your debugger should behave as expected when building with LDC.
Re: Breakpoint for EXE to DLL debugging in VisualD (all D)
On 06/05/2021 16:21, frame wrote: > Some code of my framework is reused in my DLL too because it has it's > own logic as a plugin system. > > I want to seamlessly debug from EXE to DLL inspection by running the > main application. > > If I set a breakpoint for a method in the VS debugger it generates > breakpoints for all method overloads for the main EXE and also sometimes > for the DLL too - but in most cases only for the EXE. I have tried to reproduce the issue with a simple pair of exe and DLL sharing a template in a common module, but that worked as expected (showing both function locations in the list of breakpoints). > > The breakpoint will be hit if the function name matches the process, so > it seems. > > eg.: > ```main.exe!mylib.func.get!bool.get(...)``` > ```some.dll!mylib.func.get!bool.get(...)``` > > I tried to manually insert the breakpoint as modified function name, but > that doesn't work. > I tried to export the breakpoint xml data and edit it, but I am afraid I > also need the correct function address to get this working. The mago debug extensions deals with D expressions, but not breakpoint locations. There seems to be an interface to support function name resolution, but it is not implemented yet. > > The only way it works so far is when the debugger catches an error in > loaded DLL and opens the right editor tab for it. If I set a breakpoint > then it also generates breakpoints for functions in the DLL too. > > Is there are way to select the loaded DLL when setting a breakpoint I > don't know? > In case you load the DLL dynamically, maybe it helps if you preload the DLL and it's symbols, e.g. by loading it as a direct dependency of the executable.
Re: Breakpoint for EXE to DLL debugging in VisualD (all D)
On 08/05/2021 21:44, frame wrote: > On Saturday, 8 May 2021 at 14:26:18 UTC, Rainer Schuetze wrote: > >> In case you load the DLL dynamically, maybe it helps if you preload >> the DLL and it's symbols, e.g. by loading it as a direct dependency of >> the executable. > > I can see in the module window that all symbols are already loaded, but > still no luck. > It also fails to step-by-step debugging into the exported function. > > It highly depends in which editor tab the breakpoint is set. If I select > the wrong one, only the main application gets the breakpoint. The main > problem is to open this tab in the right context in the first place. > > It's a arbitrary behavior, for some functions it works better than > others. Maybe simple functions work better than those which are created > by static type variants. > > Also weird that the debugger even opens the same code tab for different > stacks but doesn't title it. This seems to be a problem with VS too. It > would be great if VisualD could provide a debugger breakpoint list too > which allows to select the module if needed because the standard > debugger window is not very sophisticated anyway. Opening the same file twice is probably hinting at the problem: the source file references in the debug information are different, and VS thinks they are referring to different files. This probably also affects break point location resolution. What compiler are you using? What command line options? Looking at a hex listing of binary object files might reveal if source file names are represented differently.
Re: first chance exception in VisualD
On 28/07/2021 11:37, frame wrote: > Are first chance exception breakpoints throwing by assert() working in > VisualD? I have core.exceptions.AssertError enabled but it slips > through. I fancied that it worked some time ago. Not sure what happend. Dealing with exceptions in the debugger is a bit tricky: - a 64-bit executable built with dmd only generates a "priveleged instruction exception" for unhandled exceptions as dmd generated code that does not use standard exception handling - a 32-bit executable built with dmd has regular exception handling code, but uses exception code 0xe0440001 for all exceptions - the standard VS debugger with or without the mago extension cannot filter on the actual exception - only the "mago debug engine" as selected in the "Debugging" project configuration can evaluate the "D Exceptions" settings, but it might have bitrotten... - when compiling with LDC, standard C++ exceptions are generated, and you can setup exception filters in the "C++ exceptions" group tl;dr: use LDC :-)
Re: Are there any debugger functions?
On 06/01/2022 19:04, frame wrote: If a pointer has an invalid target a debugger in VS shows the error `D0001: Error: Expression couldn't be evaluated` when I try to access it. Is there a debugger function to trigger this access which can be used inside an invariant? I can assert it by checking if the pointer address is far to low, but this doesn't always work. Are you looking for something like IsBadReadPtr? See https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-isbadreadptr
Re: -checkaction=C - Debugger out of sync?
On 27/01/2022 18:32, frame wrote: @Rainer Schuetze I quote this (you have sent me somehow a private email) Sorry, I still screw this up too often since the default/button order has changed in Thunderbird. If your invariant is called from the GC during finalization, it might have to do with the debugger executing code to show structs or ranges. Are you using the visualizer methods __debugOverView, __debugExpanded, etc.? Are ranges displayed in your Auto/Local/Watch windows? No, I don't. You can try to disable implicit code execution by the debugger in Tools->Options->Debugging->Mago by unchecking options "Call struct/class..." and "Call range methods". Yes, the option `Call range methods` causes the problem! Is that still experimental in VisualD 1.2.0? Please do not enable it by default then. It's a bit dangerous because executing code automatically can mutate your program state. The default has been changed quite some time ago (https://github.com/rainers/mago/commit/8ce1bb37818ea38e88ec8ecf2439383b592fca46), so you probably picked up the enabled state as an early adopter.
Re: Global variables not accessible with Visual Studio debugger
On 21/04/2022 21:37, pdgr wrote: Hello, I have a program that I want to debug on Windows 10 using Visual Studio 2022. I'm debugging the built .exe directly (not using VisualD or anything). Without Visual D (or to be more precise: without the mago debugger extension that comes with Visual D), you are rather limited when debugging D code. The program is compiled with dmd ver v2.099.0 using the following flags: dmd main.d -debug -g -gf -gs -m64 In Visual Studio when I type the name of my global variable in the watch window it can't find it.. any way to solve this? I found some old thread that suggested using {module-name}.{global-var-name} but that doesn't work either. It might work to use the mangled name, e.g. _D3mod4namei. You can find the exact speelling in the disassembly of an access to the variable. An alternative might be to use extern(C) when declaring the variable.
Re: Global variables not accessible with Visual Studio debugger
On 23/04/2022 15:41, pdgr wrote: On Saturday, 23 April 2022 at 13:29:16 UTC, pdgr wrote: Thanks for the suggestions, the extern(C) thing doesn't work.. but in the disassembly I can see the mangled name and I can inspect the value in the watch window using that mangled name. Kinda annoying but it works. Scratch that.. it doesn't actually work: the disassembly doesn't not contain any mangled names, I mistook a hex value for the mangled name. I suspect you are trying to watch a thread local variable that uses indirect addressing. With shared or __gshared variables, you see the symbol being used as debug information, but the debugger cannot handle that as a C++ expression. You can see the mangled symbol with "pragma(msg, var.mangleof)" at compile time. Using this in the watch window shows it as a "void*", which you can then cast to your type using C++-Syntax, e.g. "*(int*)_D3mod3tlsi". I'd recommend installing Visual D including the debugger extension mago instead, though ;-)