Any support for not stripping binaries?

David Holmes david.holmes at oracle.com
Thu Mar 14 21:24:54 PDT 2013


On 15/03/2013 1:46 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 15/03/2013 9:46 AM, Omair Majid wrote:
>>>
>>> I was wondering if there a known way to avoid stripping binaries?
>>>
>>> I tried the following configuration
>>> $ bash configure --enable-debug --disable-zip-debug-info
>>> $ make POST_STRIP_CMD='' STRIP_POLICY=no_strip DEBUG_BINARIES=true
>>> all
>>>
>>> The hotspot shared objects (such as libjvm.so, libjsgi.so,
>>> libattach.so)
>>> still had DWARF information, but all JDK shared objects (such as
>>> the
>>> java launcher, libawt.so) seem to be stripped.
>>>
>>> Is there a way to emulate this style of the builds?
>>>
>>> $ make
>>>     DEBUG_CLASSFILES="true" \
>>>     DEBUG_BINARIES="true" \
>>>     STRIP_POLICY="no_strip"
>>
>> It appears not. STRIP_POLICY is not used on the jdk side of the build
>> any more (why? accidental omission in the conversion?) - though I
>> found
>> it somewhat dubious anyway. There's a tension between what to put in
>> in
>> the first place, versus what to strip out later. Eg creating libs
>> with
>> all symbols can be useful for debugging, but the final image can have
>> them stripped out. Problem then is that you need vastly more disk
>> space
>> during the build.
>>
>> Given that POST_STRIP_COMMAND= on the make invocation should nullify
>> post-stripping, I'm wondering if the problem is with what is getting
>> built in in the first place?
>>
>> And as you note hotspot deals with this it's own, potentially
>> incompatible, way.
>>
>
> It still seems to be using STRIP_POLICY, at least in b80.
> jdk/make/common/Library.gmk has:

That is the old build.

> There's a bug in that debuginfo files are always created, but that
> is true in 7 too (and something we patched locally in IcedTea for now,
> I think).
>
> I noticed that some JDK libraries have debuginfo files and some don't,
> so I compared libhprof with libawt.  And guess what?  libhprof's
> invocation of SetupNativeCompilation has DEBUG_SYMBOLS:=true
> while libawt's doesn't.

The Full Debug Symbol project had limited scope as to which 
libraries/binaries symbols were to be produced for and for which 
platforms - Dan Daugherty has covered this a couple of times in related 
email threads (sorry no quick cross-reference).

As was mentioned in those other threads we need to distinguish between 
Oracle JDK FDS needs and OpenJDK FDS needed.

> common/makefiles/NativeCompilation.gmk has:
>
>      ifneq (,$$($1_DEBUG_SYMBOLS))
>          ifeq ($(ENABLE_DEBUG_SYMBOLS), true)
>              # Programs don't get the debug symbols added in the old build. It's not clear if
>              # this is intentional.
>              ifeq ($$($1_PROGRAM),)
>                  $1_EXTRA_CFLAGS+=$(CFLAGS_DEBUG_SYMBOLS)
>                  $1_EXTRA_CXXFLAGS+=$(CXXFLAGS_DEBUG_SYMBOLS)
>              endif
>          endif
>      endif
>
> I don't see why we need two checks for enabling debug symbols.  At the very least,
> the default should be on.

There is currently a per-library setting and a global setting. The 
per-library settings are as per the scope of the FDS project just 
mentioned. Executables are excluded.

Long history here and it needs cleaning up in a way that will meet the 
needs of different builders of the OpenJDK sources.

David
-----

>
> As a quick fix, the outer conditional could be removed.
>
>> David
>> -----
>>
>>> Thanks,
>>> Omair
>>>
>>
>



More information about the build-infra-dev mailing list