public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* Re: [PATCH] PPC64 _dl_lookup_symbol_internal clobbers fpr2
@ 2003-08-26 21:38 Steven Munroe
  2003-08-27  4:36 ` Ulrich Drepper
  0 siblings, 1 reply; 4+ messages in thread
From: Steven Munroe @ 2003-08-26 21:38 UTC (permalink / raw)
  To: libc-hacker

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

Jakub Jelinek writes:

> Why dl-reloc.c and rtld.c?

dl-runtime.os, dl-lookup.os, and dl-misc.os seem to be the minimum set to clean
up the dynamic relocation path so dropped dl-reloc and rtld from the
-msoft-float list.

> Maybe CFLAGS-rtld-strlen.os := -msoft-float etc.

strlen, memcpy, and memset are clean (rewritten in asm) but mempcpy, memmove,
memchr, and strnlen are not. So I added rtld-mempcpy etc to the list. This is
not required to fix this fpr clobber, but these functions should not be using
fprs anyway.

2003-08-26  Steven Munroe  <sjmunroe@us.ibm.com>

	* sysdeps/powerpc/powerpc64/elf/Makefile: New file.

-- 
Steven Munroe
sjmunroe@us.ibm.com
Linux on PowerPC-64 Development
GLIBC for PowerPC-64 Development

[-- Attachment #2: ppc64-ld-soft-float.patch --]
[-- Type: text/plain, Size: 689 bytes --]

diff -urN libc23-cvstip-20030825/sysdeps/powerpc/powerpc64/elf/Makefile libc23/sysdeps/powerpc/powerpc64/elf/Makefile
--- libc23-cvstip-20030825/sysdeps/powerpc/powerpc64/elf/Makefile	Wed Dec 31 18:00:00 1969
+++ libc23/sysdeps/powerpc/powerpc64/elf/Makefile	Tue Aug 26 15:26:03 2003
@@ -0,0 +1,11 @@
+# powerpc64/ELF specific definitions.
+
+# Need to prevent gcc from using fprs in code used during dynamic linking.
+
+CFLAGS-dl-runtime.os := -msoft-float
+CFLAGS-dl-lookup.os := -msoft-float
+CFLAGS-dl-misc.os := -msoft-float
+CFLAGS-rtld-mempcpy.os := -msoft-float
+CFLAGS-rtld-memmove.os := -msoft-float
+CFLAGS-rtld-memchr.os := -msoft-float
+CFLAGS-rtld-strnlen.os := -msoft-float

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] PPC64 _dl_lookup_symbol_internal clobbers fpr2
  2003-08-26 21:38 [PATCH] PPC64 _dl_lookup_symbol_internal clobbers fpr2 Steven Munroe
@ 2003-08-27  4:36 ` Ulrich Drepper
  0 siblings, 0 replies; 4+ messages in thread
From: Ulrich Drepper @ 2003-08-27  4:36 UTC (permalink / raw)
  To: sjmunroe; +Cc: libc-hacker

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steven Munroe wrote:

> 2003-08-26  Steven Munroe  <sjmunroe@us.ibm.com>
> 
> 	* sysdeps/powerpc/powerpc64/elf/Makefile: New file.

I applied the patch.  Thanks,

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/TDUu2ijCOnn/RHQRAkcmAJ9ruIJ3sUZ2nwhHYk3/ztzTlH96mwCgtJIG
H9ulNgkaTuSrka/Pupr//a0=
=70lu
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] PPC64 _dl_lookup_symbol_internal clobbers fpr2
  2003-08-26 16:32 Steven Munroe
