mangled name  
Author Message
Shouvik





PostPosted: Visual C++ General, mangled name Top

Is there any API to retrieve the address of a method (private/public) using the mangled name. the method is supposed to be a class member.

we can know the mangled name from the .map file in VC++ 6.0

Please also suggest a method of using this in GCC.




Visual C++6  
 
 
einaros





PostPosted: Visual C++ General, mangled name Top

You can use the undname command line utility to un-mangle the name, if that helps.

It's not clear to me whether you want to get the symbol address from another DLL, another static library or within your main project.



 
 
Shouvik





PostPosted: Visual C++ General, mangled name Top

yes i want to retrieve the address from the mangled name in the DLL only.

Corressponding to the solution provided by you

pvt p;

_asm
{
lea ecx, p
call pvt::sum
}

works fine with VS2005 but crimps in VC++6.0. (My project cant make use of Managed C++ compiler and CLR)

the following error shows up


D:\RAJSHOUVIK\pvt\pvt.cpp(51) : error C2420: 'pvt' : illegal symbol in first operand
D:\RAJSHOUVIK\pvt\pvt.cpp(51) : error C2415: improper operand type
D:\RAJSHOUVIK\pvt\pvt.cpp(51) : error C2400: inline assembler syntax error in 'second operand'; found 'bad token'
D:\RAJSHOUVIK\pvt\pvt.cpp(52) : error C2400: inline assembler syntax error in 'opcode'; found 'bad token'
Error executing cl.exe.
Creating browse info file...

pvt.exe - 4 error(s), 0 warning(s)

So what i thought is VS2005 is a manged C++ code so it makes necessary arrangements to know the Address of the caled method but in VC++6.0 i need to supply the address explicitly. Hence what I planned is to create a .def

Am i going in the correct way or can I modify something in the solution given by to make it run in VC++6.0

Please help



 
 
Mike Danes





PostPosted: Visual C++ General, mangled name Top

"My project cant make use of Managed C++ compiler and CLR"

Are you saying that you are using VC++ 6 just because you cannot use Managed C++ and CLR But VC++ 2005 does not force you in any way to use Managed C++ and CLR. It supports native C++ just like VC++ 6 !

 

 


 
 
einaros





PostPosted: Visual C++ General, mangled name Top

So what i thought is VS2005 is a manged C++ code so it makes necessary arrangements to know the Address of the caled method but in VC++6.0 i need to supply the address explicitly. Hence what I planned is to create a .def

That's a common misconception. As Mike points out, there's nothing forcing you to use the CLR even though you compile with VC8 (or VC7 / 7.1 for that matter). I suggest you stick with VC8, and forget VC6. While the latter had a lot to offer in its prime, it's long since surpassed with regard to language conformance, flexibility and (at least in some cases) speed. Not to mention that there's no longer any support for '6.

My suggestion: migrate.



 
 
Shouvik





PostPosted: Visual C++ General, mangled name Top

i cant make use of VS7 + because of two things

  • licensing issues are bit problemous
  • Back compatibility is not an issue with VS 7+ but supporting higher versions will be prob for VC 6.0

This is because stil 6.0 is more widely used here in our domain.

Now coming to the main problem I could somethow access the pvt method using function pointer and then assigning the address but it would be better if i dynamically retrieve the address from the mangled name so generated.

So please suggest a way to retrieve the address(HEX Value) from the mangled name.



 
 
einaros





PostPosted: Visual C++ General, mangled name Top

So please suggest a way to retrieve the address(HEX Value) from the mangled name.

Un-mangle the name using undname, and fetch the address using GetProcAddress().



 
 
Holger Grund





PostPosted: Visual C++ General, mangled name Top

So please suggest a way to retrieve the address(HEX Value) from the mangled name.

Un-mangle the name using undname, and fetch the address using GetProcAddress().

Erh Why would you expect the unmangled name to produce valid input to GetProcAddress If the function is indeed exported it would very likely have the mangled name in the export name table, but certainly not anything I can think of that would be produced by undname on a C++ mangled name.

I take it, it is quite obvious but obviously it's the caller's responsibility to set up things correctly which would come for free in C++ code. Notably, care must be taken for virtual functions, pointer adjustments and covariant return types.

-hg


 
 
einaros





PostPosted: Visual C++ General, mangled name Top

 

Erh Why would you expect the unmangled name to produce valid input to GetProcAddress If the function is indeed exported it would very likely have the mangled name in the export name table, but certainly not anything I can think of that would be produced by undname on a C++ mangled name.

