C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  remedial demangling          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Jim Keohane Guest Posted: Fri Aug 15, 2003 1:56 am    Post subject: remedial demangling I have 2 questions, kind folks. 1. Is it correct for a demangler to generate the same results from two different mangled names? 2. In the case I cite below are the different mangled names due to differentiating C++ function pointers from C function pointers? Both of the mangled C++ names below, when run thru windows cxxfilt or dos cppfilt or z/OS c++filt generate the identical results: C:DOS>cppfilt __ct__03BOBFPFPv_PvPvT1P03JIM TED::__ct(void *(*)(void *), void *, void *(*)(void *), JIM *) C:DOS>cppfilt __ct__03BOBFPFPv_PvPvPFPv_PvP03JIM TED::__ct(void *(*)(void *), void *, void *(*)(void *), JIM *) I have changed two terms to TED & JIM to simplify this example. On the internet I found what appeared to be almost an identical output of some demangler: BOB::__ct(void *(*)(void *), void *, void *(*)(void *)extern "C", JIM *) The difference is the extern "C" at end of third parameter. I suspect the extra extern "C" is actually needed on my z/OS mainframe platform to distinguish between C and C++ functions since the 1st parm is a C++ function pointer and the 3rd parm is a C function pointer. I suspect the difference in the mangled names is due to one of them containing the extern "C" info. The 3rd parm is CFUNC as specified by: extern "C" { typedef void *(*CFUNC)(void *) } whereas 1st parm is CPPFUNC as specified by: typedef void *(*CPPFUNC)(void *); Apprecaite any thoughts on this. Thanks! - Jim Keohane p.s. If someone can point me to current c++filt source code I might be able to puzzle it out myself. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Sat Aug 16, 2003 3:51 pm    Post subject: Re: remedial demangling In article <12bc9e26.0308140735.183544d7 (AT) posting (DOT) google.com>, Jim Keohane wrote: Quote: I have 2 questions, kind folks. 1. Is it correct for a demangler to generate the same results from two different mangled names? Yes if they're mangled in different formats. If they come from the exact same implementation then this should not happen. Quote: 2. In the case I cite below are the different mangled names due to differentiating C++ function pointers from C function pointers? Both of the mangled C++ names below, when run thru windows cxxfilt or dos cppfilt or z/OS c++filt generate the identical results: Which version of c++filt is this? The GNU version understands many different mangling formats and attempts to distinguish them automatically. Quote: C:DOS>cppfilt __ct__03BOBFPFPv_PvPvT1P03JIM TED::__ct(void *(*)(void *), void *, void *(*)(void *), JIM *) C:DOS>cppfilt __ct__03BOBFPFPv_PvPvPFPv_PvP03JIM TED::__ct(void *(*)(void *), void *, void *(*)(void *), JIM *) These appear to be symbols for BOB's constructor so it should say "BOB::BOB" instead of "TED::__ct". Quote: I have changed two terms to TED & JIM to simplify this example. Compare the two symbols and you'll see that one has "T1" and the other has "PFPv_Pv". The "T1" is a back-reference to the first parameter type, a kind of compression, whereas "PFPPv_Pv" is a simple repetition. Quote: On the internet I found what appeared to be almost an identical output of some demangler: BOB::__ct(void *(*)(void *), void *, void *(*)(void *)extern "C", JIM *) That looks wrong to me, assuming you're feeding it the same symbols. Quote: The difference is the extern "C" at end of third parameter. I suspect the extra extern "C" is actually needed on my z/OS mainframe platform to distinguish between C and C++ functions since the 1st parm is a C++ function pointer and the 3rd parm is a C function pointer. I suspect the difference in the mangled names is due to one of them containing the extern "C" info. Doubt it. I don't see anything in those symbols that indicates an extern "C". <snip> Quote: p.s. If someone can point me to current c++filt source code I might be able to puzzle it out myself. Here's the GNU version: <http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/binutils/cxxfilt.c?cvsroot=src> <http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/libiberty/cplus-dem.c?cvsroot=src> (note, cp-demangle.c is for demangling a new mangling format and will not be useful for you). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ken Hagan Guest Posted: Sat Aug 16, 2003 3:56 pm    Post subject: Re: remedial demangling "Jim Keohane" <jimkeo (AT) multi-platforms (DOT) com> wrote... Quote: I have 2 questions, kind folks. 1. Is it correct for a demangler to generate the same results from two different mangled names? Yes. For example, the MS mangling scheme allows an "abbreviation" mechanism which means the mangled name doesn't have to repeat class names. The compiler will always emit abbreviated names, but it would not be unreasonable for a demangler to tolerate the full form. Related question: Is it correct for a compiler to emit different results for two occurences of the same unmangled name? No, that would give you a linker error. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Tue Aug 19, 2003 12:15 pm    Post subject: Re: remedial demangling In article <12bc9e26.0308181131.6f49470c (AT) posting (DOT) google.com>, Jim Keohane wrote: Quote: Ben & Ken, Thanks muchly! The abbreviation "T1" is interesting as I received an UNRESOLVED during link bind with one of the mangled names in the unresolved error message and the other mangled name in the compiler output itself. This was IBM's C++ compiler on their mainframe z/OS USS (Unix System Services). One question is why the two different generated names that are actually the same. Other question is why binder/linker not smart enough to realize they're the same? They shouldn't be treated the same. The compiler must generate the same names consistently. If it generates different names in different translation units, they are probably being compiled using different and incompatible settings. The name-mangling difference is just one symptom of that. You need to fix the problem, not the symptom. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top llewelly Guest Posted: Thu Aug 21, 2003 11:02 am    Post subject: Re: remedial demangling Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes: Quote: In article <864r0d8v2j.fsf (AT) Zorthluthik (DOT) local.bar>, llewelly wrote: [email]jimkeo (AT) multi-platforms (DOT) com[/email] (Jim Keohane) writes: Ben & Ken, Thanks muchly! The abbreviation "T1" is interesting as I received an UNRESOLVED during link bind with one of the mangled names in the unresolved error message and the other mangled name in the compiler output itself. This was IBM's C++ compiler on their mainframe z/OS USS (Unix System Services). One question is why the two different generated names that are actually the same. Other question is why binder/linker not smart enough to realize they're the same? [snip] By my reading of http://www.codesourcery.com/cxx-abi/abi.html#mangling, the T1 abbreviation is allowed only in template instantiations - not in ordinary functions. What relevance does that have to this compiler? oops. None, sorry, I was confused. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michiel Salters Guest Posted: Fri Aug 22, 2003 9:52 am    Post subject: Re: remedial demangling "Ken Hagan" <K.Hagan (AT) thermoteknix (DOT) co.uk> wrote Quote: Related question: Is it correct for a compiler to emit different results for two occurences of the same unmangled name? No, that would give you a linker error. Not if the linker is smart enough to convert these mangled names to a canonical form before determining equivalence. The standard requires that (only) identical types can be linked, and doesn't care how a compiler and a linker achieve that. Regards, -- Michiel Salters [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jim Keohane Guest Posted: Sat Aug 30, 2003 10:53 am    Post subject: Re: remedial demangling Thanks, one and all. I do have a linker $UNRESOLVED$ error and it is the same compiler during a build/make of an application that generates different mangled names. I have opened a problem issue with compiler vendor. I forget which is which but the compiler generates one of the two mangled versions (abbreviated or not) for the actual class method body and the other mangled version for the sole reference/invocation in another source/class file. I thought, as others have said, the compiler should be consistent. Next best thing might be for linker, after being unable to resolve a reference, to try a hopefully quick second pass looking for the reverse mangled version (if abbreviated then try full and vice versa). I suppose linker wouldn't even bother to do a second pass unless the name it was searching for either was already abbreviated or, if not abbreviated (T1?), contained dupe class references. Consistent compiler would be the obvious *best* remedy but... Thanks double muchly! - Jim Keohane Quote: Related question: Is it correct for a compiler to emit different results for two occurences of the same unmangled name? No, that would give you a linker error. Not if the linker is smart enough to convert these mangled names to a canonical form before determining equivalence. The standard requires that (only) identical types can be linked, and doesn't care how a compiler and a linker achieve that. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.