This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.27: less than two weeks till release
On 22/01/2018 09:11, Szabolcs Nagy wrote:
> On 21/01/18 22:01, Romain Naour wrote:
>> 2) aarch64 (gcc):
>>
>> libsanitizer/sanitizer_common/sanitizer_linux.cc:1265:35: error: ‘struct
>> mcontext_t’ has no member named ‘__reserved’; did you mean ‘__glibc_reserved1’?
>> u8 *aux = ucontext->uc_mcontext.__reserved;
>> ^~~~~~~~~~
>> __glibc_reserved1
>>
>> Build issue introduced by:
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=4fa9b3bfe6759c82beb4b043a54a3598ca467289
>>
>> * sysdeps/unix/sysv/linux/aarch64/ucontext_i.sym (oEXTENSION): Use
>> __glibc_reserved1 instead of __reserved.
>>
>> Even with the current gcc master, we can't build an aarch64 toolchain with the
>> upcoming glibc 2.27 since ucontext->uc_mcontext.__reserved is still used.
>
> indeed that commit seems faulty:
>
> on aarch64 a list of cpu states (e.g fp registers) can only be
> accessed via parsing the __reserved member (there are no macros
> or functions defined for this, the user has to manually cast).
>
> and __reserved does not violate the namespace rules, so i don't
> think we need macro hackery to use different name based on
> _GNU_SOURCE.
>
> so i think this api should not be changed, i'll revert this part
> of that patch.
>
> thanks for catching it.
>
I noted it sometime ago and added a fix on my ILP32 sanitizer support on
compiler-rt [1] (still in review):
+// glibc starting at 2.26 does not typedef sigcontext to mcontext_t,
+// but rather defines its own with internal reserved member with
+// different naming. The mcontext_t definition below is based on
+// Linux UAPI for sicontex_t.
+struct __sanitizer_mcontext_t {
+ unsigned long long int fault_address;
+ unsigned long long int regs[31];
+ unsigned long long int pc;
+ unsigned long long int sp;
+ unsigned long long int pstate;
+ unsigned char reserved[4096] __attribute__ ((__aligned__ (16))); // NOLINT
+};
+
static bool Aarch64GetESR(ucontext_t *ucontext, u64 *esr) {
static const u32 kEsrMagic = 0x45535201;
- u8 *aux = ucontext->uc_mcontext.__reserved;
+ __sanitizer_mcontext_t *mctx = reinterpret_cast<__sanitizer_mcontext_t *>
+ (&ucontext->uc_mcontext);
+ u8 *aux = mctx->reserved;
while (true) {
_aarch64_ctx *ctx = (_aarch64_ctx *)aux;
if (ctx->size == 0) break;
I am not sure if we should fix on glibc or sanitizer side.
[1] https://reviews.llvm.org/D40134