Discussion:
A new debugger for Linux - would it work for D?
(too old to reply)
Cristian Vlasceanu
2006-11-21 23:50:30 UTC
Permalink
Hi,
I have written a Linux debugger (so far targeting C and C++) and from
conversations with Walter and Andrei Alexandrescu emerged the idea of adapting
it to support D.

The areas that might need some not-so-trivial effort are the stack unwinding
(as I understood from Walter, D sometimes uses stack frame layouts that may
not be compatible with C) and the expression interpreter.

Take a look, and if you think the investment in D is worthwhile I will give it
a shot.

Thank you,
Cristian Vlasceanu (http://www.zero-bugs.com)
Bill Baxter
2006-11-22 00:18:52 UTC
Permalink
Post by Cristian Vlasceanu
Hi,
I have written a Linux debugger (so far targeting C and C++) and from
conversations with Walter and Andrei Alexandrescu emerged the idea of adapting
it to support D.
The areas that might need some not-so-trivial effort are the stack unwinding
(as I understood from Walter, D sometimes uses stack frame layouts that may
not be compatible with C) and the expression interpreter.
Take a look, and if you think the investment in D is worthwhile I will give it
a shot.
Thank you,
Cristian Vlasceanu (http://www.zero-bugs.com)
That would be fantastic.
I'm primarily on Windows, but I'd probably fire up my VMWare Ubuntu
install just to be able to use a decent D debugger.

Would this be for GDC only? Or both DMD & GDC?

--bb
Cristian Vlasceanu
2006-11-22 01:25:03 UTC
Permalink
Pardon my ignorance, what is GDC? The GNU implementation of D?

If that is the case, then the answer is that it depends on which side the work
will be done, i.e. it might be the case that the compiler need be tweaked to
generate DWARF to help the debugger, not just for the debugger to be extended to
understand D.

The way the debugger works to date is to look up for stack unwinding info
(generated for C++ exception unwinding), and, if not found, it falls back to the
"classical" linked list of frames approach, using the instruction pointer, stack
pointer and frame register.

I must admit I have not tried interoperating Zero and D, I just wanted to see if
there is enough interest in the community to justify the work.

Cristian
Lutger
2006-11-22 01:40:30 UTC
Permalink
Post by Cristian Vlasceanu
I must admit I have not tried interoperating Zero and D, I just wanted to see if
there is enough interest in the community to justify the work.
Cristian
I'm thinking about getting into linux and would appreciate the work, of
course. Can't speak for other people, but I suspect most would like a
good debugger for D very much.

It seems like Zero is also designed for making it easier for other tools
to use it, nice one.

Good luck with development, I hope you will decide to make the effort.
Bill Baxter
2006-11-22 03:34:46 UTC
Permalink
Post by Cristian Vlasceanu
Pardon my ignorance, what is GDC? The GNU implementation of D?
GDC uses the GCC backend to generate code.
DMD uses the Digtal Mars backend to generate code.
GDC is out of date.
That's about all I know.

I don't know if they have different object formats or different formats
for debug info.


--bb
Carlos Santander
2006-11-22 03:47:52 UTC
Permalink
Post by Bill Baxter
Post by Cristian Vlasceanu
Pardon my ignorance, what is GDC? The GNU implementation of D?
GDC uses the GCC backend to generate code.
DMD uses the Digtal Mars backend to generate code.
GDC is out of date.
Err... latest svn revision (41) puts gdc up with dmd 0.174...
Post by Bill Baxter
That's about all I know.
I don't know if they have different object formats or different formats
for debug info.
--bb
--
Carlos Santander Bernal
Bill Baxter
2006-11-22 04:35:46 UTC
Permalink
Post by Carlos Santander
Post by Bill Baxter
Post by Cristian Vlasceanu
Pardon my ignorance, what is GDC? The GNU implementation of D?
GDC uses the GCC backend to generate code.
DMD uses the Digtal Mars backend to generate code.
GDC is out of date.
Err... latest svn revision (41) puts gdc up with dmd 0.174...
Cool beans! (Not sure how I was supposed to know that, though, given
that there hasn't been an announcement here, AFAIK. But great news
nonetheless.)

--bb
John Reimer
2006-11-22 05:29:16 UTC
Permalink
On Tue, 21 Nov 2006 19:47:52 -0800, Carlos Santander
Post by Carlos Santander
Post by Bill Baxter
Post by Cristian Vlasceanu
Pardon my ignorance, what is GDC? The GNU implementation of D?
GDC uses the GCC backend to generate code.
DMD uses the Digtal Mars backend to generate code.
GDC is out of date.
Err... latest svn revision (41) puts gdc up with dmd 0.174...
Are you sure? The svn revision I have on my computer is 41 and it hasn't
been updated for awhile now. I keep doing an "svn update" and there are
no changes. Is there a different svn repository that I'm not aware of?

-JJR
Carlos Santander
2006-11-22 05:57:12 UTC
Permalink
Post by John Reimer
On Tue, 21 Nov 2006 19:47:52 -0800, Carlos Santander
Post by Carlos Santander
Post by Bill Baxter
Post by Cristian Vlasceanu
Pardon my ignorance, what is GDC? The GNU implementation of D?
GDC uses the GCC backend to generate code.
DMD uses the Digtal Mars backend to generate code.
GDC is out of date.
Err... latest svn revision (41) puts gdc up with dmd 0.174...
Are you sure? The svn revision I have on my computer is 41 and it
hasn't been updated for awhile now. I keep doing an "svn update" and
there are no changes. Is there a different svn repository that I'm not
aware of?
-JJR
branches/gdc-0.20-dev/d/ChangeLog :

2006-11-18 David Friedman <dvdfrdmn at users.sf.net>

Rest of DMD 0.174 merge:
(etc)
--
Carlos Santander Bernal
John Reimer
2006-11-22 06:06:19 UTC
Permalink
On Tue, 21 Nov 2006 21:57:12 -0800, Carlos Santander
Post by Carlos Santander
Post by John Reimer
On Tue, 21 Nov 2006 19:47:52 -0800, Carlos Santander
Post by Carlos Santander
Post by Bill Baxter
Post by Cristian Vlasceanu
Pardon my ignorance, what is GDC? The GNU implementation of D?
GDC uses the GCC backend to generate code.
DMD uses the Digtal Mars backend to generate code.
GDC is out of date.
Err... latest svn revision (41) puts gdc up with dmd 0.174...
Are you sure? The svn revision I have on my computer is 41 and it
hasn't been updated for awhile now. I keep doing an "svn update" and
there are no changes. Is there a different svn repository that I'm not
aware of?
-JJR
2006-11-18 David Friedman <dvdfrdmn at users.sf.net>
(etc)
my changelog doesn't say that... I must have downloaded a different branch

-JJR
John Demme
2006-11-22 05:23:56 UTC
Permalink
Post by Cristian Vlasceanu
Hi,
I have written a Linux debugger (so far targeting C and C++) and from
conversations with Walter and Andrei Alexandrescu emerged the idea of
adapting it to support D.
The areas that might need some not-so-trivial effort are the stack
unwinding (as I understood from Walter, D sometimes uses stack frame
layouts that may not be compatible with C) and the expression interpreter.
Take a look, and if you think the investment in D is worthwhile I will
give it a shot.
Thank you,
Cristian Vlasceanu (http://www.zero-bugs.com)
You would totally be my hero. I'm the one who wrote (and maintains) the GDB
D patches project... so far it only supports D symbol demangling, and not
even all that well. I haven't done more since GDB is bloody impossible to
hack (as your website mentions.)

DMD's DWARF output is incomplete (outright wrong sometimes, actually see bug
#146) but GDB frequently can't even handle a lot of D stacks anyway. I
think Walter will be much more inclined to add more DWARF support (and fix
the existing support) if someone is actually developing a debugging program
for D code and is willing to give him advice on the DWARF format (as I
recall, he wasn't particularly excited about learning DWARF to initially
implement the output.)

In short, if Zero were to get good (or even better- great) D support, I'm
pretty confident nearly every Linux D user would use it, and the Windows D
users would be very jelous.

BTW- I think Zero is a great idea. I haven't read over the entire web site
yet, but I like it a lot. GDB sucks! Choice is great!

Good luck with D. If you have any questions, I'm happy to answer them
personally or feel free to post to the newsgroups here. The D community
tends to be very friendly and helpful. You might also check out
dsource.org for some tutorials and interesting D projects.
--
~John Demme
me at teqdruid.com
http://www.teqdruid.com/
Cristian Vlasceanu
2006-11-22 06:34:11 UTC
Permalink
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.

The details of generating the correct DWARF output might be addressed by using the
producer functions in Dave Anderson's libdwarf
(http://reality.sgiweb.org/davea/dwarf.html). Zero uses the consumer side of that
library and I am pleased with the results so far.

Meanwhile I will try and educate myself some more wrt to D.

Thank you kindly for your warm thoughts! It is also great to know that someone has
explored these issues before.
Thomas Kühne
2006-11-22 07:35:32 UTC
Permalink
Post by Cristian Vlasceanu
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.
see attachment

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddemangled.zip
Type: application/zip
Size: 20264 bytes
Desc: not available
Url : http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20061122/dda12d3a/attachment.zip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
Url : http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20061122/dda12d3a/attachment.pgp
Don Clugston
2006-11-22 11:19:39 UTC
Permalink
Post by Thomas Kühne
Post by Cristian Vlasceanu
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.
see attachment
Thomas
Wow, it's interesting to compare yours with my compile-time demangler.
They are both about the same number of lines of code (and both seem more
comprehensive than the one in Phobos).
Walter Bright
2006-11-22 21:13:34 UTC
Permalink
Post by Don Clugston
Post by Thomas Kühne
Post by Cristian Vlasceanu
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.
see attachment
Thomas
Wow, it's interesting to compare yours with my compile-time demangler.
They are both about the same number of lines of code (and both seem more
comprehensive than the one in Phobos).
Would you two care to take the best of both, and we can replace the
Phobos one?
Don Clugston
2006-11-23 08:35:20 UTC
Permalink
Post by Walter Bright
Post by Don Clugston
Post by Thomas Kühne
Post by Cristian Vlasceanu
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.
see attachment
Thomas
Wow, it's interesting to compare yours with my compile-time demangler.
They are both about the same number of lines of code (and both seem
more comprehensive than the one in Phobos).
Would you two care to take the best of both, and we can replace the
Phobos one?
I think there a couple of issues in the mangling algorithm which need to
be addressed first.
- The bug with local alias template parameters (depends on where it's
instantiated from).
- Bugzilla bug #221, a one-character fix.
mtype.c line 174-175,

mangleChar[Tbit] = 'b';
mangleChar[Tbool] = 'x';

This should be changed so they are both 'b'.
- Items that use D mangling but don't have D linkage. I suggest changing
those cases to use "0" then the linkage type ('W' for Windows, 'U', for
C, etc, same as for delegate/function pointers), then the length.
So instead of
main3abci

it would be
0U4main3abci

for

void main()
{
int abc;
}


making it distinguishable from
extern(Windows)
{
int main3abci;
}

- template floating point value parameters should use big-endian order
(with exponent first) which would be moderately human-readable, instead
of the current order, which makes no sense.

expression.c line 1316 is currently

for (int i = 0; i < REALSIZE-REALPAD; i++)
buf->printf("%02x", p[i]);

but should be

for (int i = REALSIZE-REALPAD-1; i >=0; i--)
buf->printf("%02x", p[i]);

(Actually it would be even better if the implicit bit were stripped out
for x86; that would make it more compatible across platforms, and would
mean 0x1.123456789ABCDEDEp+0 would be mangled as:
"3FFF123456789ABCDEDE"
-- but proper cross-platform support needs a bit more thought).
Bruno Medeiros
2006-11-23 10:30:13 UTC
Permalink
Post by Don Clugston
- Items that use D mangling but don't have D linkage. I suggest changing
those cases to use "0" then the linkage type ('W' for Windows, 'U', for
C, etc, same as for delegate/function pointers), then the length.
So instead of
main3abci
it would be
0U4main3abci
for
void main()
{
int abc;
}
making it distinguishable from
extern(Windows)
{
int main3abci;
}
Can we define functions that do not have D linkage, but have D name
mangling? If so, does that even make sense? It was my understanding that
any function with linkage other than D is used for obj/lib/dll level
compatibility with other programs written in other languages (i.e., ABI
level compatibility). As such, these other languages don't understand D
name mangling but only C name mangling, so what's a non-D-linkage with
D-name-mangling for?
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Don Clugston
2006-11-23 11:17:01 UTC
Permalink
Post by Bruno Medeiros
Post by Don Clugston
- Items that use D mangling but don't have D linkage. I suggest
changing those cases to use "0" then the linkage type ('W' for
Windows, 'U', for C, etc, same as for delegate/function pointers),
then the length.
So instead of
main3abci
it would be
0U4main3abci
for
void main()
{
int abc;
}
making it distinguishable from
extern(Windows)
{
int main3abci;
}
Can we define functions that do not have D linkage, but have D name
mangling? If so, does that even make sense? It was my understanding that
any function with linkage other than D is used for obj/lib/dll level
compatibility with other programs written in other languages (i.e., ABI
level compatibility). As such, these other languages don't understand D
name mangling but only C name mangling, so what's a non-D-linkage with
D-name-mangling for?
These symbols cannot be externally linked directly, but it can be
important for eg alias template parameters. (Everything needs to be
manglable, even it can't be linked directly).

extern(C) {

void func() {
// 'func' uses C name mangling

void inner() {
// 'inner' uses D name mangling.
// So 'func.inner' is a hybrid.
}

}
}

It's even possible to have extern(Windows) inner functions inside
extern(C) functions!
Frits van Bommel
2006-11-23 11:28:22 UTC
Permalink
Post by Bruno Medeiros
Can we define functions that do not have D linkage, but have D name
mangling?
Not as far as I know.
Post by Bruno Medeiros
If so, does that even make sense? It was my understanding that
any function with linkage other than D is used for obj/lib/dll level
compatibility with other programs written in other languages (i.e., ABI
level compatibility). As such, these other languages don't understand D
name mangling but only C name mangling, so what's a non-D-linkage with
D-name-mangling for?
I have on several occasions declared functions as extern(C) in order to
be able to access them from inline assembly. I needed to be sure about
the calling convention, and at that time the D calling convention wasn't
documented as well as it is now. (http://www.digitalmars.com/d/abi.html)
Name mangling is wholly irrelevant to this, though. In fact my
backtraces would've looked better if all names had D mangling, so I
would have liked name mangling to have been preserved.
Thomas Kuehne
2006-11-23 16:14:30 UTC
Permalink
Post by Frits van Bommel
Post by Bruno Medeiros
Can we define functions that do not have D linkage, but have D name
mangling?
Not as far as I know.
Post by Bruno Medeiros
If so, does that even make sense? It was my understanding that
any function with linkage other than D is used for obj/lib/dll level
compatibility with other programs written in other languages (i.e., ABI
level compatibility). As such, these other languages don't understand D
name mangling but only C name mangling, so what's a non-D-linkage with
D-name-mangling for?
# extern(C) void outer(){
# void inner(){
# }
# }
Post by Frits van Bommel
outer
outer5innerFZv
outer
0U5outer5innerFZv
Thomas
Bruno Medeiros
2006-11-23 22:01:46 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Frits van Bommel
Post by Bruno Medeiros
Can we define functions that do not have D linkage, but have D name
mangling?
Not as far as I know.
Post by Bruno Medeiros
If so, does that even make sense? It was my understanding that
any function with linkage other than D is used for obj/lib/dll level
compatibility with other programs written in other languages (i.e., ABI
level compatibility). As such, these other languages don't understand D
name mangling but only C name mangling, so what's a non-D-linkage with
D-name-mangling for?
# extern(C) void outer(){
# void inner(){
# }
# }
Post by Frits van Bommel
outer
outer5innerFZv
outer
0U5outer5innerFZv
Thomas
Ah, got it. But in terms of calling convention, is outer.inner still of
regular D calling convention? (I think so, given some obj2asm tests I did)

As for fixes, how about just mangling the inner function with a full D
name mangling, treating the parent names as if they were D-mangled too?:
_D4modl4funcFZv5innerFZv
This way we (maybe) can't tell the calling convention of the parent
functions... but does that matter?
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Frits van Bommel
2006-11-23 22:09:17 UTC
Permalink
Post by Bruno Medeiros
As for fixes, how about just mangling the inner function with a full D
_D4modl4funcFZv5innerFZv
This way we (maybe) can't tell the calling convention of the parent
functions... but does that matter?
It might matter for something like DDL if it wants to call a function in
a dynamically-loaded module. It's kind of important to know the calling
convention for that :). (Not sure if DDL currently does anything like
this, but if not it might in the future)
Thomas Kuehne
2006-11-23 20:25:30 UTC
Permalink
Post by Don Clugston
Post by Walter Bright
Post by Don Clugston
Post by Thomas Kühne
Post by Cristian Vlasceanu
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.
see attachment
Thomas
Wow, it's interesting to compare yours with my compile-time demangler.
They are both about the same number of lines of code (and both seem
more comprehensive than the one in Phobos).
Would you two care to take the best of both, and we can replace the
Phobos one?
I think there a couple of issues in the mangling algorithm which need to
be addressed first.
<snip>
Post by Don Clugston
- Items that use D mangling but don't have D linkage. I suggest changing
those cases to use "0" then the linkage type ('W' for Windows, 'U', for
C, etc, same as for delegate/function pointers), then the length.
So instead of
main3abci
it would be
0U4main3abci
I dislike unnecessary special cases:
#
# module wood;
#
# class Tree{
# static this(){
# }
#
# ~this(){
# }
# }
#
# extern(C) void outer(){
# extern(Windows) int middle(){
# void inner(){
# }
# return 0;
# }
# }
#

DMD-0.174 generates the following symbols
Post by Don Clugston
_Class_4wood4Tree *
_D4wood4Tree11_staticCtorFZv
_D4wood4Tree5_dtorFZv
_init_4wood4Tree *
_modctor_4wood *
outer
outer6middleWZi *
outer6middleWZi5innerFZv *
_vtbl_4wood4Tree *
_D4wood4Tree9__Class__Pv
_D4wood4Tree12__staticCtorFZv
_D4wood4Tree6__dtorFZv
_D4wood4Tree8__init__Pv
_D4wood11__modctor__FZv
outer
_D4wood5outerFZv6middleWZi
_D4wood5outerFZv6middleWZi5innerFZv
_D4wood4Tree8__vtbl__Av
There are no special cases(identifiers starting with two underscores are
reserved), thus no need for the demangler to know anything about the RT's
internals.

Thomas
Don Clugston
2006-11-24 07:18:03 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Don Clugston
Post by Walter Bright
Post by Don Clugston
Post by Thomas Kühne
Post by Cristian Vlasceanu
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.
see attachment
Thomas
Wow, it's interesting to compare yours with my compile-time demangler.
They are both about the same number of lines of code (and both seem
more comprehensive than the one in Phobos).
Would you two care to take the best of both, and we can replace the
Phobos one?
I think there a couple of issues in the mangling algorithm which need to
be addressed first.
<snip>
Post by Don Clugston
- Items that use D mangling but don't have D linkage. I suggest changing
those cases to use "0" then the linkage type ('W' for Windows, 'U', for
C, etc, same as for delegate/function pointers), then the length.
So instead of
main3abci
it would be
0U4main3abci
#
# module wood;
#
# class Tree{
# static this(){
# }
#
# ~this(){
# }
# }
#
# extern(C) void outer(){
# extern(Windows) int middle(){
# void inner(){
# }
# return 0;
# }
# }
#
DMD-0.174 generates the following symbols
Post by Don Clugston
_Class_4wood4Tree *
_D4wood4Tree11_staticCtorFZv
_D4wood4Tree5_dtorFZv
_init_4wood4Tree *
_modctor_4wood *
outer
outer6middleWZi *
outer6middleWZi5innerFZv *
_vtbl_4wood4Tree *
_D4wood4Tree9__Class__Pv
_D4wood4Tree12__staticCtorFZv
_D4wood4Tree6__dtorFZv
_D4wood4Tree8__init__Pv
_D4wood11__modctor__FZv
outer
_D4wood5outerFZv6middleWZi
_D4wood5outerFZv6middleWZi5innerFZv
_D4wood4Tree8__vtbl__Av
There are no special cases(identifiers starting with two underscores are
reserved), thus no need for the demangler to know anything about the RT's
internals.
Agreed, I like that *much* better than my proposal.
BTW, unittest is another special case, and should be treated in the same
way.
- Don.
Thomas Kuehne
2006-11-23 21:12:45 UTC
Permalink
Post by Walter Bright
Post by Don Clugston
Post by Thomas Kühne
Post by Cristian Vlasceanu
D has a demangling scheme that is not compatible with C++?
Then that's another area that needs work in the debugger.
see attachment
Thomas
Wow, it's interesting to compare yours with my compile-time demangler.
They are both about the same number of lines of code (and both seem more
comprehensive than the one in Phobos).
Would you two care to take the best of both, and we can replace the
Phobos one?
http://d.puremagic.com/issues/show_bug.cgi?id=588
(though this doesn't handle any special cases)

Thomas
Walter Bright
2006-11-23 22:50:39 UTC
Permalink
Post by Thomas Kuehne
http://d.puremagic.com/issues/show_bug.cgi?id=588
Thanks!
Cristian Vlasceanu
2006-11-24 04:42:09 UTC
Permalink
I owe a clarification (especially since some of you have posted code in response
to my demangling question).

Zero is NOT open source, and my long term intent is a commercially supported
product (see some of my ramblings here: http://the-free-meme.blogspot.com/).

Also I see a lot of domain knowledge wrt the inner workings of D in this forum.

I thinks it would be a good idea (architecturally and ethically) that Zero provide
hooks for D-supporting plugins and shared objects. Such modules could be open
source themselves, or othewise licensed, as their respective authors see fit. The
demangler for example is already based on a factory pattern (it deals with legacy
gcc and the Itanium ABI), and delegating to a .so that implements D demangling
would not be very hard to do.
Frits van Bommel
2006-11-24 09:41:45 UTC
Permalink
Post by Cristian Vlasceanu
I owe a clarification (especially since some of you have posted code in response
to my demangling question).
Zero is NOT open source, and my long term intent is a commercially supported
product (see some of my ramblings here: http://the-free-meme.blogspot.com/).
Well, Thomas's code is GPL-with-exception, so you can link it to a
commercial program without any problem, as long as you distribute any
modifications to his source.
Post by Cristian Vlasceanu
Also I see a lot of domain knowledge wrt the inner workings of D in this forum.
I thinks it would be a good idea (architecturally and ethically) that Zero provide
hooks for D-supporting plugins and shared objects. Such modules could be open
source themselves, or othewise licensed, as their respective authors see fit. The
demangler for example is already based on a factory pattern (it deals with legacy
gcc and the Itanium ABI), and delegating to a .so that implements D demangling
would not be very hard to do.
That would work as well, of course.
Walter Bright
2006-11-24 19:35:13 UTC
Permalink
Post by Frits van Bommel
Post by Cristian Vlasceanu
I thinks it would be a good idea (architecturally and ethically) that Zero provide
hooks for D-supporting plugins and shared objects. Such modules could be open
source themselves, or othewise licensed, as their respective authors see fit. The
demangler for example is already based on a factory pattern (it deals with legacy
gcc and the Itanium ABI), and delegating to a .so that implements D demangling
would not be very hard to do.
That would work as well, of course.
It would be better for D users if support was built in, so it would work
out of the box with no hassle. Having the hooks for plugins, however, is
still a very good idea and should be done. That will help future proof
the debugger.
BCS
2006-11-24 20:13:12 UTC
Permalink
Post by Walter Bright
Post by Frits van Bommel
Post by Cristian Vlasceanu
I thinks it would be a good idea (architecturally and ethically) that Zero provide
hooks for D-supporting plugins and shared objects. Such modules could be open
source themselves, or othewise licensed, as their respective authors see fit. The
demangler for example is already based on a factory pattern (it deals with legacy
gcc and the Itanium ABI), and delegating to a .so that implements D demangling
would not be very hard to do.
That would work as well, of course.
It would be better for D users if support was built in, so it would work
out of the box with no hassle. Having the hooks for plugins, however, is
still a very good idea and should be done. That will help future proof
the debugger.
You could ship it with the plug in pre-installed.
Cristian Vlasceanu
2006-11-25 02:10:24 UTC
Permalink
Post by BCS
Post by Walter Bright
Post by Frits van Bommel
Post by Cristian Vlasceanu
I thinks it would be a good idea (architecturally and ethically) that Zero provide
hooks for D-supporting plugins and shared objects. Such modules could be open
source themselves, or othewise licensed, as their respective authors see fit. The
demangler for example is already based on a factory pattern (it deals with legacy
gcc and the Itanium ABI), and delegating to a .so that implements D demangling
would not be very hard to do.
That would work as well, of course.
It would be better for D users if support was built in, so it would
work out of the box with no hassle. Having the hooks for plugins,
however, is still a very good idea and should be done. That will help
future proof the debugger.
You could ship it with the plug in pre-installed.
Yes this is exactly what I have in mind, by "hooks and plugins" I meant
to have the D support *dynamically* linked in, so that it can be
upgraded or replaced without having to recompile the debugger.
Cristian Vlasceanu
2006-11-30 20:30:20 UTC
Permalink
Do you have any D code samples that confuse GDB? (bad line numbers, weird stack
unwinding, etc).

- Cristian

John Reimer
2006-11-22 05:23:57 UTC
Permalink
On Tue, 21 Nov 2006 15:50:30 -0800, Cristian Vlasceanu
Post by Cristian Vlasceanu
Hi,
I have written a Linux debugger (so far targeting C and C++) and from
conversations with Walter and Andrei Alexandrescu emerged the idea of adapting
it to support D.
The areas that might need some not-so-trivial effort are the stack unwinding
(as I understood from Walter, D sometimes uses stack frame layouts that may
not be compatible with C) and the expression interpreter.
Take a look, and if you think the investment in D is worthwhile I will give it
a shot.
Thank you,
Cristian Vlasceanu (http://www.zero-bugs.com)
There would be a lot of support for that. Debuggers are an oft requested
feature for D.

-JJR
freeagle
2006-11-22 13:04:27 UTC
Permalink
All current and future linux users coding in D would be very thankful,
including me!
Post by John Reimer
On Tue, 21 Nov 2006 15:50:30 -0800, Cristian Vlasceanu
Post by Cristian Vlasceanu
Hi,
I have written a Linux debugger (so far targeting C and C++) and from
conversations with Walter and Andrei Alexandrescu emerged the idea of adapting
it to support D.
The areas that might need some not-so-trivial effort are the stack unwinding
(as I understood from Walter, D sometimes uses stack frame layouts that may
not be compatible with C) and the expression interpreter.
Take a look, and if you think the investment in D is worthwhile I will give it
a shot.
Thank you,
Cristian Vlasceanu (http://www.zero-bugs.com)
There would be a lot of support for that. Debuggers are an oft
requested feature for D.
-JJR
Craig Black
2006-11-22 19:05:00 UTC
Permalink
Currently there is no debugger tailored for D, so this would be great and
appreciated by many. However, how difficult would it be to make this
portable to Windows as well? Most D developers use Windows primarily.

-Craig
Kristian Kilpi
2006-11-22 19:30:47 UTC
Permalink
Post by Craig Black
Currently there is no debugger tailored for D, so this would be great and
appreciated by many. However, how difficult would it be to make this
portable to Windows as well? Most D developers use Windows primarily.
-Craig
Oh, it would be really great to have a debugger! On Windows too (I'm using
win).
John Reimer
2006-11-22 20:35:30 UTC
Permalink
Post by Craig Black
Currently there is no debugger tailored for D, so this would be great and
appreciated by many. However, how difficult would it be to make this
portable to Windows as well? Most D developers use Windows primarily.
-Craig
Do they? I wouldn't say that anymore.

-JJR
freeagle
2006-11-22 22:52:20 UTC
Permalink
Post by John Reimer
Post by Craig Black
Currently there is no debugger tailored for D, so this would be great and
appreciated by many. However, how difficult would it be to make this
portable to Windows as well? Most D developers use Windows primarily.
-Craig
Do they? I wouldn't say that anymore.
-JJR
could be interesting to somehow get those numbers
John Reimer
2006-11-22 23:36:11 UTC
Permalink
On Wed, 22 Nov 2006 14:52:20 -0800, freeagle <dalibor.free at gmail.com>
Post by freeagle
Post by John Reimer
Post by Craig Black
Currently there is no debugger tailored for D, so this would be great and
appreciated by many. However, how difficult would it be to make this
portable to Windows as well? Most D developers use Windows primarily.
-Craig
Do they? I wouldn't say that anymore.
-JJR
could be interesting to somehow get those numbers
I agree.
Continue reading on narkive:
Loading...