On 7/8/2026 9:36 AM, Pierrick Bouvier wrote:
> On 7/7/2026 11:11 PM, Max Filippov wrote:
>> On Tue, Jul 7, 2026 at 11:10 AM Pierrick Bouvier
>> <[email protected]> wrote:
>>> On 7/7/2026 9:30 AM, Pierrick Bouvier wrote:
>>>> On 7/7/2026 6:45 AM, Max Filippov wrote:
>>>>> On Mon, Jul 6, 2026 at 3:43 PM Pierrick Bouvier
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> Needed, else we get this error:
>>>>>> dangerous relocation: l32r: misaligned literal target: .text
>>>>>
>>>>> This flag wasn't needed before because crt.S hasn't been built
>>>>> with text-section-literals, why is it needed now?
>>>>>
>>>> Previously, .S and .c were compiled in different steps, with different
>>>> options. Now, with meson, we have to provide a single compiler command
>>>> for all the files (no intermediate steps), which is a *hard* requirement
>>>> to save user from dealing with compilation details in arch files.
>>
>> This sounds a bit restrictive for the tests, no?
>>
> 
> It may appear restrictive, but it has not been a problem for all the
> existing tests we have. In practice, only xtensa has such a structure,
> with this distinction between .S and .c that use/don't use text section
> literals. In such a case, I prefer to unify things instead of twist the
> workflow until it works.
> 
> The alternative would be to give arch files full control of how they
> build all their binaries, which is much more verbose and error prone
> than the current approach. (Note: I tried that first before having the
> current design where tests are just declared).
> Also, it pushes all compiler details (is flag supported, is it available
> or through docker, how to build container?, ...) back to arch files.
> 
> Also, because meson can only have one cc and cross cc at a time, we
> would still need custom targets for everything, which is really not
> something anyone wants to write themselves, trust me.
> 
>>>> One consequence is that .c + .S combination gets
>>>> -mtext-section-literals, which triggers this. Easily fixed by adding the
>>>> .align section.
>>
>> Ok, not having literals in the text section isn't essential for the existing
>> xtensa tests. But not being able to do that deliberately feels a bit strange.
>>
> 
> I'm sorry xtensa uses a corner case, but fortunately, this simple align
> makes things work as expected.
> 
>>>> I can add this in commit description, if you're ok with this
>>>> explanation, and accept the patch.
>>
>> Sure. Feel free to add
>> Reviewed-by: Max Filippov <[email protected]>
>>
> 
> Thanks!
> 
>>>>>> Signed-off-by: Pierrick Bouvier <[email protected]>
>>>>>> ---
>>>>>>  tests/tcg/xtensa/crt.S | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/tests/tcg/xtensa/crt.S b/tests/tcg/xtensa/crt.S
>>>>>> index 909872cd385..de8fd8c1cd7 100644
>>>>>> --- a/tests/tcg/xtensa/crt.S
>>>>>> +++ b/tests/tcg/xtensa/crt.S
>>>>>> @@ -6,6 +6,7 @@
>>>>>>      jx      a2
>>>>>>
>>>>>>  .text
>>>>>> +.align 4
>>>>>>  .global _start
>>>>>>  _start:
>>>>>>  #if XCHAL_HAVE_WINDOWED
>>>>>> --
>>>>>> 2.47.3
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> While at it, any chance you could give some hints about how to compile
>>> for xtensaeb? I didn't find any compiler flag, and out of modifying
>>> target/xtensa/core-dc232b/core-isa.h to set XCHAL_HAVE_BE to 1, I'm stuck.
>>>
>>> I doubt it's the right way to do considering that it was not needed before.
>>
>> You can download a compiler for the core `test_kc705_be` from
>>   https://github.com/foss-xtensa/toolchain/releases/tag/2020.07
>> and then either run qemu `configure` with the option
>>   --cross-cc-xtensaeb=xtensa-test_kc705_be-elf-gcc
>> or run tests with
>>   make test-tcg CORE=test_kc705_be CC=xtensa-test_kc705_be-elf-gcc
>>
>> The `CORE` variable chooses both the argument for the qemu `-cpu` option
>> and include directory used when building tests. The `CC` chooses the
>> compiler and linker.
>>
>> I usually run configure with some compilers for little- and big-endian xtensa
>> and then run tests switching the core and compiler.
> 
> Sounds good. I'll add it to our debian-xtensa-cross, and uses it
> directly for xtensaeb.
> In case you want to run this with other cores, feel free to answer with
> a list with their names and toolchains, and I'll be happy to add all
> needed suites, so there is no need to set any CC and CORE, but directly
> offer check-tcg-xtensa-X-softmmu suites. The good side is that everyone,
> including our CI and you, will be able to run the *exact* same setup.
> 
> Cheers,
> Pierrick

If you have a chance to take a look, I observed that test_timer.S is
flaky on xtensaeb with kc705_be. It fails with a probably of 25% on my
machine.

Regards,
Pierrick

Reply via email to