@ 2003-08-26 16:43 ` Jakub Jelinek
  0 siblings, 0 replies; 4+ messages in thread
From: Jakub Jelinek @ 2003-08-26 16:43 UTC (permalink / raw)
  To: sjmunroe; +Cc: libc-hacker

On Tue, Aug 26, 2003 at 10:01:47AM -0500, Steven Munroe wrote:
> The resolve path of ld.so does not actually use fp operations but gcc has a
> nasty habit of using volitile fprs to move/copy structs inline. So a function
> that is dynamically linked and has float/double parms may find its parametes
> globbled by plt-fixup on the first call. This is the case with
> _dl_lookup_symbol_internal in the current current RHEL 3 beta. 
> 
> There are three possible solutions:
> 
> 1) change the dl-machine.h TRAMPOLINE to save/restore fprs 2-13. This would
> slow down all dynamic resolves.
> 2) change gcc to not use fprs for struct copies. This would have negative
> impact on SPEC benchmarks
> 3) apply -msoft-float to the compile of the appropriate loader modules so that
> the dynamic resolve path does not use fprs.
> 
> For now I would like to go with option 3:
> 
> 2003-08-26  Steven Munroe  <sjmunroe@us.ibm.com>
> 
> 	* sysdeps/powerpc/powerpc64/elf/Makefile: New file.

Why dl-reloc.c and rtld.c?
I don't see how code in them could be called from fixup() or
profile_fixup().
On the other side, profile_fixup() can call _dl_mcount from
dl-profile.c and both can call strlen, strcmp, stpcpy and mempcpy.
The former 3 seem to be either written in assembly or don't use fpr2-13,
mempcpy apparently uses fpr2-13, but it seems to be called only when
error will be signalled, so it will never return and thus doesn't matter.
Maybe CFLAGS-rtld-strlen.os := -msoft-float etc. would be useful too,
if that works.

Also, why don't you just add CFLAGS-dl-runtime.os etc instead of
CFLAGS-dl-runtime.c? Lazy binding matters in the dynamic linker only.

> diff -urN libc23-cvstip-20030825/sysdeps/powerpc/powerpc64/elf/Makefile libc23/sysdeps/powerpc/powerpc64/elf/Makefile
> --- libc23-cvstip-20030825/sysdeps/powerpc/powerpc64/elf/Makefile	Wed Dec 31 18:00:00 1969
> +++ libc23/sysdeps/powerpc/powerpc64/elf/Makefile	Mon Aug 25 14:57:54 2003
> @@ -0,0 +1,9 @@
> +# powerpc64/ELF specific definitions.
> +
> +# Need to prevent gcc from using fprs durring dynamic linking.
> +
> +CFLAGS-dl-runtime.c := -msoft-float
> +CFLAGS-dl-lookup.c := -msoft-float
> +CFLAGS-dl-reloc.c := -msoft-float
> +CFLAGS-dl-misc.c := -msoft-float
> +CFLAGS-rtld.c := -msoft-float


	Jakub

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH] PPC64 _dl_lookup_symbol_internal clobbers fpr2
@ 2003-08-26 16:32 Steven Munroe
  2003-08-26 16:43 ` Jakub Jelinek
  0 siblings, 1 reply; 4+ messages in thread
From: Steven Munroe @ 2003-08-26 16:32 UTC (permalink / raw)
  To: libc-hacker

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

The resolve path of ld.so does not actually use fp operations but gcc has a
nasty habit of using volitile fprs to move/copy structs inline. So a function
that is dynamically linked and has float/double parms may find its parametes
globbled by plt-fixup on the first call. This is the case with
_dl_lookup_symbol_internal in the current current RHEL 3 beta. 

There are three possible solutions:

1) change the dl-machine.h TRAMPOLINE to save/restore fprs 2-13. This would
slow down all dynamic resolves.
2) change gcc to not use fprs for struct copies. This would have negative
impact on SPEC benchmarks
3) apply -msoft-float to the compile of the appropriate loader modules so that
the dynamic resolve path does not use fprs.

For now I would like to go with option 3:

2003-08-26  Steven Munroe  <sjmunroe@us.ibm.com>

	* sysdeps/powerpc/powerpc64/elf/Makefile: New file.

-- 
Steven Munroe
sjmunroe@us.ibm.com
Linux on PowerPC-64 Development
GLIBC for PowerPC-64 Development

[-- Attachment #2: ppc64-ld-soft-float.patch --]
[-- Type: text/plain, Size: 580 bytes --]

diff -urN libc23-cvstip-20030825/sysdeps/powerpc/powerpc64/elf/Makefile libc23/sysdeps/powerpc/powerpc64/elf/Makefile
--- libc23-cvstip-20030825/sysdeps/powerpc/powerpc64/elf/Makefile	Wed Dec 31 18:00:00 1969
+++ libc23/sysdeps/powerpc/powerpc64/elf/Makefile	Mon Aug 25 14:57:54 2003
@@ -0,0 +1,9 @@
+# powerpc64/ELF specific definitions.
+
+# Need to prevent gcc from using fprs durring dynamic linking.
+
+CFLAGS-dl-runtime.c := -msoft-float
+CFLAGS-dl-lookup.c := -msoft-float
+CFLAGS-dl-reloc.c := -msoft-float
+CFLAGS-dl-misc.c := -msoft-float
+CFLAGS-rtld.c := -msoft-float

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-08-27  4:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-26 21:38 [PATCH] PPC64 _dl_lookup_symbol_internal clobbers fpr2 Steven Munroe
2003-08-27  4:36 ` Ulrich Drepper
  -- strict thread matches above, loose matches on Subject: below --
2003-08-26 16:32 Steven Munroe
2003-08-26 16:43 ` Jakub Jelinek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).