1
0
mirror of https://sourceware.org/git/glibc.git synced 2025-09-15 12:01:15 +03:00
Files
glibc/elf
H.J. Lu c1bec0b52d i386: Update ___tls_get_addr to preserve vector registers
Compiler generates the following instruction sequence for dynamic TLS
access:

	leal	tls_var@tlsgd(,%ebx,1), %eax
	call	___tls_get_addr@PLT

CALL instruction is transparent to compiler which assumes all registers,
except for EFLAGS, AX, CX, and DX, are unchanged after CALL.  But
___tls_get_addr is a normal function which doesn't preserve any vector
registers.

1. Rename the generic __tls_get_addr function to ___tls_get_addr_internal.
2. Change ___tls_get_addr to a wrapper function with implementations for
FNSAVE, FXSAVE, XSAVE and XSAVEC to save and restore all vector registers.
3. dl-tlsdesc-dynamic.h has:

_dl_tlsdesc_dynamic:
	/* Like all TLS resolvers, preserve call-clobbered registers.
	   We need two scratch regs anyway.  */
	subl	$32, %esp
	cfi_adjust_cfa_offset (32)

It is wrong to use

	movl	%ebx, -28(%esp)
	movl	%esp, %ebx
	cfi_def_cfa_register(%ebx)
	...
	mov	%ebx, %esp
	cfi_def_cfa_register(%esp)
	movl	-28(%esp), %ebx

to preserve EBX on stack.  Fix it with:

	movl	%ebx, 28(%esp)
	movl	%esp, %ebx
	cfi_def_cfa_register(%ebx)
	...
	mov	%ebx, %esp
	cfi_def_cfa_register(%esp)
	movl	28(%esp), %ebx

4. Update _dl_tlsdesc_dynamic to call ___tls_get_addr_internal directly.
5. Add have-test-mtls-traditional to compile tst-tls23-mod.c with
traditional TLS variant to verify the fix.
6. Define DL_RUNTIME_RESOLVE_REALIGN_STACK in sysdeps/x86/sysdep.h.

This fixes BZ #32996.

Co-Authored-By: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
(cherry picked from commit 848f0e46f0)
2025-08-18 12:44:54 -07:00
..
2009-06-03 16:21:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2013-06-05 20:44:03 +00:00
2009-10-30 00:48:54 -07:00
2009-06-03 16:21:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-06-22 15:07:40 -07:00
2009-10-30 00:48:54 -07:00
2012-01-07 23:57:22 -05:00
2006-03-01 06:18:49 +00:00
2023-05-29 23:00:12 +00:00
2023-05-29 23:00:12 +00:00
2023-05-29 23:00:12 +00:00
2023-05-29 23:00:12 +00:00
2020-05-18 15:39:34 +02:00
2013-06-05 20:44:03 +00:00
2005-07-07 23:00:02 +00:00
2005-07-07 23:00:02 +00:00
2005-07-07 23:00:02 +00:00
2005-07-07 23:00:02 +00:00
2005-07-07 23:00:02 +00:00
2022-04-26 10:16:11 -07:00
2022-04-26 10:16:11 -07:00
2013-10-18 19:45:36 +05:30
2024-12-05 09:53:47 +00:00
2024-12-05 09:53:47 +00:00
2024-12-05 09:53:47 +00:00
2024-12-05 09:53:47 +00:00
2024-12-05 09:53:47 +00:00
2024-12-05 09:53:47 +00:00
2011-09-10 14:34:15 -04:00
2011-09-10 14:34:15 -04:00
2011-09-10 14:34:15 -04:00
2005-03-20 22:25:59 +00:00
2006-03-01 06:18:49 +00:00
2005-03-03 08:28:23 +00:00
2005-03-03 08:28:23 +00:00
2005-03-03 08:28:23 +00:00
2005-03-03 08:28:23 +00:00
2005-03-18 10:54:53 +00:00
2005-03-18 10:54:53 +00:00
2005-04-27 01:39:11 +00:00
2011-08-24 09:32:13 +02:00
2006-03-01 06:18:49 +00:00