On Mon, 13 Apr 2026 11:09:34 GMT, Matthias Baesken <[email protected]> wrote:

>> When building a JVM with -ffunction-sections in the C/C++ compile flags, the 
>> gtest os_linux.decoder_get_source_info_valid_vm fails and delivers another 
>> result
>> 
>> 
>> [ RUN ] os_linux.decoder_get_source_info_valid_vm
>> test/hotspot/gtest/runtime/test_os_linux.cpp:404: Failure
>> Expected equality of these values:
>>   buf
>>     Which is: "test_os_linux.cpp"
>>   "jniCheck.hpp"
>> 
>> [ FAILED ] os_linux.decoder_get_source_info_valid_vm (20 ms)
>> 
>> 
>> So for this compilation mode, it is probably better to avoid the check for 
>> this specific header.
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Filter out the function/data sections flags from libjvm gtest build

So we have a test that makes an assertion that fails in the gtest enabled 
libjvm.so when a certain combination of flags is used. I would think that 
libjvm.so with and without gtest should be built as similar as possible to make 
sure the test results are likely to be representative of the real libjvm.so. 
This test assertion is either relevant or it's not. The discussion above seems 
to indicate that what it's looking at is not really relevant to the real 
libjvm.so, because debuginfo structures are different. If that is the case, 
then removing the assertion completely, or making it conditional on when it is 
deemed relevant seems like the right solution. If on the other hand, it _is_ 
relevant, then this combination of flags is broken and we should disable it 
globally, or at least for libjvm.so. To me it seems like a bad idea to only 
change the flags for the gtest enabled libjvm.so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/30516#issuecomment-4236844106

Reply via email to