objcopy issues on Solaris

Tue May 2 01:02:28 UTC 2017

On 29/04/2017 2:00 AM, Reingruber, Richard wrote:
> Hi Erik,
>
> I noticed this workaround, but apparently it was removed again from the hotspot build with http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/8c76e844a7f9.
>
> This confused me, nevertheless I tried it.
>
>   fix_empty_sec_hdr_flags libjvm.so
>   objcopy --only-keep-debug libjvm.so libjvm.debuginfo     # here I got the "Not enough room for program headers, try linking with -N"
>   add_gnu_debuglink libjvm.debuginfo libjvm.so
>
> Succeeds: now I got a libjvm.debuginfo, but it seems to be corrupted:
>
>   $ elfdump libjvm.debuginfo > dump.txt
>   Segmentation Fault (core dumped)
>
> I assume the workaround was removed because of this corruption(that's what the bugs JDK-8034005 and JDK-8033602 suggest), but why was it kept for the jdk build then? Do you know?

Magnus cleaned it all up in 9 under:

http://hg.openjdk.java.net/jdk9/dev/rev/f105fbc01fd7

but there was no backport to 8u.

> I was hoping that Oracle's binutils 2.21.1 contains fixes for the issues which are not yet pushed upstream. This would explain my problems with binutils 2.28 from gnu.org

I have no idea what the policy was regarding pushing anything upstream 
in this area, but 2.21.1 was certainly addressing some solaris specific 
issues. I don't think the bug system these numbers refer to still exists:

7004268 update binutils to 2.21.1
7157682 gobjcopy sets .SUNW_cap section attributes to 0
7165526 gobjcopy corrupts SUNW_dof section in libjvm.so and breaks dtrace

David

> Cheers, Richard.
>
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> Sent: Freitag, 28. April 2017 15:34
> To: Baesken, Matthias <matthias.baesken at sap.com>; David Holmes <david.holmes at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' <magnus.ihse.bursie at oracle.com>
> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard <richard.reingruber at sap.com>
> Subject: Re: objcopy issues on Solaris
>
> Hello,
>
> In jdk8u we still have this workaround for broken gobjcopy in
> NativeCompilation.gmk:
>
> # gobjcopy crashes on "empty" section headers with the SHF_ALLOC flag set.
> # Use $(FIX_EMPTY_SEC_HDR_FLAGS) to clear the SHF_ALLOC flag (if set) from
> # empty section headers until a fixed $(OBJCOPY) is available.
> # An empty section header has sh_addr == 0 and sh_size == 0.
> # This problem has only been seen on Solaris X64, but we call this tool
> # on all Solaris builds just in case.
> #
> # $(OBJCOPY) --add-gnu-debuglink=... corrupts SUNW_* sections.
> # Use $(ADD_GNU_DEBUGLINK) until a fixed $(OBJCOPY) is available.
> $$($1_OBJECT_DIR)/$$(LIBRARY_PREFIX)$$($1_LIBRARY).debuginfo :
> $$($1_TARGET) \
>                  $(FIX_EMPTY_SEC_HDR_FLAGS) $(ADD_GNU_DEBUGLINK)
>          $(RM) $$@
>          $(FIX_EMPTY_SEC_HDR_FLAGS) $(LOG_INFO) $$<
>          $(OBJCOPY) --only-keep-debug $$< $$@
>          $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$<
>
> I don't know if this is related to your problem. We were able to remove
> the above in JDK 9 because gobjcopy in Solaris 11 is not exhibiting this
> problem for us. The introduction of this workaround is from before my
> time so I don't know the details. The tools FIX_EMPTY_SEC_HDR_FLAGS and
> ADD_GNU_DEBUGLINK are in the jdk8u src.
>
> I checked a build machine for jdk8u and it reports "GNU objcopy 2.15"
> and this seems to be from the default OS package (Solaris 10). We have
> had problems with bugs in gobjcopy in the past though. (Example
> https://bugs.openjdk.java.net/browse/JDK-8034021) So try to get all the
> latest patches for it.
>
> /Erik
>
> On 2017-04-28 14:20, Baesken, Matthias wrote:
>>> GNU objcopy (GNU Binutils) 2.21.1
>>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>> This is a Solaris 11u1 package.
>>
>> Hi David, thanks for the info.
>> But what about  Solaris 10 ?
>>
>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>
>> mentions 10u6  supported for JDK8 .
>>
>> And  does  the  11u1 package   developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>    Contain special objcopy patches ?
>>
>> Best regards, Matthias
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 28. April 2017 13:24
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; Erik Joelsson (erik.joelsson at oracle.com) <erik.joelsson at oracle.com>; 'magnus.ihse.bursie at oracle.com' <magnus.ihse.bursie at oracle.com>
>> Cc: Simonis, Volker <volker.simonis at sap.com>; Reingruber, Richard <richard.reingruber at sap.com>
>> Subject: Re: objcopy issues on Solaris
>>
>> Hi Matthias,
>>
>> On 28/04/2017 7:21 PM, Baesken, Matthias wrote:
>>> Hello, we are facing problems with gobjcopy on Solaris 10 x86_64.
>>> When processing libjvm.so (product build) with FDS and separated debug-infos we are getting :
>>>
>>> objcopy: libjvm.debuginfo: Not enough room for program headers, try linking with -N
>>>
>>> It looks like we are running into this (or a similar) problems :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-7165598
>>>
>>> As recommended in those bugs :
>>>
>>>    x86
>>>    https://bugs.openjdk.java.net/browse/JDK-8034005
>>>
>>>    (and similar Sparc issue)
>>>    https://bugs.openjdk.java.net/browse/JDK-8033602
>>>
>>> We are using objcopy from binutils-2.28 (downloaded and built ourselves from standard binutils gnu.org page)
>>> and still get the mentioned error.
>>>
>>> In the OpenJDK version checks, 2.21 seems to be needed minimum,
>>> the comments in version check says "objcopy prior to 2.21.1 on solaris is broken and is not usable.".
>>>
>>> Could you tell us the exact version of  objcopy / gobjcopy  you are using in 8 and 9 on Solaris  to
>>> process the debuginfo ?
>>> And where do you get the gobjcopy from?
>> GNU objcopy (GNU Binutils) 2.21.1
>>
>> developer/gnu-binutils at 2.21.1-0.175.1.0.0.24.0
>>
>> This is a Solaris 11u1 package.
>>
>> David
>> -----
>>
>>> Thanks, Richard and Matthias
>>>
>