This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Arm's SVE PCS and LD_AUDIT support?
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com
- Date: Mon, 3 Feb 2020 11:35:35 +0000
- Subject: Re: Arm's SVE PCS and LD_AUDIT support?
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n7wGhP30kT1phfGLWvVYEhAI0KBdYOrgs0F1PchoRbE=; b=S7eq4fuBJ6E9GUzCSFaBIigeRJ6QrpTrpX1PNKH8SHvLBiZuz2+AZ9eSXf+1QUHju7YR2Cq3X/7pcXIj0aIjsiDtECxwYiadiXtj7cTmBsHC/vGfSMVUqXrx+G0t3gGgNMZMUzwzPzcYbLzE7zuKPYpkQYgzwCLyHAsccxvWg4YIXOrj7biTBtYC4MTDlhimSJIdjhzvEp3mFf4+PFWZhUINK+OPLOB5B/JD1SteJ02YT29oxNnGV6uYmvA90BzXuFXacmKcToGzF1vzPo2OxWt8EeCUly0eCZ6VKxwMTyhxcbaNnPOpgEy/vHC2AKoybUJpVKXz/ZASjI7VfPFVTQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cP6cZ+cZoXj7YEzKGV/HZvrwC40jDrcynoH0KwO/bi59LjXZDHEfeOTnsZus+vRSPt4ZLguoVdmxoIxu0xTVcV4VLBLrky6UDtlXlopAWmI6IMYldrcuVH5BkGQYekiJLYX4jqdaLVL332+U68Oic8zefeWzX+bGLcn8Id/oHg9oRopls578Gsu0tQsOMWAW1DIzn1Gh8izGbVcLDQTwoH0VKtKfaWSTI/IGr7qbCSHslA5qmTJIp271O3I6ZfHfiywScAluWRXM1XzGseirrGe1OpZTbPzJtpKwNPkycRNqAK3xZmUnXM7tx0KC7O6Zg7eoKmqR7hRQ0zPnrkBcAw==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <4dfd7792-f5d3-452a-2089-099dc2f82d21@redhat.com>
On 01/02/2020 03:37, Carlos O'Donell wrote:
> Szabolcs,
>
> One of the things I want to refactor is to move some of the LD_AUDIT
> support up a level inside the dynamic loader and have it depend
> less on the lazy-binding semantics.
>
> I want only la_pltenter() and la_pltexit() to be affected by the
> binding semantics, but today because lazy was the default, we aren't
> there yet.
iirc currently any load time bound pltgot entries
will not go via plt hook of ldaudit because it
uses the same entry mechanism as lazy binding
(plt0 jumps to GOT[2]) so vpcs is not using ld
audit now.
will that change?
> Florian and I were wondering if we couldn't implement the following:
>
> - Leave PLT in place for SVE PCS but unused.
>
> - Enable full save-restore in plt enter/exit conservatively for
> STO_AARCH64_VARIANT_PCS if LD_AUDIT is in use, possibly routing
> those symbols to a different _dl_profile_fixup_full_save?
>
> Would that work?
i don't understand what is the new ld audit mechanism
for hooking into the plt if not GOT[1] & GOT[2].
when the vpcs abi was designed we were thinking about
adding a second entry point somewhere (e.g.
DT_AARCH64_VPCS_PLT and DT_AARCH64_VPCS_PLTGOT)
instead of using GOT[1] as PLTGOT initializer which
then jumps to GOT[2], variant_pcs symbols could
use a different entry point which can do whatever
it takes to make lazy binding work.
but it seemed a bit too much hassle for something
we don't really plan to use (bind now for vpcs is
good enough) and in principle the entry point can
handle variant_pcs and normal symbols differently,
it's just ugly because checking for the STO_*
symbol table flag at runtime has to happen in
asm since we don't know the pcs yet.
adding such second entry is still possible, or
the ld audit hook can do something ugly in asm.
if you can distinguish normal and vpcs syms in
the hook then i see no problem doing ld audit,
but the struct where the register state is saved
need to be scalable (currently exposed to the
user in the plt callbacks).