Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!infopiz!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.lang.c++ Subject: Re: Let's write a new linker! (Was: Re: Naming Conventions) Keywords: name mangling linking symbol clashes Message-ID: <3782@lupine.NCD.COM> Date: 8 Feb 91 05:17:29 GMT References: <1604@tcs.tcs.com> <474@mole-end.UUCP> Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 52 In article <474@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes: +> What, with name mangling and symbol clashes, what we really need is a +> new linker. The whole concept of name mangling just to be able to use the +> venerable UNIX linker should be tossed. Yeah, and I can hear to screams of +> agony as some people would switch to such a linker before others. Still, +> I've long thought name mangling is revolting. + +I'm inclined to agree that we need better linkers, but I don't know how we +can get them. It's hard to force linkers on operating systems, especially +since there are a few machines (HP3000, for example) whose architectures +require that the linker be a trusted program to ensure the security of the +operating system. I'm inclined to disagree that we need new linkers before we can rid ourselves of the various link-time problems caused by "name mangling". In fact, what is needed is *not* new linkers but rather new assemblers and C compilers. Name mangling is used in the cfront translator because it generates C and because there are no C compilers which accept "void func (int, int)" as an identifier. Likewise, g++ (which generates assembly code directly) must use name mangling because no existing assembler accepts the string "void func (int, int)" as an identifier. By the time the "name" strings get down into the object files, it no longer really matters whether or not they contain "special" characters (or even blanks). By that time, the only tools that will be doing anything with the "name" strings are the linker and possibly some object-file-dump program. Those programs probably don't give a damn what characters appear the strings in the linker symbol table. Just considering *real* C++ compilers for a moment (e.g. g++) we could rid ourselves of the linking problems that name mangling causes if we had assemblers which allowed something like: .alias func__FiT1,"void func (int, int)" This directive would allow the (mangled) name "func__FiT1" to be used throughout the generated assembly code, but when it came time for the assembler to generate the object file, it would place the string "void func (int, int)" into the object file symbol table instead of "func__FiT1". For C++ translators (like cfront), a similar facility at the level of the C compiler would likewise be useful. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.