Turn off name mangling

[tim_c]

I have a special situation where I must turn off name mangling in plain
C. OW appends underscore to dll exports.

The exported names within the dll is deduced by dead reckoning by an
alien user of the dll, therefore name mangling is fatal.

I've proven the dll works by messing up the names and then editing them
using the debugger immediately before they get called. It works and says
the calling convention works.

I think this issue has turned up before but I can find no reference, nor
in the docs. The usual ploys seems to be telling users to get the
calling convention right.

If I try telling the linker to rename it complains the function is
already exported.

[Mat Nieuwenhoven]

Post by tim_c
I have a special situation where I must turn off name mangling in plain
C. OW appends underscore to dll exports.
The exported names within the dll is deduced by dead reckoning by an
alien user of the dll, therefore name mangling is fatal.
I've proven the dll works by messing up the names and then editing them
using the debugger immediately before they get called. It works and says
the calling convention works.
I think this issue has turned up before but I can find no reference, nor
in the docs. The usual ploys seems to be telling users to get the
calling convention right.
If I try telling the linker to rename it complains the function is
already exported.

#pragma aux is probably what you need. I don't have it handy, but it is in
the docs.

Mat Nieuwenhoven

[Dave Yeo]

Post by tim_c
The exported names within the dll is deduced by dead reckoning by an
alien user of the dll, therefore name mangling is fatal.
I've proven the dll works by messing up the names and then editing them
using the debugger immediately before they get called. It works and says
the calling convention works.

Write your own DEF file and use alias's? IIRC under exports
foo=_foo
will allow _foo to be accessed as foo or _foo.
Dave

[Hans-Bernhard Bröker]

Post by tim_c
I have a special situation where I must turn off name mangling in plain
C.

There is none, so nothing to turn off. What you're looking at is
decoration, not mangling. The latter is what happens to C++ symbol names.

Post by tim_c
OW appends underscore to dll exports.

... in _some_ of its available modes. In others it doesn't.

Post by tim_c
The usual ploys seems to be telling users to get the
calling convention right.

That's not a ploy, that's what you need to do. Naming is part of the
calling convention. You want to influence naming, so you need to change
your calling convention. See the -ec* family of compiler switches.

[tim_c]

Post by Hans-Bernhard Bröker
That's not a ploy, that's what you need to do. Naming is part of the
calling convention. You want to influence naming, so you need to change
your calling convention. See the -ec* family of compiler switches.

I used the wrong name, sorry.

I'll experiment further. Forcing the entire build to a different
convention might work. (these are published sources where edit is highly
undesirable, gcc and msc are the usual tools but there is a good reason
for a version without the msc dependencies)

[tim_c]

Post by Hans-Bernhard Bröker

Post by tim_c
OW appends underscore to dll exports.

... in _some_ of its available modes. In others it doesn't.

Post by tim_c
The usual ploys seems to be telling users to get the
calling convention right.

That's not a ploy, that's what you need to do. Naming is part of the
calling convention. You want to influence naming, so you need to change
your calling convention. See the -ec* family of compiler switches.

Report on what I discovered which might be useful to others.

1. In this instance turning off name decoration was a correct solution
and the only way to give source compatibility with gcc and msc.

2. Compiling the entire source suite using -ecs which is __syscall would
work but on more extensive checks hit a fatal problem with OW libraries
not recognising the convention. A fix would require changing public
sources, needs to be avoided.

3. The only fully working solution and by far the simplest is patch on
the the core third party codes, then everything can use OW default. This
is also proof that the single problem is name decoration. (as I said
this is an unusual situation, computed library function name (patch adds
decoration))

Is there an OW source patch utility which can be distributed? I cannot
change widely published sources but a single file patch would fix things
and make OW a viable compiler.

[tim_c]

Now managed to figure out the incantation to change the exported
function names. (been trying to figure this out from the docs for days,
just getting error msgs and warning, is opposite to lbc file method)

For dll export, link the dll giving literally

export newname=oldname

For lbc seems to be
oldname.newname

Within the dll the new name is added and the old remains but does not work.

[Jiri Malak]

Post by tim_c

Post by Hans-Bernhard Bröker

Post by tim_c
OW appends underscore to dll exports.

... in _some_ of its available modes. In others it doesn't.

Post by tim_c
The usual ploys seems to be telling users to get the
calling convention right.

