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

Reply via email to