Re: [PING][PATCH, GCC/ARM] Only test tls-disable-literal-pool.c if target supports native TLS

[Prakhar Bahuguna <prakhar.bahuguna@arm.com>]

On 30/05/2017 14:11:22, Christophe Lyon wrote:
> On 30 May 2017 at 09:44, Prakhar Bahuguna <prakhar.bahuguna@arm.com> wrote:
> > On 29/05/2017 14:23:05, Christophe Lyon wrote:
> >> On 19 May 2017 at 14:29, Prakhar Bahuguna <prakhar.bahuguna@arm.com> wrote:
> >> > On 11/05/2017 14:54:37, Prakhar Bahuguna wrote:
> >> >> tls-disable-literal-pool.c should only be run if the toolchain and target
> >> >> support native thread-local storage rather than emulated TLS. This patch also
> >> >> improves the matching of the error message.
> >> >>
> >> >> testsuite/ChangeLog:
> >> >>
> >> >> 2017-05-11  Prakhar Bahuguna  <prakhar.bahuguna@arm.com>
> >> >>
> >> >>       * gcc.target/arm/tls-disable-literal-pool.c: Change
> >> >>       require-effective-target to tls_native.
> >> >>       Move dg-error to return statement line and change to dg-message.
> >> >>
> >> >> Testing done: Regression testing for ARMv7-M with a TLS-enabled toolchain and a
> >> >> TLS-disabled toolchain.
> >> >>
> >>
> >> Hi,
> >> Can you share more details on the configuration you used?
> >> In my testing, the only cortex-M config I have is arm-none-eabi
> >> --with-cpu=cortex-m3.
> >> Since arm-none-eabi means native-tls is disabled, this test is skipped.
> >> A constraint for me is that m3 was the only cortex-m cpu supported by qemu the
> >> last time I checked.
> >>
> >> Thanks,
> >>
> >> Christophe
> >>
> >
> > Hi Christophe,
> >
> > For a regular arm-none-eabi build, TLS is indeed disabled and the test should
> > be skipped. The diagnostic and test is meant to catch instances where the
> > toolchain has been built with native TLS enabled. This can be done either by
> > explicitly passing the --enable-tls configure flag for arm-none-eabi, or by
> 
> This didn't occur to me: what does --target arm-none-eabi --enable-tls actually
> means in terms of functionality? Do you use newlib +  a suitable kernel to
> provide thread support? Or are all the tls-related GCC tests compile-only,
> and we do not need a setup with proper thread support to actually test this?
> 

Hi Christophe, the test is compile-only. Threading isn't really a thing in the
context of bare-metal code on a microcontroller, but this diagnostic is there
to prevent the compiler from generating garbage assembly even if the user is
going out of their way to do something nonsensical. The test exists to validate
that the diagnostic triggers under such conditions.

> > using an arm-none-linux-gnueabi[hf] toolchain and testing against an M-profile
> > target.
> I guess you use a board for that? As I'm using qemu (user mode) for GCC testing,
> I'm not sure how I could test such a configuration given that qemu
> does not support
> any v7m processor to my knowledge.

As above, the execution target does not matter as there is no code to execute.
The compiler should simply error out if told to compile code with thread-local
variables and literal pools disabled.

-- 

Prakhar Bahuguna