namespace namespace

Dave Korn dave.korn.cygwin@googlemail.com
Tue Jul 7 21:38:00 GMT 2009


Dave Korn wrote:
> Jakub Jelinek wrote:
>>>> 000139c0 t
>>>> __ZN3gnu5javax3net3ssl8provider11CipherSuiteC1EPNS3_15CipherAlgorithmEPNS3_20KeyExchangeAlgorithmEPNS3_18SignatureAlgorithmEPNS3_12MacAlgorithmEiiiPN4java4lang6StringE.clone.1

>> No, C++ FE is innocent.  *.clone.NNN are created by function versioning, see
>> clone_function_name, and are never exported.
>                        ^^^^^^^^^^^^^^^^^^^^^^^
> 
>> If . doesn't work even for non-exported symbols on your target, the target
>> is misconfigured (look at NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL), if it
>> works, why do you have problems with it?
> 
>   I don't, but I didn't know that for sure until you said above that it would
> definitely never be exported.  

  Ok, now I do, and they are(*).

  I take it that this is a bug in the dllexport attribute getting propagated
unduly to clones when it should only be applied to the original (non-cloned)
version, and not that these clones are meant to be externally visible for some
reason I don't understand?

  There's presumably an issue with the handling in the backend hooks, which I
should be able to track down without too much difficulty, but you could help
me with one bit of advice: how do I detect when I've been handed the tree for
a decl of a cloned function rather than an original?

    cheers,
      DaveK
-- 
(*) - http://sourceware.org/ml/binutils/2009-07/msg00076.html



More information about the Java-patches mailing list