RFR: 8002034 and 8001756 - FDS changes mainly re cross-compiling

David Holmes david.holmes at oracle.com
Thu Nov 1 19:39:59 PDT 2012


On 2/11/2012 12:03 PM, BILL PITTORE wrote:
> On 11/1/2012 7:47 PM, David Holmes wrote:
>> On 2/11/2012 8:49 AM, Dmitry Samersoff wrote:
>>> David,
>>>
>>> Sorry, (my eyes) I misread if
>>>
>>> As far as I understand, cross compilation require explicit ALT_OBJCOPY.
>>
>> Yes.
>>
>>> Is there any defaults?
>>
>> No. The makefiles know nothing about the toolsets for cross-compiling.
> We set CC, CPP, CXX using COMPILER_PATH which gets us to the cross
> tools, why not go for OBJCOPY as well? It may or may not exist. Is that
> worse than the current situation?

Fair point, we could just assume that when cross-compiling we find 
objcopy in the same place as gcc etc.

Thanks,
David


> bill
>
>>
>>> Does it make sense to warn if ALT_OBJCOPY isn't set?
>>
>> The build already reports:
>>
>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
>> INFO: no objcopy cmd found so cannot create .debuginfo files.
>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0
>>
>> I could extend that to say:
>>
>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
>> INFO: no objcopy cmd found so cannot create .debuginfo files. You may
>> need to set ALT_OBJCOPY.
>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0
>>
>> Thanks,
>> David
>>>
>>> -Dmitry
>>>
>>> On 2012-11-02 02:15, David Holmes wrote:
>>>> Thanks for the review Dmitry.
>>>>
>>>> On 1/11/2012 10:02 PM, Dmitry Samersoff wrote:
>>>>> David,s
>>>>>
>>>>> if we use host /usr/bin/objcopy for cross compiling,
>>>>> changes looks good for me.
>>>>
>>>> ??? We don't use host /usr/bin/objcopy for cross-compiling that is why
>>>> DEF_OBJCOPY is only set when not cross-compiling.
>>>>
>>>> Of course you can set ALT_OBJCOPY=/usr/bin/objcopy when
>>>> cross-compiling.
>>>> It probably won't work but you can do it.
>>>>
>>>> David
>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2012-11-01 07:41, David Holmes wrote:
>>>>>> No takers so far - don't be shy, it's not a difficult one I
>>>>>> promise :)
>>>>>>
>>>>>> Updated webrev:
>>>>>> http://cr.openjdk.java.net/~dholmes/8002034/webrev.01/
>>>>>>
>>>>>> Because of the multiple sub-make invocations that occur during a
>>>>>> build
>>>>>> the FDS logic gets processed numerous times, many of which are not
>>>>>> needed and which might show confusing output (eg that FDS is enabled
>>>>>> when you have disabled it). So I added another conditional to at
>>>>>> least
>>>>>> check that BUILD_FLAVOR has been set - that excludes a couple of the
>>>>>> unnecessary executions.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 31/10/2012 5:29 PM, David Holmes wrote:
>>>>>>> http://cr.openjdk.java.net/~dholmes/8002034/webrev/
>>>>>>>
>>>>>>> This mainly addresses
>>>>>>>
>>>>>>> JDK-8002034 Allow Full Debug Symbols when cross-compiling
>>>>>>>
>>>>>>> The initial FDS work simply disables FDS when cross-compilation is
>>>>>>> involved. But we're now ready to deal with the cross-compilation
>>>>>>> case
>>>>>>> (and even if we weren't these changes would be fine anyway). So
>>>>>>> if FDS
>>>>>>> is initially enabled we will rely on ALT_OBJCOPY being set to the
>>>>>>> correct value for cross-compilation; and we don't set the default
>>>>>>> OBJCOPY in that case. So if you do nothing when cross-compiling
>>>>>>> OBJCOPY
>>>>>>> will be empty and that will cause the build to disable FDS, just
>>>>>>> as if
>>>>>>> the OBJCOPY command was not found.
>>>>>>>
>>>>>>> As this is the same code that causes:
>>>>>>>
>>>>>>> JDK-8001756 Hotspot makefiles report missing OBJCOPY command in the
>>>>>>> wrong circumstances
>>>>>>>
>>>>>>> I also fixed this by moving the OBJCOPY checks inside the
>>>>>>> ENABLE_FULL_DEBUG_SYMBOLS=1 conditional. Basically unless we are
>>>>>>> asking
>>>>>>> for FDS we shouldn't complain if the OBJCOPY command is not found.
>>>>>>>
>>>>>>> This will be pushed to the hotspot-emb repo as it is needed there
>>>>>>> ASAP.
>>>>>>>
>>>>>>> I'll be doing a similar change, under 8002040, for the JDK side of
>>>>>>> things.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>
>>>>>
>>>
>>>
>


More information about the hotspot-runtime-dev mailing list