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 ;-)
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: -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: 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: 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: 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: 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: 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*));
> ```
>
> 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: 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: 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 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: 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 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 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: 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 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 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 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
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 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 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 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 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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
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 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 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 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: 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: 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: 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: 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: 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 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: 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 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: 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 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: 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 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: 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: 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: 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: 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: 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: 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.
