From: Zack Weinberg <zack@codesourcery.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Possible race condition with deferred binding on IPF
Date: Mon, 08 Mar 2004 18:08:09 +0000 [thread overview]
Message-ID: <87wu5v1aba.fsf@egil.codesourcery.com> (raw)
In-Reply-To: <BEC72735-6E38-11D8-9E11-003065589C02@cup.hp.com>
Cary Coutant <cary@cup.hp.com> writes:
>> Converting the ld8 to a ld8.acq is a simple matter of changing the
>> second line of this array to
>>
>> 0x00, 0x41, 0x3c, 0x70, 0x29, 0xc0, /* ld8.acq
>> r16=[r15],8 */
>
> Yes, this is the same bit pattern Steve Ellcey and I came up with.
Ok. I'll see about testing this and submitting a proper patch.
> This code does not need to be patched. The two words loaded here point
> to the dynamic loader's BOR routine. The dynamic loader must provide
> the proper values in the linkage table before the program can run;
> these values will not change, so the ordering isn't important. Adding
> an ld.acq here would unnecessarily slow the code down.
Ok, thanks for the clarification.
> I don't see anything wrong with you're reasoning, but changing this
> will have a binary compatibility impact, as the copy of gp to r14 is
> now part of the ABI, and will be present in inlined import stubs in
> existing .o files. I don't think gcc generates inlined import stubs at
> the moment, but I think Intel's compiler does.
>
> Too bad. It leaves me wondering why we didn't design it this way in
> the first place.
Understood. I can still squeeze PLT0 down to two bundles by moving
the r2=r14 move into PLT1a, but I suspect that it only fits because
I didn't put in all the necessary stop bits. Also it relies on being
able to express a relocation to PLT_RESERVE+8, which may not be
possible. And I'm not sure whether this actually executes any faster.
(The idea is, since the ordering doesn't matter, to fetch the branch
target address first, and then the move to b6 can fit into that bundle -
but only if I don't need a stop bit between the load and the move to b6.)
.PLT0:
addl r2 = @gprel(plt_reserve+8), r2 ;;
ld8 r17 = [r2], 8
mov b6 = r17
ld8 r1 = [r2], -16
ld8 r16 = [r2]
br b6 ;;
.PLT1:
addl r15 = @pltoff(name1), r1 ;;
ld8.acq r16 = [r15], 8
mov r14 = r1 ;;
ld8 r1 = [r15]
mov b6 = r16
br b6 ;;
.PLT1a:
mov r2 = r14
mov r15 = @iplt(name1)
br .PLT0 ;;
zw
next prev parent reply other threads:[~2004-03-08 18:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-05 0:05 Possible race condition with deferred binding on IPF Cary Coutant
2004-03-07 21:53 ` Zack Weinberg
2004-03-07 23:09 ` Zack Weinberg
2004-03-08 17:15 ` Cary Coutant
2004-03-08 18:08 ` Zack Weinberg [this message]
2004-03-09 20:49 ` Jim Wilson
2004-03-09 20:51 ` Zack Weinberg
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wu5v1aba.fsf@egil.codesourcery.com \
--to=zack@codesourcery.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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