public inbox for
help / color / mirror / Atom feed
From: Kevin Ryde <>
Subject: c/10355: i386 regparm doco note on shlib use
Date: Tue, 08 Apr 2003 22:26:00 -0000	[thread overview]
Message-ID: <> (raw)

>Number:         10355
>Category:       c
>Synopsis:       i386 regparm doco note on shlib use
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 08 22:26:00 UTC 2003
>Release:        3.2.3 20030316 (Debian prerelease) (Debian testing/unstable)
System: Linux blah 2.2.15 #1 Tue Apr 25 17:13:48 EST 2000 i586 unknown unknown GNU/Linux
Architecture: i586
	<machine, os, target, libraries (multiple lines)>
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux

The i386 regparm attribute is not good for functions in shared
libraries on some systems.  It'd be nice to have a warning about that
in the manual.

On Solaris 8, the loader's lazy binding resolver code clobbers eax,
ecx and edx, in accordance with the standard calling conventions,
meaning bad values reach the first call to a regparm function.

I'd like to propose the few words below.  GLIBC and FreeBSD are the
only loaders I've had a close look at.  Very possibly other BSD
flavours are safe too.

Content-Disposition: attachment; filename=extend.texi.regparm-plt.diff

--- extend.texi.~1.127.~	2003-03-27 09:10:43.000000000 +1000
+++ extend.texi	2003-04-09 08:17:25.000000000 +1000
@@ -2360,6 +2360,7 @@
 @code{local-dynamic}, @code{initial-exec} or @code{local-exec}.
 @item regparm (@var{number})
+@cindex @code{regparm} attribute
 @cindex functions that are passed arguments in registers on the 386
 On the Intel 386, the @code{regparm} attribute causes the compiler to
 pass up to @var{number} integer arguments in registers EAX,
@@ -2367,6 +2368,14 @@
 variable number of arguments will continue to be passed all of their
 arguments on the stack.
+Beware that on some ELF systems this attribute is unsuitable for
+global functions in shared libraries.  Lazy binding will send the
+first call via resolving code in the loader, which might assume EAX,
+EDX and ECX can be clobbered, as per the standard calling conventions.
+Solaris 8 is affected by this.  GNU systems with GLIBC 2.1 or higher,
+and FreeBSD, are believed to be safe though since the loaders there
+save all registers.
 @item stdcall
 @cindex functions that pop the argument stack on the 386
 On the Intel 386, the @code{stdcall} attribute causes the compiler to


             reply	other threads:[~2003-04-08 22:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-08 22:26 Kevin Ryde [this message]
2003-05-20 22:28 bangerth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).