On Thursday, 23 April 2015 at 18:07:48 UTC, Iain Buclaw wrote:
A 'nice to know' which is specific to GDC. If you prefix
pragma(mangle) names with "*" then it will not apply
target-dependent
prefixes.
For LLVM, this works by prefixing the name with \1.
We need to do this internally for naked
On 23 April 2015 at 19:15, Dan Olson via Digitalmars-d
wrote:
> Iain Buclaw via Digitalmars-d writes:
>>
>> (FYI - last time I checked GDC goes ahead and applied target-specific
>> mangling on-top of pragma(mangle). So you can relax and assume
>> nothing about the target).
>
> So does LDC.
>
> A
Iain Buclaw via Digitalmars-d writes:
>
> Because of this, debugging in OSX is not as good as it could be (if
> you use DMD). All debuggers I've seen remove the leading '_' from
> symbols before they begin demangling symbols.
And I noticed __cxa_demangle() is defined that way. Target specific
pr
Iain Buclaw via Digitalmars-d writes:
>
> (FYI - last time I checked GDC goes ahead and applied target-specific
> mangling on-top of pragma(mangle). So you can relax and assume
> nothing about the target).
So does LDC.
Actually, DMD does too on OS X, but only for extern(C) - attention to
func p
On 22 April 2015 at 19:59, Michel Fortin via Digitalmars-d
wrote:
> On 2015-04-22 16:32:55 +, Dan Olson said:
>
>> Since the compile chain knows whether the target system prepends an
>> underscore, I wonder if it can be bubbled up into some compiler trait or
>> version that prevents writing v
On 2015-04-22 16:32:55 +, Dan Olson said:
Since the compile chain knows whether the target system prepends an
underscore, I wonder if it can be bubbled up into some compiler trait or
version that prevents writing versioned code based on system. I think
it would help gdc much as it has many
On 20 April 2015 at 18:33, Dan Olson via Digitalmars-d
wrote:
> $ nm showmangle.o | grep fun
> U _D10showmangle4dfunFiZv
> U __Z6cxxfuni
> U _cfun
>
> --
> Dan
Because of this, debugging in OSX is not as good as it could be (if
you use DMD). All
"Daniel Murphy" writes:
> "Jacob Carlborg" wrote in message
> news:mh7mka$19r9$1...@digitalmars.com...
>
>> And what about pragma(mangle), should that output the symbol name
>> completely untouched?
>
> Yes.
Then for systems that add underscore prefix to compiler identifiers, dmd
.mangleof for
Michel Fortin writes:
>
> I think if you specify the mangling most of the time it's because you
> don't want the compiler to do it for you. But you should consider
> doing this:
>
> string mangleC(string name) {
> version (OSX) return "_" ~ name;
> else return name;
> }
>
> pragma(mang
"Guillaume Chatelet" wrote in message
news:vrcvkydsexiwamula...@forum.dlang.org...
This is still broken
https://issues.dlang.org/show_bug.cgi?id=14178
That's not the issue we're talking about.
I'm actually recoding the name mangling for linux/osx right now because
the current implementatio
On Wednesday, 22 April 2015 at 01:46:57 UTC, Daniel Murphy wrote:
Until fairly recently .mangleof was completely broken for eg
extern(C++) mangling on windows. I'm not surprised there are
still bugs there. Ideally .mangleof will give exactly the
string that ends up in the object file.
This
"Jacob Carlborg" wrote in message news:mh7mka$19r9$1...@digitalmars.com...
And what about pragma(mangle), should that output the symbol name
completely untouched?
Yes.
On 2015-04-22 03:46, Daniel Murphy wrote:
Until fairly recently .mangleof was completely broken for eg extern(C++)
mangling on windows. I'm not surprised there are still bugs there.
Ideally .mangleof will give exactly the string that ends up in the
object file.
And what about pragma(mangle),
"Dan Olson" wrote in message news:m28udmoj3v@comcast.net...
An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces
the actual object file symbol while mangleof for C names strips a
leading underscore.
Is this intended? If so what is rationale?
Until fairly recently .man
On 2015-04-21 18:29:36 +, Jacob Carlborg said:
On 2015-04-21 19:01, Dan Olson wrote:
If I want to call a C function void debug(const char*) from a C library,
I would do this because of D "debug" keyword:
pragma(mangle, "debug")
extern (C) void debug_c(const(char*));
Now I would th
On 2015-04-21 17:01:51 +, Dan Olson said:
Dan Olson writes:
Jacob Carlborg writes:
On 2015-04-20 18:33, Dan Olson wrote:
An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces
the actual object file symbol while mangleof for C names strips a
leading underscore.
Is t
On 2015-04-21 19:01, Dan Olson wrote:
Hmmm, I can see another point of view where mangleof should produce the
equivalent extern(C) symbol. My gut says this is the way it should
work.
That makes sense.
If I want to call a C function void debug(const char*) from a C library,
I would do this b
Dan Olson writes:
> Jacob Carlborg writes:
>
>> On 2015-04-20 18:33, Dan Olson wrote:
>>> An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces
>>> the actual object file symbol while mangleof for C names strips a
>>> leading underscore.
>>>
>>> Is this intended? If so what is
Jacob Carlborg writes:
> On 2015-04-20 18:33, Dan Olson wrote:
>> An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces
>> the actual object file symbol while mangleof for C names strips a
>> leading underscore.
>>
>> Is this intended? If so what is rationale?
>
> I don't think
On 2015-04-20 18:33, Dan Olson wrote:
An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces
the actual object file symbol while mangleof for C names strips a
leading underscore.
Is this intended? If so what is rationale?
I don't think it's intentional. The point of "mangleof
An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces
the actual object file symbol while mangleof for C names strips a
leading underscore.
Is this intended? If so what is rationale?
Demo
$ cat >showmangle.d <
21 matches
Mail list logo
