This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: namespace namespace


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]