On Fri, 14 Apr 2023 00:34:14 GMT, Jiangli Zhou <jian...@openjdk.org> wrote:
>>> The direct renaming in this case seems to be more strait forward. >> >> If we were to do this then we should have a naming convention of some kind >> e.g. `<lib-name>_<var-name>` but it strikes me as wrong as the code >> shouldn't need to know what library it is part of. In this case we do >> something as a simple point-fix, but to me it says there is a bigger problem. > >> I'm not familiar with the details of symbol scoping and linkage with >> libraries, but I would have hoped there was a way to have symbols like this >> shareable throughout the code that comprises the library without exposing >> them to users of the library. It used to be IIRC only functions we listed in >> the mapfiles were exposed, and these days we use explicit attributes to >> export them. Is there not some equivalent thing for data? > > If my understanding is correct the mapfile is for exported symbols, which are > in the export table. Those symbols can be dynamically looked up, e.g. via > dlsym. By default, '-fvisibility=hidden' is used > (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). > The symbols are '.hidden' by default if not exported. E.g. jmm_interface is > 'hidden' as objdump shows below. However, the linker error that we are seeing > here for statically linking the libraries together is a different issue. The > linker founds multiple ones in different object files, hence the failures. > We'd have to change to use internal linkage for the affect variables to > resolve the failure if feasible (without renaming). Please let me know if I'm > missing anything. > > objdump: > ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: > not a dynamic object > SYMBOL TABLE: > 0000000000000000 l df *ABS* 0000000000000000 management_ext.c > ... > 0000000000000000 g F .text 0000000000000068 JNI_OnLoad > 0000000000000008 g O .bss 0000000000000008 .hidden jvm > 0000000000000000 *UND* 0000000000000000 JVM_GetManagement > 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface > 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version > If we were to do this then we should have a naming convention of some kind > e.g. `<lib-name>_<var-name>` but it strikes me as wrong as the code shouldn't > need to know what library it is part of. In this case we do something as a > simple point-fix, but to me it says there is a bigger problem. Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166165671
