[Bug libc/23296] Data race in setting function descriptor during lazy binding

[danglin at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23296

--- Comment #10 from John David Anglin <danglin at gcc dot gnu.org> ---
I looked at what 32-bit HPUX does.  It sets the LTP to zero initially.
It sets the function address to point to a "b,l,n" instruction before the
trampoline.

The trampoline looks like this:

0x7b04d170:     b,l,n 0x7b04d17c,r31
0x7b04d174:     b,l,n 0x7b04d17c,r31
0x7b04d178:     b,l,n 0x7b04d17c,r31
0x7b04d17c:     ldil -3ffdc000,r21
0x7b04d180:     ldo 160(r21),r21
0x7b04d184:     ldsid (sr0,r21),r1
0x7b04d188:     mtsp r1,sr0
0x7b04d18c:     addil -7b04d000,r31,%r1
0x7b04d190:     ldo -16c(r1),r1
0x7b04d194:     extrw,u r1,29,30,r1
0x7b04d198:     addil 0,r1,%r1
0x7b04d19c:     ldo 3(r1),r19
0x7b04d1a0:     ldil 7b04f000,r31
0x7b04d1a4:     ldo 360(r31),r31
0x7b04d1a8:     be 0(sr0,r21)
0x7b04d1ac:     ldo 0(r31),r21

With technique, all the information needed to find the relocation is encoded
in the function address.  It needs a bunch of "b,l,n" instructions and a larger
trampoline.

HPUX appears to bind indirect calls immediately.  I guess this is to work
around the fact that $$dyncall loads the LTP value before the function address.

The trampoline only seems to be used when a call goes via an import stub.

-- 
You are receiving this mail because:
You are on the CC list for the bug.