handle <local-source-name> in demangler

Geoffrey Keating geoffk@apple.com
Thu Nov 9 23:59:00 GMT 2006


On 08/11/2006, at 5:28 PM, Mark Mitchell wrote:

> I think the mangling itself is fine.
>
> However, I still think that it is important to have aliasing  
> directives for the assembler so that whatever name-mangling you use  
> does not reach object files on systems with the appropriate  
> assembler support.  And, I still think you should commit to those  
> improvements as part of the work that you are doing.  In particular,  
> I don't think you should make changes to G++ that make these new  
> mangled names show up on GNU/Linux systems, provided people have new  
> enough assemblers.  If you will do this, it will help both LTO and  
> IMA.
>
> Since you've complained in the past that people have objected to  
> some of your changes only after you have checked in patches, I want  
> to make it clear that I'm objecting now.

Thank you for making it clear that you're objecting now!

I don't think I can commit to doing any work on GAS.  If the new  
assembler becomes available before I've finished IMA, then I will try  
to make IMA use the new feature; this may or may not be useful for  
LTO.  If the new assembler is not available then, what I have  
implemented now is that on ELF systems, if the compiler ever tries to  
put out a name in the new mangling then it will call sorry().  Is this  
acceptable?

Even if I decide to never contribute the IMA changes, cxxfilt should  
still support demangling these names, for compatibility with the Apple  
compiler and to interpret files produced with LTO (including assembly  
files on all systems and .o files on non-ELF systems), and so I should  
commit this patch (as modified once we've decided what the actual  
mangling should be).  Is this acceptable?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2462 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20061109/f4683138/attachment.p7s>


More information about the Gcc-patches mailing list