https://sourceware.org/bugzilla/show_bug.cgi?id=24836
--- Comment #8 from crusader.mike at gmail dot com --- Alan, you are correct -- looks like garbage collection can remove symbol references to the point that final binary no longer needs given DT_NEEDED shared lib anymore. That is precisely what happens in my case. And if you carefully read --as-needed documentation -- it works precisely as declared (not as expected :)). Now question is: 1. Is there any way to discard DT_NEEDED entries that are no longer needed? (apparently determining this isn't trivial according to my admittedly basic understanding of dynamic linker's behavior) 2. Should --as-needed behavior be modified to address this? Or is it better to make --gc-section sensitive to --as-needed presence (and perform additional cleanup)? Additionally, I've read a lot about [dynamic] linker behavior (big thanks to gold's author for blog posts/etc) and can answer some of my own questions: 3. That weird symbol in my final binary is an inline C++ function (XalanVector<...> destructor) that wasn't inlined. 4. ~XalanVector() wasn't garbage collected very likely because there is a global variable that uses it. Is there any way to track down that variable? 5. There is no corresponding constructor because it was inlined. 6. I can't explain why that destructor produced two entries in .dynsym table (which end with EEED1Ev and EEED2Ev respectively). Interestingly they both have same address/type/etc. My mapfile mentions only one of them: .text 0x00000000004074e0 0x2cd72 ... .text._ZN11xalanc_1_1111XalanVectorItNS_31MemoryManagedConstructionTraitsItEEED2Ev 0x0000000000415bb0 0x21 ../../CommonLib/libCommon.a(NXMLNodeUnix.cpp.o) 0x0000000000415bb0 xalanc_1_11::XalanVector<unsigned short, xalanc_1_11::MemoryManagedConstructionTraits<unsigned short> >::~XalanVector() 0x0000000000415bb0 xalanc_1_11::XalanVector<unsigned short, xalanc_1_11::MemoryManagedConstructionTraits<unsigned short> >::~XalanVector() plus an entry in .gcc_except_table (I assume this is used during stack unwinding): .gcc_except_table ... .gcc_except_table._ZN11xalanc_1_1111XalanVectorItNS_31MemoryManagedConstructionTraitsItEEED2Ev 0x000000000044137e 0x4 ../../CommonLib/libCommon.a(NXMLNodeUnix.cpp.o) I would appreciate any help explaining origin and purpose of EEED1Ev symbol. 7. I find it curious that my final binary contains huge .dynsym table. Even if few symbols are actually used by shared libs -- should be rest of those entries removed to save space? Is there a way to find which ones of these symbols are used (and by which shared lib)? -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils