[PATCH v2] hppa: Handle __gmon_start__ as undefined weak or hidden on hppa

[John David Anglin <dave dot anglin at bell dot net>]

On 2015-10-25, at 3:32 PM, John David Anglin wrote:

> The attached change fixes libc/19170.  It is identical to the approach used on ia64 aside from
> the hppa assembler code.


In testing, an issue was found with the previous change.  Final executables would generate a segmentation
fault in _dl_fixup (DL_FIXUP_MAKE_VALUE) when all instances of __gmon_start__ were removed from the
executable's dependent shared libraries.  Generally, this was easily fixed by rebuilding the executable but
this is problematic for tool-chain executables needing recursive builds.

The attached change facilitates the removal of the current weak definition of __gmon_start__.

The DL_FIXUP_MAKE_VALUE macro is updated so that it doesn't cause a segmentation fault when its
MAP argument is null.  It should be noted that the LOOKUP_VALUE_ADDRESS macro which also has
a MAP argument checks for a null value.  It now generates a null descriptor when MAP is null.
__canonicalize_funcptr_for_compare will now return null in a final executable if a function is undefined
due to library rebuilds.

Secondly, we now check in _dl_runtime_resolve whether _dl_fixup found the requested function and
if not it returns directly to the previous caller.  Of course, this only works once but that's all that's needed.
Old shared executables can resolve to their internal instance of __gmon_start__.  New executables
have checks that allow gmon_initializer to determine whether __gmon_start__ is defined or not.

The comment for gmon_initializer is updated to explain the treatment of PLABEL32 relocations in shared
and final executables.  gmon_initializer is updated to call __canonicalize_funcptr_for_compare.  This
doesn't significantly affect the fast path when __gmon_start__ is not defined, and resolution needs
doing when it is defined.  Also, function pointers are handled at runtime in shared executables.

There are significant advantages in having a weak undefined __gmon_start__.  The --as-needed processing
by ld works correctly and we don't end up with unnecessary libraries bound to an application.  Lazy
binding is also improved.

Okay?

Dave 
--
John David Anglin	dave.anglin@bell.net

Attachment: gmon_start_10.d.txt
Description: Text document