• Iain Buclaw (39/39) Dec 30 2013 Hi.
• Jacob Carlborg (5/9) Dec 30 2013 I think they should have some kind of prefix to avoid conflict with user...
• Iain Buclaw (6/16) Dec 31 2013 I had already gathered that much when I spoke to David on IRC. I
• Iain Buclaw (2/3) Dec 31 2013 Oh never mind,, I think I know the problem. :(
• Iain Buclaw (17/24) Jan 02 2014 Special symbols can be suffixed with a $ perhaps. I can't think of
• Jerry (4/20) Jan 02 2014 I like this approach. Do we need the "info" in classinfo$,
• Rainer Schuetze (6/20) Jan 03 2014 I think double underscores should be hint enough to suggest "compiler

"Iain Buclaw" <ibuclaw ubuntu.com> writes:

Hi.

I've fixed up the D demangler in gdb with one or two hicks left 
to address.  As the below auto-complete feature presents, the 
full function signatures are now shown.

(gdb) break 'gdbstress.testsig(
gdbstress.testsig(double)
gdbstress.testsig(float)
gdbstress.testsig(real)


Currently, I have been dwelling on the best way to express the 
following symbols:

__ctorMFZ
__dtorMFZ
__postblitMFZ
__initZ
__ClassZ
__vtblZ
__InterfaceZ
__ModuleInfoZ


This is the current mapping I've got in my local branch:

__ctor -> this
__dtor -> ~this
__postblit -> this(this)
__init -> init
__Class -> classinfo
__vtbl -> vtable
__interface -> interfaceinfo
__ModuleInfo -> moduleinfo


However I'm not sure if the names are sufficient, and whether or 
not they should really be prefixed with a double underscore to 
ensure that they don't conflict with user-declared members 
(especially the compiler-generated symbols).


What do you think?

(gdb) print 'gdbstress.testmembers.
gdbstress.testmembers.this(this, int)
gdbstress.testmembers.~this()
gdbstress.testmembers.this(this)
gdbstress.testmembers.init


Regards
Iain.

Jacob Carlborg <doob me.com> writes:

On 2013-12-30 13:24, Iain Buclaw wrote:

 However I'm not sure if the names are sufficient, and whether or not
 they should really be prefixed with a double underscore to ensure that
 they don't conflict with user-declared members (especially the
 compiler-generated symbols).

I think they should have some kind of prefix to avoid conflict with user 
declared symbols and somehow indicate they're special symbols.

-- 
/Jacob Carlborg

"Iain Buclaw" <ibuclaw gdcproject.org> writes:

On Monday, 30 December 2013 at 12:57:57 UTC, Jacob Carlborg wrote:
 On 2013-12-30 13:24, Iain Buclaw wrote:

 However I'm not sure if the names are sufficient, and whether 
 or not
 they should really be prefixed with a double underscore to 
 ensure that
 they don't conflict with user-declared members (especially the
 compiler-generated symbols).

 I think they should have some kind of prefix to avoid conflict 
 with user declared symbols and somehow indicate they're special 
 symbols.

I had already gathered that much when I spoke to David on IRC. I 
was looking for some more concrete suggestions really.

Also Brad, I haven't received any ML messages since 29th? :-)

Regards,
Iain.

"Iain Buclaw" <ibuclaw gdcproject.org> writes:

On Tuesday, 31 December 2013 at 12:22:54 UTC, Iain Buclaw wrote:
 Also Brad, I haven't received any ML messages since 29th? :-)

Oh never mind,, I think I know the problem. :(

Iain Buclaw <ibuclaw gdcproject.org> writes:

On 30 December 2013 12:57, Jacob Carlborg <doob me.com> wrote:
 On 2013-12-30 13:24, Iain Buclaw wrote:

 However I'm not sure if the names are sufficient, and whether or not
 they should really be prefixed with a double underscore to ensure that
 they don't conflict with user-declared members (especially the
 compiler-generated symbols).


 I think they should have some kind of prefix to avoid conflict with user
 declared symbols and somehow indicate they're special symbols.


Special symbols can be suffixed with a $ perhaps.  I can't think of
any other symbol that would work.

__init -> init$
__Class -> classinfo$
__vtbl -> vtable$
__interface -> interfaceinfo$
__ModuleInfo -> moduleinfo$


The alternative is to just go for prefixing with double underscore,
given that the names are OK?

__init -> __init
__Class -> __classinfo
__vtbl -> __vtable
__interface -> __interfaceinfo
__ModuleInfo -> __moduleinfo


Regards
Iain

Jerry <jlquinn optonline.net> writes:

Iain Buclaw <ibuclaw gdcproject.org> writes:

 On 30 December 2013 12:57, Jacob Carlborg <doob me.com> wrote:
 On 2013-12-30 13:24, Iain Buclaw wrote:

 However I'm not sure if the names are sufficient, and whether or not
 they should really be prefixed with a double underscore to ensure that
 they don't conflict with user-declared members (especially the
 compiler-generated symbols).


 Special symbols can be suffixed with a $ perhaps.  I can't think of
 any other symbol that would work.

 __init -> init$
 __Class -> classinfo$
 __vtbl -> vtable$
 __interface -> interfaceinfo$
 __ModuleInfo -> moduleinfo$

I like this approach.  Do we need the "info" in classinfo$,
interfaceinfo$, and moduleinfo$?

Jerry

Rainer Schuetze <r.sagitario gmx.de> writes:

On 02.01.2014 12:35, Iain Buclaw wrote:
 Special symbols can be suffixed with a $ perhaps.  I can't think of
 any other symbol that would work.

 __init -> init$
 __Class -> classinfo$
 __vtbl -> vtable$
 __interface -> interfaceinfo$
 __ModuleInfo -> moduleinfo$


 The alternative is to just go for prefixing with double underscore,
 given that the names are OK?

 __init -> __init
 __Class -> __classinfo
 __vtbl -> __vtable
 __interface -> __interfaceinfo
 __ModuleInfo -> __moduleinfo

I think double underscores should be hint enough to suggest "compiler 
generated stuff". Prepending $ might confuse expression evaluators (e.g. 
mago).

I always wondered why these symbols don't follow the standard mangling 
to start with...