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