[Bug ld/22269] Undefined weak symbols isn't resolved to 0 in static PIE

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22269

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Alan Modra from comment #11)
> > If there is a program bug:
> > ...
> > may lead to undesired behavior.
> 
> Quite so.
> 
> > -z dynamic-undefined-weak applies if there is a DT_NEEDED entry which
> > may provide definition for undefined weak reference at run-time.  For static
> > PIE, weak undefined should always be resolved to 0.
> 
> I agree, which is why I felt it was a good idea to default
> link_info.dynamic_undefined_weak to 0 when link_info.nointerp.

That is fine as long as "-z dynamic-undefined-weak" doesn't change
undefined weak symbol resolution in static PIE.

> Also, --no-dynamic-linker -z dynamic-undefined-weak probably ought to be an
> error, or at least warn.

Either is OK with me as long as undefined weak symbol is resolved to
0 in static PIE.

> However, making that change (or explicitly passing -z
> nodynamic-undefined-weak) results in x86 tests that fail, due to not
> generating a plt entry for the undefined weak call.  No matter how I look at

They fail because of undefined weak symbols in dynamic symbol table which
should be expected.  But undefined weak symbols are still resolved to 0 at
link-time.  I checked a few testcases to verify it.

> it, that is a bug in the x86 backend: link_info.dynamic_undefined_weak
> should not control the generation of a plt entry.  (I'm also of the opinion
> that adding a plt entry for an undefined weak without dynamic relocs is just
> bloat, but that's a separate issue and one I don't care to argue about.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.