That's not a ploy, that's what you need to do. Naming is part of the
calling convention. You want to influence naming, so you need to change
your calling convention. See the -ec* family of compiler switches.

Report on what I discovered which might be useful to others.
1. In this instance turning off name decoration was a correct solution
and the only way to give source compatibility with gcc and msc.
2. Compiling the entire source suite using -ecs which is __syscall would
work but on more extensive checks hit a fatal problem with OW libraries
not recognising the convention. A fix would require changing public
sources, needs to be avoided.
3. The only fully working solution and by far the simplest is patch on
the the core third party codes, then everything can use OW default. This
is also proof that the single problem is name decoration. (as I said
this is an unusual situation, computed library function name (patch adds
decoration))
Is there an OW source patch utility which can be distributed? I cannot
change widely published sources but a single file patch would fix things
and make OW a viable compiler.

Your conclusions are completely wrong.
Especialy statement about source compatibility problem for OW compiler.
What you describe is binary compatibility problem.
It looks like you don't understand calling convention and what it means.
Default OW calling convention (register calling convention) is not supported by gcc and
msc
that if you want generate code compatible with gcc or msc then you must change calling
convention for OW compiler.
Each calling convention has its own naming rules.
Bellow is example of generated symbol names for various calling convention for C function
prototyped as int foo( int )
cdecl _foo (GCC and MSC default calling convention)
watcall foo_ (OW default register calling convention)
stdcall ***@4 (Used mostly by Win32)
fastcall @***@4

I recommend you to read Programmer guide section 8.27.3 Predefined Aliases and next
sections which describes each calling convention used by OW.
You should also understand what calling convention is used by gcc and msc.


I think that gcc and msc use cdecl calling convention as default that you should compile
your source
with -ecc option if you want compatibility with these comiplers.
I must note that it supose OW C RTL will be used for generated code but, DLL it is OK.
All your DLL entries symbol name should be in proper form.
But name change by -ecc option is not purpose it is result of OW default calling
convention change.
Next posible problem can be incompatible import library for your DLL.

You don't give here any serious example of your problem, only try to stated what you think
as true.
Simply symbol name change can not solve calling convention incompatibility.

Jiri

[tim_c]

Post by Jiri Malak
Your conclusions are completely wrong.

We are talking cross purposes about a problem I have never come across
before and I hazard a guess you haven't either.

Post by Jiri Malak
Especialy statement about source compatibility problem for OW compiler.
What you describe is binary compatibility problem.

No. GCC and MSC can compile the sources and are self compatible. I am
not talking intercompiler compatibility. Nothing to do with calling
conventions. It is a pure textual naming problem.

OW cannot compile the sources, it does not work because the sources make
a program which violates the naming convention used by OW.

The program can be given a third party dll compiled by someone else
(assume was compiled using OW), no def file, no header, the dll is
simply dropped into a directory. A user at runtime says use
facility "fred".

The dll is called perhaps fred.dll

The calling program tells Windows to load fred.dll, computes perhaps the
textual name initialise_lib_fred and asks Windows for the address of
initialise_lib_fred inside the dll.

Unfortunately OW has appended "_"

Binary compatibility is perfect, can be anything which works with a dll.

Editing any of the sources is impractical, has to be a simple solution.

