This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/21265] _dl_runtime_resolve isn't compatible with Intel C++ __regcall calling convention


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]