[PATCH v3 18/19] test/py: android: extend abootimg test

[Safae Ouajih]

On 27/02/2023 15:18, Tom Rini wrote:
> On Mon, Feb 27, 2023 at 03:15:31PM +0100, Safae Ouajih wrote:
>> On 07/02/2023 20:02, Tom Rini wrote:
>>> On Mon, Feb 06, 2023 at 12:50:20AM +0100, Safae Ouajih wrote:
>>>
>>>> test_abootimg is extended to include the testing of boot images
>>>> version 4. For this, boot.img and vendor_boot.img have been
>>>> generated using mkbootimg tool with setting the header
>>>> version to 4.
>>>>
>>>> This tests:
>>>> - Getting the header version using abootimg
>>>> - Extracting the load address of the dtb
>>>> - Extracting the dtb start address in RAM
>>>>
>>>> Running test:
>>>> $ ./test/py/test.py --bd sandbox --build -k test_abootimg
>>>>
>>>> Signed-off-by: Safae Ouajih <souajih at baylibre.com>
>>>> Reviewed-by: Simon Glass <sjg at chromium.org>
>>>> ---
>>>>    test/py/tests/test_android/test_abootimg.py | 136 ++++++++++++++++++--
>>>>    1 file changed, 123 insertions(+), 13 deletions(-)
>>> Alright, so I don't know where the failure starts, exactly. And to make
>>> testing this easier, there's currently the
>>> trini/u-boot-gitlab-ci-runner:jammy-20230126-07Feb2023 container you can
>>> use to replicate my problem. The problem is that while this test passes
>>> in CI, with GCC, with Clang it fails, consistently:
>>> https://source.denx.de/u-boot/u-boot/-/jobs/572239#L284
>>> and I'm not quite sure why. I hope that building sandbox with clang and
>>> also just trying these features out interactively will fail too, and so
>>> debugging this will be less of a problem.
>>>
>> Hello Tom,
>>
>> I have investigated this issue, clang has a strange behavior in:
>>
>> * abootimg_get_dtb_load_addr() : cmd/abootimg.c
>> * android_image_get_dtb_by_index() : boot/image-android.c
>>
>> That is probably linked to some sort of optimization clang does.
>>
>> However, The fail is not reproducible using clang-15 and clang-16 and also
>> not reproducible when turning off clang optimizations.
>>
>> I suggest using clang-15 to run the test or I can remove all optimizations
>>
>> on the related functions if clang-14 is used.
> Thanks for investigating.  I see that 15 is now considered stable, so
> I'll update the next branch for that, then re-take this series.
>

Hello Tom,

Thank you.

I am a bit confused, do you mean that you will apply this series after 
clang-15 update?

Best regards,

Safae