This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/21265] _dl_runtime_resolve isn't compatible with Intel C++ __regcall calling convention
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 20 Mar 2017 14:07:44 +0000
- Subject: [Bug dynamic-link/21265] _dl_runtime_resolve isn't compatible with Intel C++ __regcall calling convention
- Auto-submitted: auto-generated
- References: <bug-21265-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21265
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
--- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #6)
> Note that there is a parallel mailing list thread reviewing this ABI change
> proposal:
>
> https://sourceware.org/ml/libc-alpha/2017-03/msg00343.html
>
> I think we still need some ABI documentation even if more registers are
> preserved because arbitrary calling conventions still will not work. Using
> noplt calls as a workaround in the Intel compiler seems a reasonable fix (no
> ABI changes required, but this still needs documentation in the psABI
> supplement IMHO).
Agreed.
(In reply to Florian Weimer from comment #5)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Andreas Schwab from comment #2)
> > > Like the regparm attribute on 32-bit x86 it can only be safely used by
> > > internal function calls.
> >
> > i386 _dl_runtime_resolve preserves EAX, ECX and EDX for regparm:
>
> I think this is mainly for internal glibc use (see the internal_function
> macro). I don't think you should read into this that glibc supports a
> different ABI than what's specified in the psABI supplement.
>
> What makes this bug different from bug 21236?
My high level opinion:
(a) "Optimize for the local special case": Use of regparm and __regcall is
restricted to internal functions. The goal is to optimize internal calls as
much as possible with the additional registers. The example of i386 support and
internal_function macro is a good example of optimizing internal function
calls.
(b) "Optimize for the global average case": Use of regparm and __regcall should
not be extended to support interposable global symbols. We should optimize for
the general case which doesn't use regparm/__regcall and which supports
developers interposing code using the standard x86_64 ABI.
If you want (a) to cover more of your program then you need to look at -fno-plt
(as Florian Weimer suggests) and LTO to make more of your program local and
enable the optimizations that allows.
--
You are receiving this mail because:
You are on the CC list for the bug.