[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-19 18:18 --- as I see in the code for lnkproperties.h public: // WARNING: Do *NOT* define this yourself. The SL5xxx from SHARP does NOT // have this class. #ifdef QTOPIA_INTERNAL_FSLP LnkProperties( AppLnk* lnk, QWidget* parent = 0 ); ~LnkProperties(); #endif and QTOPIA_INTERNAL_FSLP is not defined when compiling moc_lnkproperties.cpp so ~LnkProperties() is not seen as a result default desctructor is assumed by gcc and this one gets inlined hence the problem. So far this worked because symbol attributed were not merged. Thanks HJ and Alan. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From amodra at gmail dot com 2010-01-15 09:37 --- The sysv gabi says: When the link editor combines several relocatable object files, it does not allow multiple definitions of STB_GLOBAL symbols with the same name. On the other hand, if a defined global symbol exists, the appearance of a weak symbol with the same name will not cause an error. The link editor honors the global definition and ignores the weak ones. Similarly, if a common symbol exists (that is, a symbol whose st_shndx field holds SHN_COMMON), the appearance of a weak symbol with the same name will not cause an error. The link editor honors the common definition and ignores the weak ones. I interpret ignores to mean that whether the weak symbol is present or not, the end result should be the same. So I think HJ's 9670 patch to merge visibilty from the weak symbol to the strong one is totally bogus. -- What|Removed |Added AssignedTo|unassigned at sources dot |amodra at gmail dot com |redhat dot com | Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2010-01-15 09:37:08 date|| http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 13:13 --- (In reply to comment #2) The sysv gabi says: When the link editor combines several relocatable object files, it does not allow multiple definitions of STB_GLOBAL symbols with the same name. On the other hand, if a defined global symbol exists, the appearance of a weak symbol with the same name will not cause an error. The link editor honors the global definition and ignores the weak ones. Similarly, if a common symbol exists (that is, a symbol whose st_shndx field holds SHN_COMMON), the appearance of a weak symbol with the same name will not cause an error. The link editor honors the common definition and ignores the weak ones. I interpret ignores to mean that whether the weak symbol is present or not, the end result should be the same. So I think HJ's 9670 patch to merge visibilty from the weak symbol to the strong one is totally bogus. Well, is --- extern int foo (void) __attribute__((weak,__visibility__ (hidden))); --- valid or not? -- What|Removed |Added BugsThisDependsOn||9679 http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 13:37 --- In ./libqpe/moc_lnkproperties.o: 140: 000152 FUNCWEAK HIDDEN37 _ZN13LnkPropertiesD1Ev It is ignored only if there is a definition. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From amodra at gmail dot com 2010-01-15 13:55 --- HJ, I don't understand your point in comment #3. If your 9679 testcase isn't valid C then you had no reason to apply your 9679 patch. If your 9679 testcase is valid (and I think it is), then I believe the link error prior to your 9679 patch is simply due to a gcc bug. gcc ought to only generate an R_X86_64_PC32 reference to a function when the function is known to be local, and since a weak symbol can be overridden there is no guarantee that it is local. In reply to comment #4: Of course. My comment #2 is about the case when a strong global defined symbol exists. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 13:56 --- (In reply to comment #1) the testcase is here http://uclibc.org/~kraj/ld-pr11175.tar.bz2 The testcase is invalid. Linker never saw any definition of `LnkProperties::~LnkProperties()'. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 14:00 --- (In reply to comment #5) HJ, I don't understand your point in comment #3. If your 9679 testcase isn't valid C then you had no reason to apply your 9679 patch. If your 9679 testcase is valid (and I think it is), then I believe the link error prior to your 9679 patch is simply due to a gcc bug. gcc ought to only generate an R_X86_64_PC32 reference to a function when the function is known to be local, and since a weak symbol can be overridden there is no guarantee that it is local. Symbol visibility was introduced well after weak symbol. I will ask it in gABI group for clarification. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From amodra at gmail dot com 2010-01-15 14:05 --- In reply to comment #6. Look again. $ nm -o *.o | grep _ZN13LnkPropertiesD1Ev fileselector.o: U _ZN13LnkPropertiesD1Ev lnkproperties.o:0ae9 T _ZN13LnkPropertiesD1Ev moc_lnkproperties.o:0001 W _ZN13LnkPropertiesD1Ev -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 16:01 --- (In reply to comment #8) In reply to comment #6. Look again. $ nm -o *.o | grep _ZN13LnkPropertiesD1Ev fileselector.o: U _ZN13LnkPropertiesD1Ev lnkproperties.o:0ae9 T _ZN13LnkPropertiesD1Ev moc_lnkproperties.o:0001 W _ZN13LnkPropertiesD1Ev Is lnkproperties.o used for linking? -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 17:34 --- (In reply to comment #7) (In reply to comment #5) HJ, I don't understand your point in comment #3. If your 9679 testcase isn't valid C then you had no reason to apply your 9679 patch. If your 9679 testcase is valid (and I think it is), then I believe the link error prior to your 9679 patch is simply due to a gcc bug. gcc ought to only generate an R_X86_64_PC32 reference to a function when the function is known to be local, and since a weak symbol can be overridden there is no guarantee that it is local. Symbol visibility was introduced well after weak symbol. I will ask it in gABI group for clarification. According to discussions on gABI group: http://groups.google.com/group/generic-abi?hl=en GNU linker, gold and Sun linker all merge hidden visibility on weak symbol even when its definition is ignored. Closing as invalid. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-15 18:29 --- (In reply to comment #9) (In reply to comment #8) In reply to comment #6. Look again. $ nm -o *.o | grep _ZN13LnkPropertiesD1Ev fileselector.o: U _ZN13LnkPropertiesD1Ev lnkproperties.o:0ae9 T _ZN13LnkPropertiesD1Ev moc_lnkproperties.o:0001 W _ZN13LnkPropertiesD1Ev Is lnkproperties.o used for linking? yes it is look at the doit.sh script in the testcase. I don't think this can be closed as invalid just yet. There is a global definition for the symbol ~LnkProperties() as seen in lnkproperties.o and linker is making it HIDDEN in the final shared library which is not expected behaviour IMO. On other note this worked before and now it does not so either there has to be other way of doing it or its a regression. If you need to have a look at the sourcecode its here http://people.via.ecp.fr/~clem/nist/doxydoc/allOpie/ -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-15 18:42 --- after reading the googlegroups thread if ld will propagate most restrictive visibility to the output for a symbol irrespective of its definition then I think this is not what gcc thinks when generating code in this case. The testcase is compiled with -fvisibility-inlines-hidden -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 19:04 --- Created an attachment (id=4523) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4523action=view) A simple testcase [...@gnu-6 pr11175]$ make cc -fPIC -c -o x.o x.c cc -fPIC -c -o foo.o foo.c cc -fPIC -c -o bar.o bar.c ld -shared -o libx.so foo.o bar.o ld -e main -o x x.o libx.so x.o: In function `main': x.c:(.text+0x5): undefined reference to `foo' make: *** [x] Error 1 [...@gnu-6 pr11175]$ -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 19:15 --- (In reply to comment #12) after reading the googlegroups thread if ld will propagate most restrictive visibility to the output for a symbol irrespective of its definition then I think this is not what gcc thinks when generating code in this case. The testcase is compiled with -fvisibility-inlines-hidden libqpe isn't built correctly. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 19:22 --- `-fvisibility-inlines-hidden' This switch declares that the user does not attempt to compare pointers to inline methods where the addresses of the two functions were taken in different shared objects. The effect of this is that GCC may, effectively, mark inline methods with `__attribute__ ((visibility (hidden)))' so that they do not appear in the export table of a DSO and do not require a PLT indirection when used within the DSO. Enabling this option can have a dramatic effect on load and link times of a DSO as it massively reduces the size of the dynamic export table when the library makes heavy use of templates. Is LnkProperties::~LnkProperties() inlined? -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-15
21:37 ---
(In reply to comment #15)
`-fvisibility-inlines-hidden'
This switch declares that the user does not attempt to compare
pointers to inline methods where the addresses of the two functions
were taken in different shared objects.
The effect of this is that GCC may, effectively, mark inline
methods with `__attribute__ ((visibility (hidden)))' so that
they do not appear in the export table of a DSO and do not require
a PLT indirection when used within the DSO. Enabling this option
can have a dramatic effect on load and link times of a DSO as it
massively reduces the size of the dynamic export table when the
library makes heavy use of templates.
Is LnkProperties::~LnkProperties() inlined?
Its in the class in lnkproperties.h but defined in lnkproperties.cpp file
LnkProperties::~LnkProperties()
{
}
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11175
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
-- What|Removed |Added Attachment #4523|application/octet-stream|application/x-bzip mime type|| http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15
22:11 ---
(In reply to comment #16)
(In reply to comment #15)
`-fvisibility-inlines-hidden'
This switch declares that the user does not attempt to compare
pointers to inline methods where the addresses of the two functions
were taken in different shared objects.
The effect of this is that GCC may, effectively, mark inline
methods with `__attribute__ ((visibility (hidden)))' so that
they do not appear in the export table of a DSO and do not require
a PLT indirection when used within the DSO. Enabling this option
can have a dramatic effect on load and link times of a DSO as it
massively reduces the size of the dynamic export table when the
library makes heavy use of templates.
Is LnkProperties::~LnkProperties() inlined?
Its in the class in lnkproperties.h but defined in lnkproperties.cpp file
LnkProperties::~LnkProperties()
{
}
Please find out how it became` hidden and weak:
140: 000152 FUNCWEAK HIDDEN37 _ZN13LnkPropertiesD1Ev
in ./libqpe/moc_lnkproperties.o.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11175
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-16 00:25 --- Created an attachment (id=4524) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4524action=view) preprocessed testcase -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-16 00:41 --- (In reply to comment #19) (In reply to comment #18) Created an attachment (id=4524) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4524action=view) preprocessed testcase -fvisibility-inlines-hidden is making this difference. $ arm-oe-linux-gnueabi-g++ -c -fvisibility-inlines-hidden moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK HIDDEN 154 _ZN13LnkPropertiesD1Ev $ arm-oe-linux-gnueabi-g++ -c moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK DEFAULT 154 _ZN13LnkPropertiesD1Ev ~LnkProperties() isn't in moc_lnkproperties.i. gcc generates it and marks it hidden. You should add ~LnkProperties (); to class LnkProperties declaration so that gcc won't mark it hidden. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-16 00:27 --- (In reply to comment #18) Created an attachment (id=4524) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4524action=view) preprocessed testcase -fvisibility-inlines-hidden is making this difference. $ arm-oe-linux-gnueabi-g++ -c -fvisibility-inlines-hidden moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK HIDDEN 154 _ZN13LnkPropertiesD1Ev $ arm-oe-linux-gnueabi-g++ -c moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK DEFAULT 154 _ZN13LnkPropertiesD1Ev -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-16
01:06 ---
Here is a testcase:
[...@gnu-6 pr11175]$ cat z.cc
class QObject
{
public:
virtual ~QObject();
virtual const char *className() const;
};
class LnkProperties : public QObject
{
public:
const char *className() const;
};
const char *LnkProperties::className() const
{
return LnkProperties;
}
[...@gnu-6 pr11175]$ gcc -S z.cc -fvisibility-inlines-hidden;
[...@gnu-6 pr11175]$ grep _ZN13LnkPropertiesD2Ev z.s | grep hidden
.hidden _ZN13LnkPropertiesD2Ev
[...@gnu-6 pr11175]$
You can't have a different declaration of class LnkProperties with user
defined:
LnkProperties::~LnkProperties()
{
}
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11175
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-15 06:33 --- the testcase is here http://uclibc.org/~kraj/ld-pr11175.tar.bz2 -- What|Removed |Added Summary|ld marks destructor hidden |ld marks destructor hidden |global |global http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
