|
»
»
Re: namespace namespace
|
View:
New views
17 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: namespace namespace
by Joseph S. Myers
::
Rate this Message:
On Mon, 29 Jun 2009, Andrew Haley wrote:
> Also, the set of C++ keywords in gjavah is different from the set in gcj. Sounds like you should put a comment where the G++ list of keywords is, saying that if you change the list of keywords for C++ you need to update <list of other places in gcj, gjavah etc.> to keep those other lists in sync - logically any addition of a C++ keyword should start with adding it for the C++ front end. -- Joseph S. Myers joseph@... |
|
|
Re: namespace namespace
by Andrew Haley
::
Rate this Message:
Joseph S. Myers wrote:
> On Mon, 29 Jun 2009, Andrew Haley wrote: > >> Also, the set of C++ keywords in gjavah is different from the set in gcj. > > Sounds like you should put a comment where the G++ list of keywords is, > saying that if you change the list of keywords for C++ you need to update > <list of other places in gcj, gjavah etc.> to keep those other lists in > sync - logically any addition of a C++ keyword should start with adding it > for the C++ front end. Will do. Andrew. |
|
|
Re: namespace namespace
by Dave Korn-6
::
Rate this Message:
Andrew Haley wrote:
> This is an ABI change. However, the ABI was almost completely broken > anyway. Tangentially-related: Would it ever be possible to change the use of periods as separators in java mangled names too, or is that too deeply entrenched or part of a standard? cheers, DaveK |
|
|
Re: namespace namespace
by Andrew Haley
::
Rate this Message:
Dave Korn wrote:
> Andrew Haley wrote: > >> This is an ABI change. However, the ABI was almost completely broken >> anyway. > > Tangentially-related: Would it ever be possible to change the use of periods > as separators in java mangled names too, or is that too deeply entrenched or > part of a standard? I suppose it could be done. Is there some big problem with periods that I don't know about? For example, java.lang.Object.class is mangled as _ZN4java4lang6Object6class$E. When do you see a problem with the use of periods as separators? Andrew. |
|
|
Re: namespace namespace
by Dave Korn-6
::
Rate this Message:
Andrew Haley wrote:
> Dave Korn wrote: >> Andrew Haley wrote: >> >>> This is an ABI change. However, the ABI was almost completely broken >>> anyway. >> Tangentially-related: Would it ever be possible to change the use of periods >> as separators in java mangled names too, or is that too deeply entrenched or >> part of a standard? > > I suppose it could be done. Is there some big problem with periods that > I don't know about? > > For example, java.lang.Object.class is mangled as _ZN4java4lang6Object6class$E. The kind of symbols I'm talking about are those with real actual periods in them, things I've seen in libjava, such as these: gnu/.libs/classpath.o: 00000030 r _java.io.IOException_ref.1567 00000034 r _java.io.IOException_ref.3036 0000002c r _java.lang.Exception_ref.1841 or these (from unidentified .o files): 000139c0 t __ZN3gnu5javax3net3ssl8provider11CipherSuiteC1EPNS3_15CipherAlgorithmEPNS3_20KeyExchangeAlgorithmEPNS3_18SignatureAlgorithmEPNS3_12MacAlgorithmEiiiPN4java4lang6StringE.clone.1 0002a9b0 t __ZN3gnu5javax3net3ssl8provider4Util11toHexStringEJPN4java4lang6StringEP6JArrayIcEw.clone.0 000139c0 t __ZN3gnu5javax3net3ssl8provider11CipherSuiteC1EPNS3_15CipherAlgorithmEPNS3_20KeyExchangeAlgorithmEPNS3_18SignatureAlgorithmEPNS3_12MacAlgorithmEiiiPN4java4lang6StringE.clone.1 0002a9b0 t __ZN3gnu5javax3net3ssl8provider4Util11toHexStringEJPN4java4lang6StringEP6JArrayIcEw.clone.0 00000d10 t __ZN3gnu5javax5swing4text4html6parser7support3low4nodeC1Eib.clone.0 00000f72 r __Utf106.2066 00000fe0 r __Utf117.2121 000002f4 r __Utf17.1621 00003b54 r __Utf1042.35506 0000c696 r __Utf1757.124553 000001d4 r _CSWTCH.18597 000001d4 r _CSWTCH.18597 00000000 d ___emutls_v._ZL12method_cache 00000020 t __Z17JvNewStringLatin1PKc.clone.0 > When do you see a problem with the use of periods as separators? Actually, there may not be a problem at all. There is a /potential/ problem relating to the export of symbols from DLLS, specified using DEF files. The syntax of DEF files uses periods as a separator in entries that forward an export to another DLL, so having periods in the symbol names would cause ambiguity in the grammar. Like I said I've seen these mysterious symbols with literal periods in them, but I don't know what they actually are. On closer inspection while writing this mail, I suddenly notice that they all appear to be local symbols; if this is always the case, then there's no problem at all because we'll never want to export them from a DLL. And noticing the '.clone.' in there makes me wonder if this is in fact an entirely C++ issue and not Java at all? (In which case sorry for bothering you with something that's not your department!) cheers, DaveK |
|
|
Re: namespace namespace
by Andrew Haley
::
Rate this Message:
Dave Korn wrote:
> Andrew Haley wrote: >> Dave Korn wrote: >>> Andrew Haley wrote: >>> >>>> This is an ABI change. However, the ABI was almost completely broken >>>> anyway. >>> Tangentially-related: Would it ever be possible to change the use of periods >>> as separators in java mangled names too, or is that too deeply entrenched or >>> part of a standard? >> I suppose it could be done. Is there some big problem with periods that >> I don't know about? >> >> For example, java.lang.Object.class is mangled as _ZN4java4lang6Object6class$E. > > The kind of symbols I'm talking about are those with real actual periods in > them, things I've seen in libjava, such as these: > > gnu/.libs/classpath.o: > > 00000030 r _java.io.IOException_ref.1567 > 00000034 r _java.io.IOException_ref.3036 > 0000002c r _java.lang.Exception_ref.1841 OK, I could fix those, but they're internal anyway. > or these (from unidentified .o files): > > 000139c0 t > __ZN3gnu5javax3net3ssl8provider11CipherSuiteC1EPNS3_15CipherAlgorithmEPNS3_20KeyExchangeAlgorithmEPNS3_18SignatureAlgorithmEPNS3_12MacAlgorithmEiiiPN4java4lang6StringE.clone.1 All this .clone stuff is to do with template instantiation in the C++ compiler. > Like I said I've seen these mysterious symbols with literal periods in them, > but I don't know what they actually are. On closer inspection while writing > this mail, I suddenly notice that they all appear to be local symbols; if this > is always the case, then there's no problem at all because we'll never want to > export them from a DLL. And noticing the '.clone.' in there makes me wonder > if this is in fact an entirely C++ issue and not Java at all? (In which case > sorry for bothering you with something that's not your department!) Blame C++, that's what I say. Andrew. |
|
|
Re: namespace namespace
by Dave Korn-6
::
Rate this Message:
Dave Korn wrote:
> And noticing the '.clone.' in there makes me wonder > if this is in fact an entirely C++ issue and not Java at all? (In which case > sorry for bothering you with something that's not your department!) Sorry for bothering you with something that's not your department. I guess windows platforms should probably define NO_DOT_IN_LABEL. cheers, DaveK |
|
|
Re: namespace namespace
by Jakub Jelinek
::
Rate this Message:
On Tue, Jun 30, 2009 at 02:30:18PM +0100, Andrew Haley wrote:
> > 000139c0 t > > __ZN3gnu5javax3net3ssl8provider11CipherSuiteC1EPNS3_15CipherAlgorithmEPNS3_20KeyExchangeAlgorithmEPNS3_18SignatureAlgorithmEPNS3_12MacAlgorithmEiiiPN4java4lang6StringE.clone.1 > > All this .clone stuff is to do with template instantiation in the C++ compiler. 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? Jakub |
|
|
Re: namespace namespace
by Dave Korn-6
::
Rate this Message:
Jakub Jelinek wrote:
> On Tue, Jun 30, 2009 at 02:30:18PM +0100, Andrew Haley wrote: >>> 000139c0 t >>> __ZN3gnu5javax3net3ssl8provider11CipherSuiteC1EPNS3_15CipherAlgorithmEPNS3_20KeyExchangeAlgorithmEPNS3_18SignatureAlgorithmEPNS3_12MacAlgorithmEiiiPN4java4lang6StringE.clone.1 >> All this .clone stuff is to do with template instantiation in the C++ compiler. > > 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. Thanks for the advice. From what Andrew says, it seems the java symbols will also never be exported, so there's not going to be a problem. cheers, DaveK |
|
|
Re: namespace namespace
by Ian Lance Taylor-3
::
Rate this Message:
Andrew Haley <aph@...> writes:
> It turns out that the mangling of C++ keywords used by gcj is completely > broken: > > In particular, when a member name is a C++ keyword, "$" is appended to the > name. However, this is results in an illegal mangled name so it is not > possible to refer to the member from CNI code. > > Also, the set of C++ keywords in gjavah is different from the set in gcj. > > Also, types are not checked for C++ keywords, so javax.xml.namespace.* cannot > be referenced from CNI code. > > This patch fixes the problem. > > This is an ABI change. However, the ABI was almost completely broken > anyway. Does this require any changes to the demangler? Note that the demangler currently has a special case for this: /* A Java mangled name may have a trailing '$' if it is a C++ keyword. This '$' is not included in the length count. We just ignore the '$'. */ if ((di->options & DMGL_JAVA) != 0 && d_peek_char (di) == '$') d_advance (di, 1); Ian |
|
|
Re: namespace namespace
by Andrew Haley
::
Rate this Message:
Ian Lance Taylor wrote:
> Andrew Haley <aph@...> writes: > >> It turns out that the mangling of C++ keywords used by gcj is completely >> broken: >> >> In particular, when a member name is a C++ keyword, "$" is appended to the >> name. However, this is results in an illegal mangled name so it is not >> possible to refer to the member from CNI code. >> >> Also, the set of C++ keywords in gjavah is different from the set in gcj. >> >> Also, types are not checked for C++ keywords, so javax.xml.namespace.* cannot >> be referenced from CNI code. >> >> This patch fixes the problem. >> >> This is an ABI change. However, the ABI was almost completely broken >> anyway. > > Does this require any changes to the demangler? Good point. I suppose that for really pedantic accuracy there should be, yes. > Note that the demangler currently has a special case for this: > > /* A Java mangled name may have a trailing '$' if it is a C++ > keyword. This '$' is not included in the length count. We just > ignore the '$'. */ > if ((di->options & DMGL_JAVA) != 0 > && d_peek_char (di) == '$') > d_advance (di, 1); How interesting. I didn't know that. I'm pretty sure that it can't possibly have worked, since there would have been no way for CNI code to refer to methods or objects that had name components that were C++ keywords. Unless, perhaps, there was a similar hack in the C++ compiler, but what would have been the point? Baffling. Thanks, Andrew. |
|
|
Re: namespace namespace
by Dave Korn-6
::
Rate this Message:
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 |
|
|
Re: namespace namespace
by Jakub Jelinek
::
Rate this Message:
On Tue, Jul 07, 2009 at 10:51:27PM +0100, Dave Korn wrote:
> > 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(*). That would be a target bug then. > 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? /* Update the properties. Make clone visible only within this translation unit. Make sure that is not weak also. ??? We cannot use COMDAT linkage because there is no ABI support for this. */ DECL_EXTERNAL (new_node->decl) = 0; DECL_COMDAT_GROUP (new_node->decl) = 0; TREE_PUBLIC (new_node->decl) = 0; DECL_COMDAT (new_node->decl) = 0; DECL_WEAK (new_node->decl) = 0; Certainly !TREE_PUBLIC functions shouldn't be exported from the current assembly file in any way... Jakub |
|
|
Re: namespace namespace
by Dave Korn-6
::
Rate this Message:
Jakub Jelinek wrote:
> On Tue, Jul 07, 2009 at 10:51:27PM +0100, Dave Korn wrote: >>> 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(*). > > That would be a target bug then. Yep, that's what I meant by target hooks. >> 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? > > /* Update the properties. > Make clone visible only within this translation unit. Make sure > that is not weak also. > ??? We cannot use COMDAT linkage because there is no > ABI support for this. */ > DECL_EXTERNAL (new_node->decl) = 0; > DECL_COMDAT_GROUP (new_node->decl) = 0; > TREE_PUBLIC (new_node->decl) = 0; > DECL_COMDAT (new_node->decl) = 0; > DECL_WEAK (new_node->decl) = 0; > > Certainly !TREE_PUBLIC functions shouldn't be exported from the current > assembly file in any way... That should do for me. Thanks! cheers, DaveK |
|
|
Re: namespace namespace
by Dave Korn-6
::
Rate this Message:
Jakub Jelinek wrote:
> /* Update the properties. > Make clone visible only within this translation unit. Make sure > that is not weak also. > ??? We cannot use COMDAT linkage because there is no > ABI support for this. */ > DECL_EXTERNAL (new_node->decl) = 0; > DECL_COMDAT_GROUP (new_node->decl) = 0; > TREE_PUBLIC (new_node->decl) = 0; > DECL_COMDAT (new_node->decl) = 0; > DECL_WEAK (new_node->decl) = 0; > > Certainly !TREE_PUBLIC functions shouldn't be exported from the current > assembly file in any way... Is there a reason why not to set DECL_ARTIFICIAL on these clones? cheers, DaveK |
|
|
Re: namespace namespace
by Tom Tromey
::
Rate this Message:
>>>>> "Andrew" == Andrew Haley <aph@...> writes:
>> Note that the demangler currently has a special case for this: >> /* A Java mangled name may have a trailing '$' if it is a C++ >> keyword. This '$' is not included in the length count. We just >> ignore the '$'. */ >> if ((di->options & DMGL_JAVA) != 0 >> && d_peek_char (di) == '$') >> d_advance (di, 1); Andrew> How interesting. I didn't know that. Andrew> I'm pretty sure that it can't possibly have worked, since Andrew> there would have been no way for CNI code to refer to methods Andrew> or objects that had name components that were C++ keywords. Andrew> Unless, perhaps, there was a similar hack in the C++ compiler, Andrew> but what would have been the point? Baffling. Baffling and gcj ... must be my doing! I don't think I considered namespace components back in the day, only virtual methods and instance fields. These were needed to compile libjava itself (I've long forgotten the examples) and could work purely by changing gcjh's output. Tom |
| Free embeddable forum powered by Nabble | Forum Help |