I found that using __syscall worked but on checking a variety of sources
it failed. A source used an indirect call to an OW lib function which
uses __watcall, not so easy to fix.
(the lib probably ought to have autoselect as I used many years ago, but
it doesn't)

Eventually on trying again I found out how to rename. Tried it first but
failed. (the docs are very difficult for me, probably for much the same
reason that writing here leads to cross purposes, that is life)

[Jiri Malak]

Post by tim_c

Post by Jiri Malak
Your conclusions are completely wrong.

We are talking cross purposes about a problem I have never come across
before and I hazard a guess you haven't either.

Post by Jiri Malak
Especialy statement about source compatibility problem for OW compiler.
What you describe is binary compatibility problem.

No. GCC and MSC can compile the sources and are self compatible. I am
not talking intercompiler compatibility. Nothing to do with calling
conventions. It is a pure textual naming problem.

Unfortunately if you refere to unportable code (which use unportable feature
or some language extension) than it is
uncompatible, but it is nothing related to OW it is general problem with
unportable code.
You can not expect that you can cross compile this type of code.

Post by tim_c
OW cannot compile the sources, it does not work because the sources make
a program which violates the naming convention used by OW.
The program can be given a third party dll compiled by someone else
(assume was compiled using OW), no def file, no header, the dll is
simply dropped into a directory. A user at runtime says use
facility "fred".
The dll is called perhaps fred.dll
The calling program tells Windows to load fred.dll, computes perhaps the
textual name initialise_lib_fred and asks Windows for the address of
initialise_lib_fred inside the dll.

You must understand calling convention ( including symbol naming rule) used
by DLL.
You incline separate symbol name rule from calling convention, this is wrong
approach.
All must be consistent to get proper result.

Post by tim_c
Unfortunately OW has appended "_"
Binary compatibility is perfect, can be anything which works with a dll.
Editing any of the sources is impractical, has to be a simple solution.

If I understand you correctly then you have DLL source code.
In this case I didn't understand your problem.
If it is unportable code then you must fix it.

If you need some code override for OW compiler then you can use possibility
to include
some header file by compiler -fi command line option or by FORCE environment
variable.

Post by tim_c
I found that using __syscall worked but on checking a variety of sources
it failed. A source used an indirect call to an OW lib function which
uses __watcall, not so easy to fix.
(the lib probably ought to have autoselect as I used many years ago, but
it doesn't)

It is interesting if you are talking about __syscall calling convention.and
problem with underscore,
because this calling convention doesn't use any underscore for symbol names
rules.

I don't understand why you talk about __watcall convention in relation to
your DLL if it is not compiled by OW.
If it is using some indirect call to C RTL it is calling to original
compiler CRTL DLL not to OW version.
It looks like you try to do something strange.

Post by tim_c
Eventually on trying again I found out how to rename. Tried it first but
failed. (the docs are very difficult for me, probably for much the same
reason that writing here leads to cross purposes, that is life)

OW compilers have very poverful auxiliary pragma "#pragma aux" which can do
regular way change in any
calling convention to reflect any special requirements as symbol naming rule
if it is necessary.
But in your case I don't expect any "exotic" compiler that existing OW
calling conventions should be anough without any change.

Jiri

[tim_c]

Post by Jiri Malak
Unfortunately if you refere to unportable code (which use unportable feature
or some language extension) than it is
uncompatible, but it is nothing related to OW it is general problem with
unportable code.
You can not expect that you can cross compile this type of code.

I completely agree it is poor practice. Might be why I struggled working
out what was going wrong and the fix. (I am rusty because I dropped out
20 years ago and unfortunately tend to use different words and ideas)

Both gcc and msc compile the code without assistance.

This is a matter of pragmatism because this is major code out there
where OW is hurt by not working. Potential OW users walk away.

The reason will become clear eventually, watch the wiki.

[Hans-Bernhard Bröker]

Post by tim_c
No. GCC and MSC can compile the sources and are self compatible. I am
not talking intercompiler compatibility. Nothing to do with calling
conventions. It is a pure textual naming problem.

I'm reasonably sure your deluding yourself regarding this conclusion.
Getting the naming right may appear to be the main obstacle, but it's
not. You _must_ match the entire calling convention correctly. Naming
is just the first difference you've encountered. It's by no means the
only one.

Post by tim_c
OW cannot compile the sources, it does not work because the sources make
a program which violates the naming convention used by OW.

Since we're nearly 100% sure that OW can compile programs that use DLLs
produces by MSC and GCC, and the other way round, it's a pretty safe
assumption that you drew this conclusion incorrectly.

Post by tim_c
The program can be given a third party dll compiled by someone else
(assume was compiled using OW), no def file, no header, the dll is
simply dropped into a directory. A user at runtime says use
facility "fred".

So in a nutshell, you're talking about a typical (though apparently
somewhat ill-designed) binary plug-in module interface.

Post by tim_c
The calling program tells Windows to load fred.dll, computes perhaps the
textual name initialise_lib_fred and asks Windows for the address of
initialise_lib_fred inside the dll.

Then that program is wrong. No Windows compiler would export that
function by that exact name, so this would never work.

Post by tim_c
Unfortunately OW has appended "_"

Because, unfortunately, you still haven't bothered to follow either the
documentation or any of the advice you've received here, to learn that
this happens _only_ in register-based calling convention.

[b***@gmail.com]

use
#pragma aux __cdecl "*"

[Hans-Bernhard Bröker]

Post by b***@gmail.com
use
#pragma aux __cdecl "*"

Wow, and it only took you five and a half years to come up with the same
old answer, and ignore the entire discussion of its merit that ensued
back then.