bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/24836] --as-needed leaves unused direct dependencies


From: crusader.mike at gmail dot com
Subject: [Bug ld/24836] --as-needed leaves unused direct dependencies
Date: Mon, 29 Jul 2019 20:29:34 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]