This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Save fp registers on x64 function resolution.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andreas Jaeger <aj at suse dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sun, 28 Jul 2013 19:23:16 -0400
- Subject: Re: [PATCH] Save fp registers on x64 function resolution.
- References: <20130726091501 dot GA7231 at domone dot kolej dot mff dot cuni dot cz> <51F297A2 dot 8010909 at suse dot com> <20130727054910 dot GA6299 at domone dot kolej dot mff dot cuni dot cz> <51F57C01 dot 9060800 at suse dot com>
On Sun, Jul 28, 2013 at 10:16:01PM +0200, Andreas Jaeger wrote:
> On 07/27/2013 07:49 AM, OndÅej BÃlka wrote:
> > [...
> > OK, also
> >>> > > movq %rax, %r11 # Save return value
> > seems retundant as you do not pass arguments via %rax.
> >>> > >
>
> But you pass the number of used SSE registers with variadic arguments
> using %rax,
This convention actually makes for _really_ nasty bugs. For example,
glib was caught calling open() through a function pointer to the wrong
(non-variadic) type. This resulted in receiving an unpredictable value
in al, and because of the way gcc's variadic prologue code works, it
would sometimes jump to an incorrect address before the start of open.
I would say the prologue code gcc generates should be fixed to clamp
or truncate the value so that this dangerous (and possibly
exploitable) situation can't happen; all it should take is an extra
bitwise-and operation. The situation could also be improved if gcc
just omitted the floating point part of the prologue when the function
never calls va_arg with a floating point type and never passes the
va_list to other functions.
BTW, the bug was caught using glib against musl; I suspect glibc is
implementing open with a non-variadic definition where all the
arguments are explicit and thereby avoided the issue but I haven't
looked.
Rich