This is a follow up thread to another similar one, in which the function was a standard thiscall member. I assume he's already got the header, as that was the case with the other thread, and that the dll is imported through an import lib. If that's so, the real problem here is the assembly syntax which isn't supported by VC6, and *that* could simply be solved by another pointer, like:

pvt p;
void (pvt::*addr)() = &pvt::sum;
_asm
{
    lea ecx, f
    call addr
}

I figured we'd get to that conclusion eventually, but not without some forced discoveries along the way.



 
 
Mike Danes





PostPosted: Visual C++ General, mangled name Top

Except that getting the address of a private member is not supposed to work
 
 
einaros





PostPosted: Visual C++ General, mangled name Top

Except that getting the address of a private member is not supposed to work

Riight, it was private. That was the motivation for the assembly use in the first place.



 
 
Holger Grund





PostPosted: Visual C++ General, mangled name Top

Erh Why would you expect the unmangled name to produce valid input to GetProcAddress If the function is indeed exported it would very likely have the mangled name in the export name table, but certainly not anything I can think of that would be produced by undname on a C++ mangled name.

This is a follow up thread to another similar one, in which the function was a standard thiscall member. I assume he's already got the header, as that was the case with the other thread, and that the dll is imported through an import lib. If that's so, the real problem here is the assembly syntax which isn't supported by VC6, and *that* could simply be solved by another pointer, like:

That explains some of it. However, undname returns the unmangled name. And that will be somthing like

"public: void __thiscall ...". Certainly not a valid export name.

I must admit I don't understand the problem since simply changing access control or granting friendship to a client of the class certainly doesn't break binary compatibility. And patching your private copy of a header is probably less of a hack than all of this assembly stuff. Oc, you could just stick with MASM.

-hg


 
 
einaros





PostPosted: Visual C++ General, mangled name Top

That explains some of it. However, undname returns the unmangled name. And that will be somthing like

"public: void __thiscall ...". Certainly not a valid export name.

I'm aware of that. For some reason got tangled up in two different scenarios, one where he wanted to get the address of a function he already had the header for (forgetting the fact that it was private), and a second where the name was mangled, and he wanted to know what it really was. None of the two were actually going on, though.

I must admit I don't understand the problem since simply changing access control or granting friendship to a client of the class certainly doesn't break binary compatibility.

That was suggested in the original thread, but didn't seem to be an accepted solution. He doesn't have the source of the dll project.

And patching your private copy of a header is probably less of a hack than all of this assembly stuff.

Hm If he was to change the header of the dll, but not the library itself, the linker wouldn't be able to match the function

The following should work, even with VC6, granted that the private function in the exported class is using thiscall. The signature will probably need some change, though.

class pvt {}; // You'd probably want to replace that with a class import, or proper declaration ..

HANDLE lib = LoadLibrary("pvtdll.dll");
void (__stdcall *p)() =
reinterpret_cast<void(__stdcall *)(void)>
(GetProcAddress(reinterpret_cast<HMODULE>(lib), "MANGLED-NAME"));
pvt instance;
_asm lea ecx, instance
(*p)();

Not a very pretty sight.



 
 
Shouvik





PostPosted: Visual C++ General, mangled name Top

well one thing for sure is i cant go for incremental build and as well my source project is not a dll project. I's thinking that we have preferrred load address for any executable set as 0x00400000 and DLL is 0x10000000. now if the OS doesnt find these addresses viable it'll relocate my project. Hence to be more full proof i's thinking of retrieving the load address dynamically. is there any method to load the process address.

u can refer to this ques too http://forums.devx.com/archive/index.php/t-84616.html



 
 
Holger Grund





PostPosted: Visual C++ General, mangled name Top

And patching your private copy of a header is probably less of a hack than all of this assembly stuff.

Hm If he was to change the header of the dll, but not the library itself, the linker wouldn't be able to match the function

I very much doubt that. Granting friendship to a client of the class certainly doesn't change any function's mangled name.

So if you have like

class pvt { void sum(); };
void foo () { pvt().sum(); } // error

why would that not work

void foo();
class pvt { void sum(); friend void foo(); };
void foo() { pvt().sum(); } // Ok

I am not aware of any ABI that would produce different names in this case. Of course, one may want to grant friendship to a single accessor class which wraps all access rather than to individual client functions.

-hg