RTEMS | cpukit/score/cpu/mips: Add thread-local storage (!1401)

[Sebastian Huber (@sebhub)]

Sebastian Huber commented on a discussion on bsps/mips/shared/irq/vectorexceptions.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1401#note_158712

 >  {
 > -  (void) frame;
 > -
 >    uint32_t   cause;
 >    uint32_t   exc;
 >  
 >    mips_get_cause( cause );
 >    exc = (cause >> 2) & 0x1f;
 >  
 > +  if ( exc == MIPS_EXCEPTION_RI && mips_emulate_rdhwr_ulr( frame ) ) {
 > +    return;
 > +  }
 > +
 >    mips_exception_frame = frame;
 >    bsp_interrupt_handler_dispatch( exc );
 >    mips_exception_frame = NULL;

I filed three issues for this:

- #5752 for the `mips_exception_frame` global
- #5753 for the thread pointer and `rdhwr`
- #5754 for `_CPU_Exception_resume()` across all ports

### #5752, the global

Agreed, and it is older than this merge request. It came in with 7ec23f42d61.
The exception vectors are dispatched through the interrupt manager because
`mips_gdb_stub_install()` installs a handler on 18 of them, so the frame had
to reach `bsp_interrupt_handler_default()` somehow.

The fix is to give the MIPS port its own exception handler registration in the
shape of `ppc_exc_set_handler()`, where a handler takes a
`CPU_Exception_frame *`. The GDB stub moves to it, and the default handler
calls `rtems_fatal()` with `RTEMS_FATAL_SOURCE_EXCEPTION` and the frame, like
`C_exception_handler()` does on PowerPC. That changes the existing exception
API of the MIPS port, which is why it is a separate issue.

### #5753, the TLS model

I measured this before answering. In an RTEMS configuration the compiler emits
`rdhwr` whatever the TLS model:

```c
extern __thread int y;
int get2(void) { return y; }
```

```
$ mips-rtems7-gcc -O2 -S -march=r3900 -ftls-model=global-dynamic tls.c
get2:
      .set    push
      .set    mips32r2
      rdhwr   $3,$29
      .set    pop
      lui     $2,%tprel_hi(y)
      addu    $2,$2,$3
      jr      $31
```

All five values of -ftls-model give that. Note the .set mips32r2 around the
rdhwr under -march=r3900: the backend emits an instruction the selected
processor cannot execute.

__tls_get_addr() does appear, but only here:

```
$ mips-rtems7-gcc -O2 -S -march=r3900 -fpic -mabicalls -mshared \
      -ftls-model=global-dynamic tls.c
      lw      $25,%call16(__tls_get_addr)($28)
      addiu   $4,$28,%tlsgd(y)
```

-mabicalls is disabled by default for mips-rtems7, and enabling it moves
the BSPs to the GOT based PIC ABI. On top of that the linker relaxes a general
dynamic sequence to local exec in a static link, which puts rdhwr back.

So a compiler change is needed either way, and the smaller one is the one ARM
already has. -mtp=soft makes GCC emit a call of __aeabi_read_tp(), and we
supply that function in cpukit/score/cpu/arm/__aeabi_read_tp.c. #5753 asks
for the same option in the MIPS backend, the matching helper under
cpukit/score/cpu/mips/, and the flag in ABI_FLAGS so application objects
carry it too. mips_emulate_rdhwr_ulr() and the reserved instruction case in
mips_vector_exceptions() then go away.

Until such a compiler exists, the emulation is what makes thread-local storage
work on the R3900, so I would like to keep it here and remove it in #5753.

#5754, exception extensions

Your first comment pointed at these. _CPU_Exception_resume() exists in three
ports, with two signatures and two headers, and RTEMS_EXCEPTION_EXTENSIONS is
enabled for aarch64 and microblaze only, although arm builds its
implementation with the option off. #5754 proposes one declaration in
cpuimpl.h, mandatory for every port, with validation tests driven from the
ISA and ABI reference documents.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1401#note_158712
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-caq4ebv0sc2m64uwhfqlpt9ll-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260904/386746e0/attachment-0001.htm>