This is the mail archive of the libc-alpha@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]

Re: [PATCH 0/3] aarch64: Update ld.so for vector abi


On 08/02/2018 10:29 AM, Szabolcs Nagy wrote:
> On 02/08/18 14:17, Carlos O'Donell wrote:
>> On 08/02/2018 06:44 AM, Szabolcs Nagy wrote:
>>> ok (ld audit is another reason to avoid plt for vector functions..)
>>
>> If you avoid the PLT with no way to add back a call through the PLT
>> this completely breaks developer tooling that uses the PLT, like
>> LD_AUDIT, latrace, and custom tooling. Be aware that there are large
>> customers in various industry verticals that use LD_AUDIT extensively.
>>
> 
> it seems x86_64 also broke the 'plt entry abi' several times
> (whenever new vector extensions were introduced)

Yes, and that's OK IMO, because LD_AUDIT is developer tooling and it's
the kind of scenario where we can tell users that they need to upgrade
their audit objects.

> we can do the same on aarch64, but that means plt entry does
> not have a stable abi (new extensions don't work on old glibc)

Yes, and I think that's OK.

> in case of sve, supporting the plt entry has significant costs.
> (stack usage, linux optimizations, save/restore overhead)
> so i would like to avoid that.

That's your choice. My position is to give you enough information to
make an informed choice. I'm reminding you that my experience within
Red Hat is that the lack of LD_AUDIT will impact an important set of
customers. The lack of PLT may not, as long as you have a GOT entry
that you indirect through and the GOT can be rewritten, we may still
support some of the key developer uses.

I will continue to work with HJ to ensure x86_64 doesn't loose the
LD_AUDIT capabilities, but there it's a little easier, we have a GOT
entry for the indirect call, and an unused PLT entry (extra binary
space), and we can redirect the GOT entry to the unused PLT entry to
get back auditing.

> it may be possible to keep the plt (and make ld_audit work),
> but force bind now semantics for vector functions somehow, so
> at least the lazy binding entry point remains backward compatible
> and efficient.  but i'm not sure if the compiler can do this.

Yes, I'm not suggesting you use the PLT entry, no, you just have it
there so you can use it in the case of LD_AUDIT, and have enough
relocation information present to make the vector functions callable
through the PLT entries. Is that possible?

-- 
Cheers,
Carlos.


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