Segmentation fault in the segmentation fault handler (simulation mode), possibly caused by GET_DTV macro

Nobody has claimed this yet.

Hi, we are having an issue in using Intel SGX SDK, triggered by "expected" segmentation faults and caused by the SDK handler `sig_handler_sim`.

Our framework is a Java/Kotlin/JVM running on top of Intel SGX and we have genuine and expected thread segmentation faults caused by the JVM due to allocation of big amount of memory in a multi-threading context.
These segmentation faults are handled by the SDK handler `sig_handler_sim`, but they are also triggering unexpected "recursive" segmentation faults.

These "recursive" segmentation faults are happening only when we load the enclave, i.e. when we have the replacement of the segmentation fault handler.
When we reach this line
https://github.com/intel/linux-sgx/blob/fdb3b8b4695b40afab5a3212cf69eb8d8db7cfb1/sdk/simulation/uinst/u_instructions.cpp#L130
the value of `thread_data` it not `NULL` but a garbage value `0x3`.

We believe that the issue is related to the handling of the DTV (`GET_DTV` macro) in your code, specifically it appears that the `counter` is not taken in consideration when retrieving the `dtv_t* __dtv` pointer, i.e. the code is missing to skip the offset of the first element of the DTV which is the counter.
We get a successful run of our code when we apply the patch below(the patch is for 64 bits, we haven't investigated the 32 bits case).
The same issue seems to be present in the `READ_TD_DATA` macro as well.

Can you please have a look and suggest further?
The issue started appearing in 2.15 (where the related code, for example the call `arch_prctl`, has been replaced) and it still seems to be present in 2.16 and 2.17.
This is happening on a Linux machine, Ubuntu 20.04, Kernel 5.13.0-41-generic and on other Ubuntu 20.04 cloud machines as well.

```
diff --git a/sdk/simulation/assembly/linux/gnu_tls.h b/sdk/simulation/assembly/linux/gnu_tls.h
index 974ddf45..6837c9f7 100644
--- a/sdk/simulation/assembly/linux/gnu_tls.h
+++ b/sdk/simulation/assembly/linux/gnu_tls.h
@@ -64,7 +64,7 @@ typedef struct
({ dtv_t* __dtv; \
__asm__ ("mov %%fs:%c1, %0" : "=r"(__dtv) \
: "i" (offsetof (tcbhead_t, dtv))); \
- __dtv; })
+ &__dtv[1]; })

#define GET_FS_GS_0() \
({ uintptr_t __orig; \
diff --git a/sdk/trts/linux/trts_pic.h b/sdk/trts/linux/trts_pic.h
index 1f769bed..b884f13f 100644
--- a/sdk/trts/linux/trts_pic.h
+++ b/sdk/trts/linux/trts_pic.h
@@ -81,6 +81,7 @@

#define dtv SE_WORDSIZE
#define tls 0
+#define tls64 16
.macro READ_TD_DATA offset
#ifdef SE_SIM
/* TLS support in simulation mode
@@ -92,10 +93,11 @@

#if defined(LINUX32)
mov %gs:dtv, %xax
+ mov tls(%xax), %xax
#elif defined(LINUX64)
mov %fs:dtv, %xax
+ mov tls64(%xax), %xax
#endif
- mov tls(%xax), %xax
mov \offset(%xax), %xax

#else /* SE_SIM */
```

Start with sdk/simulation/uinst/u_instructions.cpp around line 130, then inspect GET_DTV in sdk/simulation/assembly/linux/gnu_tls.h and READ_TD_DATA in sdk/trts/linux/trts_pic.h. Reproduce the simulation-mode recursive fault on Linux and compare 32-bit and 64-bit TLS handling; done means expected JVM segmentation faults no longer trigger recursive faults without breaking TLS access.

Written by the indexing model from the issue text.