Debugging D?
Are debug symbols compiled with -gc stored in a separate file? Visual Studio refuses to debug my things, and windbg seems to be remarkably unhelpful.
Re: Debugging D?
Are debug symbols compiled with -gc stored in a separate file? Visual Studio refuses to debug my things Nope. Plus you need to use cv2pdb to debug with Visual
Re: Debugging D?
On 06/02/11 20:29, Sean Eskapp wrote: Are debug symbols compiled with -gc stored in a separate file? Visual Studio refuses to debug my things, and windbg seems to be remarkably unhelpful. I suggest you take a look at VisualD if you're using visual studio, it will handle converting debug info so that visual studio can understand it, and give you some intellisense. http://www.dsource.org/projects/visuald -- Robert http://octarineparrot.com/
Re: Debugging D?
== Quote from Robert Clipsham (rob...@octarineparrot.com)'s article > On 06/02/11 20:29, Sean Eskapp wrote: > > Are debug symbols compiled with -gc stored in a separate file? Visual Studio > > refuses to debug my things, and windbg seems to be remarkably unhelpful. > I suggest you take a look at VisualD if you're using visual studio, it > will handle converting debug info so that visual studio can understand > it, and give you some intellisense. > http://www.dsource.org/projects/visuald I'm using VisualD already, but the project is configured using Makefiles, and I don't want to go through the hassle of changing project configs in two locations. Is there any way to still get Visual Studio debugging information if it's a makefile project?
Re: Debugging D?
On 06/02/11 22:28, Sean Eskapp wrote: == Quote from Robert Clipsham (rob...@octarineparrot.com)'s article On 06/02/11 20:29, Sean Eskapp wrote: Are debug symbols compiled with -gc stored in a separate file? Visual Studio refuses to debug my things, and windbg seems to be remarkably unhelpful. I suggest you take a look at VisualD if you're using visual studio, it will handle converting debug info so that visual studio can understand it, and give you some intellisense. http://www.dsource.org/projects/visuald I'm using VisualD already, but the project is configured using Makefiles, and I don't want to go through the hassle of changing project configs in two locations. Is there any way to still get Visual Studio debugging information if it's a makefile project? As Trass3r said, you can run the object file through cv2pdb - I've never used this though so I can't tell you how to use it. Take a look at http://dsource.org/projects/cv2pdb for more information, I guess you just need to add another command to your make file. -- Robert http://octarineparrot.com/
Debugging D shared libraries
Calling D from Python. I have two functions in D, compiled to a shared
object on Linux using LDC (but I get same problem using DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) * delta; return t + 1.0
/ (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta; return 1.0 / (1.0 + x
* x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming that the
problem is the lack of initialization of the std.parallelism module and
hence the use of taskPool is causing a problem. I am betting I am
missing something very simple about module initialization, and that
this is not actually a bug.
Anyone any proposals?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Debugging D code with GDB
Hello,
I'm trying to use `gdb` to debug D binaries, but I'm having
trouble accessing the methods of a struct or class. It seems that
`gdb` doesn't see them.
Given the following simple example
```
// test.d
struct S
{
int x;
void myPrint() { writefln("x is %s\n", x); }
}
void main(string[] args)
{
S s;
}
```
Compile the source file with debug simbols (`dmd -g test.d
-of=test`) and open the binary with gdb (`gdb test`) and run the
following
```
break _Dmain # break at D entry point
run
ptype s
type = struct test.S {
int x;
}
print s.myPrint()
Structure has no component named myPrint.
```
As you can see, when I try to access the `myPrint()` method I get
the error
"Structure has no component named myPrint."
Looking up gdb's bugzilla, I've found this issue [0] that
basically says that gdb treats D as C code (and that would
explain why it doesn't look for function definitions inside D
structs).
A simple "fix"/"hack" to this problem is to define a helper
function that will take my symbol as a parameter and internally
call the function that I need, like below:
```
extern (C) void helper(ref S s) { s.myPrint(); }
```
While this does the job for this trivial example, it doesn't
scale for a real project.
Are there any solutions to this problem?
Looking forward to your answers,
Edi
[0] - https://sourceware.org/bugzilla/show_bug.cgi?id=22480
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder wrote: Calling D from Python. I have two functions in D, compiled to a shared object on Linux using LDC (but I get same problem using DMD). [...] I heard it crashed during the talk. Bummer. I should really be there, seeing as I live about 15 mins away. If you get a chance to talk to Alex Bishop, don't be too harsh on D to him, I'm trying to convince him to make the switch :)
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder
wrote:
Calling D from Python. I have two functions in D, compiled to a
shared object on Linux using LDC (but I get same problem using
DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) * delta;
return t + 1.0 / (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta; return
1.0 / (1.0 + x * x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming
that the problem is the lack of initialization of the
std.parallelism module and hence the use of taskPool is causing
a problem. I am betting I am missing something very simple
about module initialization, and that this is not actually a
bug.
Anyone any proposals?
Try using an explicit TaskPool and destroying it with scope(exit).
Also if using LDC, you can use global ctor/dtor to deal with the
runtime.
--->8-
extern (C) {
pragma(LDC_global_crt_ctor, 0)
void initRuntime()
{
import core.runtime;
Runtime.initialize();
}
pragma(LDC_global_crt_dtor, 0)
void deinitRuntime()
{
import core.runtime;
Runtime.terminate();
}
}
--->8-
Re: Debugging D shared libraries
On Sat, 2015-09-19 at 12:21 +, ponce via Digitalmars-d-learn wrote:
> […]
>
> Try using an explicit TaskPool and destroying it with scope(exit).
>
>
> Also if using LDC, you can use global ctor/dtor to deal with the
> runtime.
>
>
> --->8-
>
> extern (C) {
> pragma(LDC_global_crt_ctor, 0)
> void initRuntime()
> {
> import core.runtime;
> Runtime.initialize();
> }
> pragma(LDC_global_crt_dtor, 0)
> void deinitRuntime()
> {
> import core.runtime;
> Runtime.terminate();
> }
> }
>
> --->8-
>
Hummm… I now do not get a segfault, and the code runs as expected :
-) but the program never terminates. :-(
Also, what would I need to cover the DMD and the GDC situations?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 15:42:15 UTC, Russel Winder wrote: Hummm… I now do not get a segfault, and the code runs as expected : -) but the program never terminates. :-( Where is it stuck? Also, what would I need to cover the DMD and the GDC situations? I don't know. :(
Re: Debugging D shared libraries
On Sat, 2015-09-19 at 15:58 +, ponce via Digitalmars-d-learn wrote:
> On Saturday, 19 September 2015 at 15:42:15 UTC, Russel Winder
> wrote:
> >
> > Hummm… I now do not get a segfault, and the code runs as
> > expected :
> > -) but the program never terminates. :-(
>
> Where is it stuck?
I commented out the :
//pragma(LDC_global_crt_dtor, 0)
//void deinitRuntime() {
//import core.runtime: Runtime;
//Runtime.terminate();
//}
and it now works fine :-)
> >
> > Also, what would I need to cover the DMD and the GDC situations?
>
> I don't know. :(
Let's hope DMD and GDC folk chip in :-)
Sadly the:
pragma(LDC_global_crt_ctor, 0)
void initRuntime() {
import core.runtime: Runtime;
Runtime.initialize();
}
will not compile under DMD :-(
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 12:21:02 UTC, ponce wrote:
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder
wrote:
Calling D from Python. I have two functions in D, compiled to
a shared object on Linux using LDC (but I get same problem
using DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) *
delta; return t + 1.0 / (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta;
return 1.0 / (1.0 + x * x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming
that the problem is the lack of initialization of the
std.parallelism module and hence the use of taskPool is
causing a problem. I am betting I am missing something very
simple about module initialization, and that this is not
actually a bug.
Anyone any proposals?
Try using an explicit TaskPool and destroying it with
scope(exit).
Also if using LDC, you can use global ctor/dtor to deal with
the runtime.
--->8-
extern (C) {
pragma(LDC_global_crt_ctor, 0)
void initRuntime()
{
import core.runtime;
Runtime.initialize();
}
pragma(LDC_global_crt_dtor, 0)
void deinitRuntime()
{
import core.runtime;
Runtime.terminate();
}
}
--->8-
What is the difference between shared static this and the global
constructor ? Russell, if you use shared static this for dmd
does it work ? Laeeth.
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 16:25:28 UTC, Laeeth Isharc wrote: What is the difference between shared static this and the global constructor ? Russell, if you use shared static this for dmd does it work ? Laeeth. Would like to know too. On OSX I've found that shared static this() was called by Runtime.initialize(), maybe it's different on Linux.
Re: Debugging D shared libraries
On Sat, 2015-09-19 at 11:07 +, John Colvin via Digitalmars-d-learn wrote: > […] > I heard it crashed during the talk. Bummer. I should really be > there, seeing as I live about 15 mins away. If you get a chance > to talk to Alex Bishop, don't be too harsh on D to him, I'm > trying to convince him to make the switch :) With the input from ponce (*) I now have the code working. Now all is need is a time machine so as to redo the demo successfully. Doctor, where are you? Oh you are committed to be on BBC1 in two hours time. Get Alex to have a chat with me and I can show the demonstration working. (*) ponce is arguably not the most positive or constructive name to go by. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Sat, 2015-09-19 at 17:15 +0100, Russel Winder wrote:
>
[…]
> Sadly the:
>
> pragma(LDC_global_crt_ctor, 0)
> void initRuntime() {
> import core.runtime: Runtime;
> Runtime.initialize();
>}
>
> will not compile under DMD :-(
On the otherhand using a:
version(LDC) {
…
}
solves the problem.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 16:15:45 UTC, Russel Winder
wrote:
Sadly the:
pragma(LDC_global_crt_ctor, 0)
void initRuntime() {
import core.runtime: Runtime;
Runtime.initialize();
}
will not compile under DMD :-(
version(LDC){ /* ... */ }
not that it helps make things work correctly, but at least
they'll compile :)
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 16:25:28 UTC, Laeeth Isharc wrote: On Saturday, 19 September 2015 at 12:21:02 UTC, ponce wrote: [...] What is the difference between shared static this and the global constructor ? Russell, if you use shared static this for dmd does it work ? Laeeth. IIRC shared static this is only called by the runtime, so obviously you can't use it to initialise the runtime itself.
Re: Debugging D shared libraries
On Sat, 2015-09-19 at 16:25 +, Laeeth Isharc via Digitalmars-d
-learn wrote:
>
[…]
> What is the difference between shared static this and the global
> constructor ? Russell, if you use shared static this for dmd
> does it work ? Laeeth.
I had no idea what to put in a:
shared static this {
…
}
so I don't have one.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Sat, 2015-09-19 at 16:33 +, John Colvin via Digitalmars-d-learn
wrote:
> On Saturday, 19 September 2015 at 16:15:45 UTC, Russel Winder
> wrote:
> > Sadly the:
> >
> > pragma(LDC_global_crt_ctor, 0)
> > void initRuntime() {
> > import core.runtime: Runtime;
> > Runtime.initialize();
> >}
> >
> > will not compile under DMD :-(
>
> version(LDC){ /* ... */ }
>
> not that it helps make things work correctly, but at least
> they'll compile :)
Indeed, it works well. Well for LDC. DMD and GDC are still broken. My
GDC problems are deeper that this code: Debian packages seem to have
weird problems and Fedora do not package GDC.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 16:32:18 UTC, Russel Winder wrote: (*) ponce is arguably not the most positive or constructive name to go by. Friend call me like this IRL since forever. It seems to be a swear word in english?
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 16:34:05 UTC, John Colvin wrote: On Saturday, 19 September 2015 at 16:25:28 UTC, Laeeth Isharc wrote: On Saturday, 19 September 2015 at 12:21:02 UTC, ponce wrote: [...] What is the difference between shared static this and the global constructor ? Russell, if you use shared static this for dmd does it work ? Laeeth. IIRC shared static this is only called by the runtime, so obviously you can't use it to initialise the runtime itself. Aha... Is there an equivalent in dmd to the global constructor ?
Re: Debugging D shared libraries
On Sat, 2015-09-19 at 16:41 +, ponce via Digitalmars-d-learn wrote: > […] > Friend call me like this IRL since forever. > > It seems to be a swear word in english? English and Spanish meanings of the word are very different. In UK (not sure about Canada, USA, Australia, New Zealand, South Africa,…) it is generally a somewhat derogatory term. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder
wrote:
Calling D from Python. I have two functions in D, compiled to a
shared object on Linux using LDC (but I get same problem using
DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) * delta;
return t + 1.0 / (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta; return
1.0 / (1.0 + x * x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming
that the problem is the lack of initialization of the
std.parallelism module and hence the use of taskPool is causing
a problem. I am betting I am missing something very simple
about module initialization, and that this is not actually a
bug.
Anyone any proposals?
Btw have you looked at Colvin's prettypyd ? It's a nicer way to
wrap things. Just @pdef!() before functions, aggregates and
fields to wrap them.
For demos, I should also think that showing Python code in one
Jupyter cell calling D code in another is a pretty nice way to
show interop. Just need to install the pyd Magic.Your D code
can import dub libraries too.
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 17:41:39 UTC, Laeeth Isharc
wrote:
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder
wrote:
Calling D from Python. I have two functions in D, compiled to
a shared object on Linux using LDC (but I get same problem
using DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) *
delta; return t + 1.0 / (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta;
return 1.0 / (1.0 + x * x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming
that the problem is the lack of initialization of the
std.parallelism module and hence the use of taskPool is
causing a problem. I am betting I am missing something very
simple about module initialization, and that this is not
actually a bug.
Anyone any proposals?
Btw have you looked at Colvin's prettypyd ? It's a nicer way
to wrap things. Just @pdef!() before functions, aggregates and
fields to wrap them.
For demos, I should also think that showing Python code in one
Jupyter cell calling D code in another is a pretty nice way to
show interop. Just need to install the pyd Magic.Your D
code can import dub libraries too.
In particular it should just work that way as PyD should deal
with runtime initialization and the like.
https://github.com/DlangScience/PydMagic
https://github.com/DlangScience/PydMagic/blob/master/examples/test.ipynb
https://github.com/John-Colvin/ppyd
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder
wrote:
Calling D from Python. I have two functions in D, compiled to a
shared object on Linux using LDC (but I get same problem using
DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) * delta;
return t + 1.0 / (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta; return
1.0 / (1.0 + x * x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming
that the problem is the lack of initialization of the
std.parallelism module and hence the use of taskPool is causing
a problem. I am betting I am missing something very simple
about module initialization, and that this is not actually a
bug.
Anyone any proposals?
Isn't it simply that when doing some work asynchronously, as with
task pool, work is being done in other threads than the main. All
the while, you're killing the Runtime. The fact that when
removing Runtime.terminate makes the code work might support
that explanation.
Re: Debugging D shared libraries
Dne 19. 9. 2015 v 18:41 Russel Winder via Digitalmars-d-learn napsal(a): > Indeed, it works well. Well for LDC. DMD and GDC are still broken. My > GDC problems are deeper that this code: Debian packages seem to have > weird problems and Fedora do not package GDC. All I need to do to make your example work, is to move the calls of Runtime.initialize and Runtime.terminate to a wrapper functions called at the start and end of the main program. -- mk
Re: Debugging D shared libraries
Am Sat, 19 Sep 2015 17:41:41 +0100
schrieb Russel Winder via Digitalmars-d-learn
:
> On Sat, 2015-09-19 at 16:33 +, John Colvin via Digitalmars-d-learn
> wrote:
> > On Saturday, 19 September 2015 at 16:15:45 UTC, Russel Winder
> > wrote:
> > > Sadly the:
> > >
> > > pragma(LDC_global_crt_ctor, 0)
> > > void initRuntime() {
> > > import core.runtime: Runtime;
> > > Runtime.initialize();
> > >}
> > >
> > > will not compile under DMD :-(
> >
> > version(LDC){ /* ... */ }
> >
> > not that it helps make things work correctly, but at least
> > they'll compile :)
>
> Indeed, it works well. Well for LDC. DMD and GDC are still broken. My
> GDC problems are deeper that this code: Debian packages seem to have
> weird problems and Fedora do not package GDC.
>
Have you tried using a newer GDC version? The debian jessie version
probably uses the 2.064.2 frontend.
I wanted to add @attribute(cctor/cdtor) support for some time now, I
even wrote the code some time but didn't push it to the main repo for
some reason. I'll put it on the TODO list but I can't work on this for
the next 2-3 weeks.
Re: Debugging D shared libraries
Am Sun, 20 Sep 2015 17:47:00 +0200
schrieb Johannes Pfau :
> Am Sat, 19 Sep 2015 17:41:41 +0100
> schrieb Russel Winder via Digitalmars-d-learn
> :
>
> > On Sat, 2015-09-19 at 16:33 +, John Colvin via
> > Digitalmars-d-learn wrote:
> > > On Saturday, 19 September 2015 at 16:15:45 UTC, Russel Winder
> > > wrote:
> > > > Sadly the:
> > > >
> > > > pragma(LDC_global_crt_ctor, 0)
> > > > void initRuntime() {
> > > > import core.runtime: Runtime;
> > > > Runtime.initialize();
> > > >}
> > > >
> > > > will not compile under DMD :-(
> > >
> > > version(LDC){ /* ... */ }
> > >
> > > not that it helps make things work correctly, but at least
> > > they'll compile :)
> >
> > Indeed, it works well. Well for LDC. DMD and GDC are still broken.
> > My GDC problems are deeper that this code: Debian packages seem to
> > have weird problems and Fedora do not package GDC.
> >
>
> Have you tried using a newer GDC version? The debian jessie version
> probably uses the 2.064.2 frontend.
>
> I wanted to add @attribute(cctor/cdtor) support for some time now, I
> even wrote the code some time but didn't push it to the main repo for
> some reason. I'll put it on the TODO list but I can't work on this for
> the next 2-3 weeks.
Just realized this thread is titled "Debugging D shared libraries" ;-)
GDC does not yet support shared libraries.
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 17:02:37 UTC, Russel Winder wrote: English and Spanish meanings of the word are very different. In UK (not sure about Canada, USA, Australia, New Zealand, South Africa,…) it is generally a somewhat derogatory term. In French it means "to rub down with abrasive paper".
Re: Debugging D shared libraries
On Sun, 2015-09-20 at 17:47 +0200, Johannes Pfau via Digitalmars-d -learn wrote: > Am Sat, 19 Sep 2015 17:41:41 +0100 > […] > > Have you tried using a newer GDC version? The debian jessie version > probably uses the 2.064.2 frontend. Debian Jessie is far too out of date to be useful. I'm on Debian Sid (still quite old), and Fedora Rawhide (not quite so old). Sadly GDC on Debian Sid tells me 5.2.1 20150911 which may well tell Iain which DMD is being used, but I haven't a clue. :-) […] The real problem using GDC is: gdc -I. -O3 -fPIC -c -o processAll_library_d.o processAll_library_d.d /usr/include/d/core/stdc/config.d:28:3: error: static if conditional cannot be at global scope static if( (void*).sizeof > int.sizeof ) ^ I haven't had chance to sit down and see if this is reasonable or not. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Sun, 2015-09-20 at 17:49 +0200, Johannes Pfau via Digitalmars-d -learn wrote: > […] > > Just realized this thread is titled "Debugging D shared libraries" ; > -) > GDC does not yet support shared libraries. Conversely I thought it did due to the GCC toolchain thingy. I'm using DMD and LDC just now so I have no actual data. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Sun, 2015-09-20 at 07:49 +, rom via Digitalmars-d-learn wrote:
>
[…]
> > works entirely fine. However the "parallel" code:
> >
> > extern(C)
> > double parallel(const int n, const double delta) {
> > Runtime.initialize();
> > const pi = 4.0 * delta * taskPool.reduce!"a + b"(
> > map!((int i){ immutable x = (i - 0.5) * delta; return
> > 1.0 / (1.0 + x * x); })(iota(1, n + 1)));
> > Runtime.terminate();
> > return pi;
> > }
> >
[…]
>
> Isn't it simply that when doing some work asynchronously, as with
> task pool, work is being done in other threads than the main. All
> the while, you're killing the Runtime. The fact that when
> removing Runtime.terminate makes the code work might support
> that explanation.
I am not sure that can be the case per se as reduce only uses threads
internally, the task pool operations should be complete by the time pi
is initialized. On the other hand there might be a lock contention
between a quiescent default task pool and the terminate code.
The code is now moved on a bit from the above, and it works sufficient
for the task at hand. This isn't production code so it doesn't have to
be quite as good and correct as maybe it should be.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Debugging D shared libraries
On Tuesday, 22 September 2015 at 14:37:11 UTC, Russel Winder wrote: On Sun, 2015-09-20 at 17:47 +0200, Johannes Pfau via Digitalmars-d -learn wrote: [...] […] [...] Debian Jessie is far too out of date to be useful. I'm on Debian Sid (still quite old), and Fedora Rawhide (not quite so old). Sadly GDC on Debian Sid tells me 5.2.1 20150911 which may well tell Iain which DMD is being used, but I haven't a clue. :-) […] The real problem using GDC is: gdc -I. -O3 -fPIC -c -o processAll_library_d.o processAll_library_d.d /usr/include/d/core/stdc/config.d:28:3: error: static if conditional cannot be at global scope static if( (void*).sizeof > int.sizeof ) ^ I haven't had chance to sit down and see if this is reasonable or not. seeing as it's an error in core.stdc.config, I'd say it's definitely not reasonable
Re: Debugging D shared libraries
Am Tue, 22 Sep 2015 14:40:43 + schrieb John Colvin : > On Tuesday, 22 September 2015 at 14:37:11 UTC, Russel Winder > wrote: > > On Sun, 2015-09-20 at 17:47 +0200, Johannes Pfau via > > Digitalmars-d -learn wrote: > >> [...] > > […] > >> [...] > > > > Debian Jessie is far too out of date to be useful. I'm on > > Debian Sid > > (still quite old), and Fedora Rawhide (not quite so old). > > > > Sadly GDC on Debian Sid tells me 5.2.1 20150911 which may well > > tell Iain which DMD is being used, but I haven't a clue. :-) > > > > […] > > > > The real problem using GDC is: > > > > gdc -I. -O3 -fPIC -c -o processAll_library_d.o > > processAll_library_d.d > > /usr/include/d/core/stdc/config.d:28:3: error: static if > > conditional > > cannot be at global scope > >static if( (void*).sizeof > int.sizeof ) > >^ > > > > I haven't had chance to sit down and see if this is reasonable > > or not. > > seeing as it's an error in core.stdc.config, I'd say it's > definitely not reasonable It's indeed strange. @Russel Winder if you can reproduce this with the latest GDC* please file a bug report. Even the error message doesn't make sense: static if works fine at global scope, AFAIK. * you could use the latest binaries from http://gdcproject.org/downloads
Re: Debugging D code with GDB
I found what Nemiver is much better for debugging D programs. With GDB I've got many problems, don't remember exactly. Thou I've used it through ddd, so maybe it's ddd problems, not exactly GDB's
Re: Debugging D code with GDB
On Saturday, 27 November 2021 at 14:17:11 UTC, Eduard Staniloiu
wrote:
Hello,
I'm trying to use `gdb` to debug D binaries, but I'm having
trouble accessing the methods of a struct or class. It seems
that `gdb` doesn't see them.
[...]
Looking forward to your answers,
Edi
[0] - https://sourceware.org/bugzilla/show_bug.cgi?id=22480
Hello, while I never evaluate calls during debugging I've managed
to find
a way : you can call the mangled name so for
```d
#!dmd -g
module a;
import std.stdio;
struct S
{
int myPrint(){return 8;}
}
pragma(msg, S.myPrint.mangleof);
int main(string[] args)
{
S s;
return 0;
}
```
in gdb CLI
```bash
p (int) _D1a1S7myPrintMFZi(s)
$1 = 8
```
works. Note that for some reasons writefln causes a crash, that's
why I've modified the example.
The problem is that my workaround does not scale better than your.
Re: Debugging D code with GDB
On Sunday, 28 November 2021 at 14:53:17 UTC, user1234 wrote: ... there is a plugin to demangle things automatically https://github.com/ANtlord/gdb-ddemangle
Re: Debugging D code with GDB
On Sunday, 28 November 2021 at 16:44:38 UTC, russhy wrote: On Sunday, 28 November 2021 at 14:53:17 UTC, user1234 wrote: ... there is a plugin to demangle things automatically https://github.com/ANtlord/gdb-ddemangle That's off-topic. The point here is that you can (unfortunately) **only** evaluate the call using the mangled form, it's not about transforming the output. Actually what would be useful is a plugin the mangle the call in custom expression before passing it to gdb ;)
Re: Debugging D code with GDB
On Saturday, 27 November 2021 at 14:17:11 UTC, Eduard Staniloiu
wrote:
Hello,
I'm trying to use `gdb` to debug D binaries, but I'm having
trouble accessing the methods of a struct or class. It seems
that `gdb` doesn't see them.
Given the following simple example
```
// test.d
struct S
{
int x;
void myPrint() { writefln("x is %s\n", x); }
}
void main(string[] args)
{
S s;
}
```
Compile the source file with debug simbols (`dmd -g test.d
-of=test`) and open the binary with gdb (`gdb test`) and run
the following
```
break _Dmain # break at D entry point
run
ptype s
type = struct test.S {
int x;
}
print s.myPrint()
Structure has no component named myPrint.
```
As you can see, when I try to access the `myPrint()` method I
get the error
"Structure has no component named myPrint."
DMD doesn't emit this information. GDB can't work miracles when
the compiler isn't pulling its own weight.
Re: Debugging D code with GDB
On Sun, 2021-11-28 at 21:59 +, Iain Buclaw via Digitalmars-d-learn
wrote:
> On Saturday, 27 November 2021 at 14:17:11 UTC, Eduard Staniloiu
> wrote:
> > Hello,
> >
> > I'm trying to use `gdb` to debug D binaries, but I'm having
> > trouble accessing the methods of a struct or class. It seems
> > that `gdb` doesn't see them.
> >
> > Given the following simple example
> > ```
> > // test.d
> > struct S
> > {
> > int x;
> >
> > void myPrint() { writefln("x is %s\n", x); }
> > }
> >
> > void main(string[] args)
> > {
> > S s;
> > }
> > ```
> > Compile the source file with debug simbols (`dmd -g test.d
> > -of=test`) and open the binary with gdb (`gdb test`) and run
> > the following
> >
> > ```
> > > break _Dmain # break at D entry point
> > > run
> > > ptype s
> > type = struct test.S {
> > int x;
> > }
> > > print s.myPrint()
> > Structure has no component named myPrint.
> > ```
> >
> > As you can see, when I try to access the `myPrint()` method I
> > get the error
> > "Structure has no component named myPrint."
> >
>
> DMD doesn't emit this information. GDB can't work miracles when
> the compiler isn't pulling its own weight.
I confirm this is an issue with DMD. I filed a bug in the issue
tracker, in case you want to follow:
https://issues.dlang.org/show_bug.cgi?id=22551
Anyway, DMD exports the symbol, it should work if you do something like
`myPrint(&s)`, but I think there is another problem on calling it, due
to defective calling convention on both DMD and LDC implementations.
LDC exports the symbol correctly, although.
--
Sincerely,
Luís Ferreira @ lsferreira.net
signature.asc
Description: This is a digitally signed message part
Re: Debugging D code with GDB
On Monday, 29 November 2021 at 14:48:21 UTC, Luís Ferreira wrote: On Sun, 2021-11-28 at 21:59 +, Iain Buclaw via Digitalmars-d-learn wrote: DMD doesn't emit this information. GDB can't work miracles when the compiler isn't pulling its own weight. I confirm this is an issue with DMD. I filed a bug in the issue tracker, in case you want to follow: https://issues.dlang.org/show_bug.cgi?id=22551 Anyway, DMD exports the symbol, it should work if you do something like `myPrint(&s)`, but I think there is another problem on calling it, due to defective calling convention on both DMD and LDC implementations. LDC exports the symbol correctly, although. Indeed, gdb assumes calling convention is same as default for target (actually its been years since I last looked, but are calling conventions tags in dwarf? Does gdb know about functions with thiscall or regparm attributes?) Another thing on the gdb side, it is currently missing D language support for overloads, so that the correct function would be picked when you call e.g std.math.sin(1f).
Re: Debugging D code with GDB
On Tuesday, 30 November 2021 at 09:01:38 UTC, Iain Buclaw wrote: On Monday, 29 November 2021 at 14:48:21 UTC, Luís Ferreira wrote: [...] Indeed, gdb assumes calling convention is same as default for target (actually its been years since I last looked, but are calling conventions tags in dwarf? Does gdb know about functions with thiscall or regparm attributes?) Another thing on the gdb side, it is currently missing D language support for overloads, so that the correct function would be picked when you call e.g std.math.sin(1f). So currently the workaround is they way to go. Thank you all for your help and suggestions!
Re: Debugging D code with GDB
On Tue, 2021-11-30 at 09:01 +, Iain Buclaw via Digitalmars-d-learn wrote: > On Monday, 29 November 2021 at 14:48:21 UTC, Luís Ferreira wrote: > > On Sun, 2021-11-28 at 21:59 +, Iain Buclaw via > > Digitalmars-d-learn wrote: > > > > > > DMD doesn't emit this information. GDB can't work miracles > > > when the compiler isn't pulling its own weight. > > > > I confirm this is an issue with DMD. I filed a bug in the issue > > tracker, in case you want to follow: > > https://issues.dlang.org/show_bug.cgi?id=22551 > > > > Anyway, DMD exports the symbol, it should work if you do > > something like `myPrint(&s)`, but I think there is another > > problem on calling it, due to defective calling convention on > > both DMD and LDC implementations. > > > > LDC exports the symbol correctly, although. > > Indeed, gdb assumes calling convention is same as default for > target (actually its been years since I last looked, but are > calling conventions tags in dwarf? Does gdb know about functions > with thiscall or regparm attributes?) > Yes, it is specified in 7.15. Calling Convention Encodings in DWARF standard. You can use DW_AT_calling_convention attribute to specify a certain calling convention, being DW_CC_normal the default value. But you have very limited number of calling conventions available, being the rest considered vendor-specific. You might want DW_CC_BORLAND_thiscall ? -- Sincerely, Luís Ferreira @ lsferreira.net signature.asc Description: This is a digitally signed message part
Debugging D applications from VS code with webfreak.debug
Hi everyone, as the subject says, I'm trying to get a debugger running with visual studio code on windows. I have installed WebFreak001's code-d and debug extensions but fail to figure out how to install a working debugger. The gdb I have installed is part of a MinGW installation and complains about the file format of the executable, I'm unsure if there's soemthing wrong there. I could not figure out how to obtain mago-mi to try that one, either. I'd appreciate any help or pointers to resources on how to get this running, as I otherwise really like the workflow with code-d. Cheers, FR
Debugging D in MonoDevelop, finding multiple gdb processes?
I'm new to the language and new to using MonoDevelop and I've got
this persistent problem that I haven't been able to solve with
Google searching. I frequently test out my code as I write it and
every time I start it up a new gdb process will start running but
not terminate at the end of the program. Even a nothing program
like the following will start up a new gdb process that won't
terminate:
int main( string[] args ){
return 0;
}
After testing out an application a few times I have to open my
process manager and clear out one gdb for every time I ran the
program. I'm using Linux Mint 17 x64.
Does anyone know how I can configure gdb to exit when a program
has exited successfully?
Re: Debugging D applications from VS code with webfreak.debug
On Thursday, 23 February 2017 at 16:28:26 UTC, FR wrote: Hi everyone, as the subject says, I'm trying to get a debugger running with visual studio code on windows. I have installed WebFreak001's code-d and debug extensions but fail to figure out how to install a working debugger. The gdb I have installed is part of a MinGW installation and complains about the file format of the executable, I'm unsure if there's soemthing wrong there. I could not figure out how to obtain mago-mi to try that one, either. I'd appreciate any help or pointers to resources on how to get this running, as I otherwise really like the workflow with code-d. Cheers, FR I don't know how to build mago-mi either, but you can obtain it from the bundle with dlangide https://github.com/buggins/dlangide/releases/download/v0.6.11/dlangide-v0_6_11-bin-win32_x86-magomi-v0_3_1.zip With GDB it should just work though, if you can run `gdb` from the command line. If you can only run it through some MinGW command line version, try running vscode over the command line there
Re: Debugging D applications from VS code with webfreak.debug
On Thursday, 23 February 2017 at 16:30:08 UTC, WebFreak001 wrote: I don't know how to build mago-mi either, but you can obtain it from the bundle with dlangide https://github.com/buggins/dlangide/releases/download/v0.6.11/dlangide-v0_6_11-bin-win32_x86-magomi-v0_3_1.zip Thanks, that got me somewhere. However, this executable stops working as soon as I run it from the command line. Double-clicking it from the explorer opens a gdb console. I added it to my path anyyhow, but clicking on debug in vscode with a launch.json with "type": "mago-mi" doesn't do anything. With GDB it should just work though, if you can run `gdb` from the command line. If you can only run it through some MinGW command line version, try running vscode over the command line there gdb is in my path, I can run it from the command line. When I run 'gdb test.exe' (test.exe being the binary placed in my workspace folder), I get the error message "not in executable format: File format not recognized", whether I build as x86 or x86_64. Any further tips on where I could get a working gdb?
Re: Debugging D applications from VS code with webfreak.debug
On Thursday, 23 February 2017 at 17:54:09 UTC, FR wrote:
gdb is in my path, I can run it from the command line. When I
run 'gdb test.exe' (test.exe being the binary placed in my
workspace folder), I get the error message "not in executable
format: File format not recognized", whether I build as x86 or
x86_64. Any further tips on where I could get a working gdb?
Nevermind on this one. Turns out something was off with the gdb
from my MinGW installation. Got a new one from
http://www.equation.com/servlet/equation.cmd?fa=gdb , placed it
where it can be found and it runs. Yay!
However: I cannot seem to get breakpoints to work. When my
executable is launched, the debug output says "No symbol table is
loaded. Use the "file" command.". Is there any special flag I
need to set in my dub.json? Should I point the "target" and "cwd"
in the launch.json anywhere but the executable that pops up in my
${workspaceRoot} (e.g. one of the sub-folders of .dub/build)?
Re: Debugging D applications from VS code with webfreak.debug
You can use the C++ plugin, which provides a debugger. Just make sure you aren't using optlink, I don't think it generates compatible files. Also you might need to use "-gc" which generates debug names to be in C format. https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools You might also need to enable breakpoints anywhere in VS code user setting file.
Re: Debugging D applications from VS code with webfreak.debug
On Friday, 24 February 2017 at 03:15:11 UTC, Jerry wrote: You can use the C++ plugin, which provides a debugger. Just make sure you aren't using optlink, I don't think it generates compatible files. Also you might need to use "-gc" which generates debug names to be in C format. https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools You might also need to enable breakpoints anywhere in VS code user setting file. Awesome! After finding the right combination of flags (-g and -m64 fed to dmd via dflags-dmd in my dub.json) this works quite nicely. Thanks a lot! Is there anywhere I can contribute this as documentation?
Re: Debugging D applications from VS code with webfreak.debug
On Friday, 24 February 2017 at 13:19:53 UTC, FR wrote:
On Friday, 24 February 2017 at 03:15:11 UTC, Jerry wrote:
You can use the C++ plugin, which provides a debugger. Just
make sure you aren't using optlink, I don't think it generates
compatible files. Also you might need to use "-gc" which
generates debug names to be in C format.
https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools
You might also need to enable breakpoints anywhere in VS code
user setting file.
Awesome! After finding the right combination of flags (-g and
-m64 fed to dmd via dflags-dmd in my dub.json) this works quite
nicely. Thanks a lot!
Is there anywhere I can contribute this as documentation?
I cannot debug my app with mago-mi. I click debug button, but
nothing happen. I have installed cpptools, mago-mi,
webfreak.debug, and I have tried vscode-dlang and code-d. My
launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "mago-mi",
"request": "launch",
"target": "${workspaceRoot}/bin/exp.exe",
"cwd": "${workspaceRoot}",
"preLaunchTask": "build"
}
]
}
Re: Debugging D in MonoDevelop, finding multiple gdb processes?
i am assuming you are using the built in gdb debugger.
a) you can try using this addin Gdb.D instead
-https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D
it might be also be in the monodevelop beta repos.
b) you can "fix"/work around the issue by replacing
"Syscall.kill" in the source
(https://github.com/mono/monodevelop/blob/master/main/src/addins/MonoDevelop.Debugger.Gdb/GdbSession.cs)
with "proc.Kill()"
similarly as what was done in the Gdb.D source
(https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D/blob/master/Gdb/GdbSession.cs)
then recompile and use.
On Wednesday, 10 June 2015 at 20:46:11 UTC, Rodger Beats wrote:
I'm new to the language and new to using MonoDevelop and I've
got this persistent problem that I haven't been able to solve
with Google searching. I frequently test out my code as I write
it and every time I start it up a new gdb process will start
running but not terminate at the end of the program. Even a
nothing program like the following will start up a new gdb
process that won't terminate:
int main( string[] args ){
return 0;
}
After testing out an application a few times I have to open my
process manager and clear out one gdb for every time I ran the
program. I'm using Linux Mint 17 x64.
Does anyone know how I can configure gdb to exit when a program
has exited successfully?
Debugging D DLL from C# app with C linkage for native Unity 5 plugin
Apologies if this has been discussed before, but I wasn't able to find anything similar on the forums or web. I can't seem to figure out how to debug a D DLL from a C# EXE. (My actual purpose here is to use D to build native plugins for Unity 5, but Unity and Mono aren't necessary to repro the problem I'm running into.) The D DLL and C# are both built as 64-bit. (C# is not set to AnyCPU). Using VS 2015 and Visual D, I can drive the D DLL from the C# EXE without any problems, but the debugger doesn't load the D DLL symbols. The DLL and PDB are in the same folder as the C# EXE. Everything behaves the same if I link to the DLL statically using P/Invoke or dynamically using LoadLibrary. Everything from the D DLL is exposed as extern(C), listed in the .def, etc. When I drive the DLL from a D EXE, I can break into the debugger easily, whether I attach at launch or attach to the process when it's already running. I'm building the DLL using: dmd dllmain.d dll.def -w -wi -g -map -ofLogic.dll -m64 -debug -shared Anyone know what I should try next? Am I missing something simple? :) thanks! Thalamus
Re: Debugging D DLL from C# app with C linkage for native Unity 5 plugin
On 30.03.2016 01:41, Thalamus wrote: Apologies if this has been discussed before, but I wasn't able to find anything similar on the forums or web. I can't seem to figure out how to debug a D DLL from a C# EXE. (My actual purpose here is to use D to build native plugins for Unity 5, but Unity and Mono aren't necessary to repro the problem I'm running into.) The D DLL and C# are both built as 64-bit. (C# is not set to AnyCPU). Using VS 2015 and Visual D, I can drive the D DLL from the C# EXE without any problems, but the debugger doesn't load the D DLL symbols. The DLL and PDB are in the same folder as the C# EXE. Everything behaves the same if I link to the DLL statically using P/Invoke or dynamically using LoadLibrary. Everything from the D DLL is exposed as extern(C), listed in the .def, etc. When I drive the DLL from a D EXE, I can break into the debugger easily, whether I attach at launch or attach to the process when it's already running. I'm building the DLL using: dmd dllmain.d dll.def -w -wi -g -map -ofLogic.dll -m64 -debug -shared Anyone know what I should try next? Am I missing something simple? :) thanks! Thalamus I haven't tried debugging a C# application, but you might have to disable "Just My Code" in the global debugger options. Also make sure to allow native debugging (JIT options). When debugging Visual D (a D DLL), I set VS (devenv.exe, a mixed C++/C# app) as the program to debug in the project debugger options. This ensures a native debugger engine is used and is the simplest way to use the mago debugger. With the "Mixed mode" engine, you can debug both C# and D/C++ in the same session.
Re: Debugging D DLL from C# app with C linkage for native Unity 5 plugin
On Tuesday, 29 March 2016 at 23:41:28 UTC, Thalamus wrote: dmd dllmain.d dll.def -w -wi -g -map -ofLogic.dll -m64 -debug -shared Anyone know what I should try next? Am I missing something simple? :) thanks! Thalamus You should be using "-gc" instead of "-g" when building 64-bit D programs that should be debugged with visual studio. Otherwise the visual studio debugger might get confused over some of the symbol names. (Because they contain '.')
Re: Debugging D DLL from C# app with C linkage for native Unity 5 plugin
On Wednesday, 30 March 2016 at 07:38:07 UTC, Benjamin Thaut wrote: On Tuesday, 29 March 2016 at 23:41:28 UTC, Thalamus wrote: dmd dllmain.d dll.def -w -wi -g -map -ofLogic.dll -m64 -debug -shared Anyone know what I should try next? Am I missing something simple? :) thanks! Thalamus You should be using "-gc" instead of "-g" when building 64-bit D programs that should be debugged with visual studio. Otherwise the visual studio debugger might get confused over some of the symbol names. (Because they contain '.') Thanks Benjamin! I changed over to -gc. I spent another couple of hours on this and finally figured it out. As it turns out, it wasn't necessary to change Just My Code. Enabling Mixed Mode debugging didn't work, but that's what set me down the path where I was able to find the answer. Unity is an odd duck in a lot of ways. They use Mono to provide cross-platform portability, and that decision led them to use their own custom subset of .NET 3.5. Although I had eliminated Unity and Mono from the repro, I had accidentally left that subset on the C# EXE. Because of this, VS uses a different managed code debugger (v3.5, v3.0, v2.0 instead of v4.6, v4.5, v4.0). This version doesn't play nicely with the Native debugger. By default, VS determines the debuggers to use automatically. So in this scenario, if you launch the EXE and then attach, it only loads the managed debugger (without telling you). If you select the old Managed and the Native debuggers in the Attach to Process dialog's Attach to: drop down list, an "Interop debugging is not supported" error pops up when you click Attach. (This is the same error you get if you select "Enable native code debugging" on the C# EXE's Debug property page.) The solution is to select only Native or the older Managed debugger, but never both. That means that you can't hit F5 to launch the EXE in debug mode and then step through native code, which is inconvenient. But for my purposes debugging through Unity, attaching to an already running process is the only scenario I really need to work anyway. The C# layer is a very thin interop and marshaling layer between the C++ (hopefully soon D) core and Unity, so 99% of the time I'll need to debug only the native code anyway. The transition between the two is the only thing that can't be stepped through, and there isn't a whole lot to that. As it turns out, I never saw this with the C++ version of the core logic because there were no C# projects in the solution, so VS automatically chose the Native one without my knowledge. Hope this helps someone else in the future! thanks, Gene
