On 11/07/2017 09:22 AM, Tsimbalist, Igor V wrote:
> I decided to split my previous patch "Enable building libitm with Intel CET "
> into two different patches. The first patch will add a new field to sjlj.S and
> target.h files. The second one will add Intel CET support on the top of the
> first one. In this case the further changes for adding Intel CET support are
> seen clearly.
>
> Ok for trunk?
>
[ ... snip ... ]
>
>
> 0021-Add-extra-field-to-gtm_jmpbuf-on-x86-only.patch
>
>
> From a6361c78bf774f2b4dbeeaf4147c286cff4ae5a4 Mon Sep 17 00:00:00 2001
> From: Igor Tsimbalist <igor.v.tsimbal...@intel.com>
> Date: Tue, 7 Nov 2017 17:00:24 +0300
> Subject: [PATCH 21/22] Add extra field to gtm_jmpbuf on x86 only
>
> Expand the gtm_jmpbuf structure by one word field to add
> Intel CET support further. The code in sjlj.S already
> allocates more space on the stack then gtm_jmpbuf needs.
> Use this extra space to absorb the new field.
>
> The structure is allocated on the stack in such a way
> that eip/rsp field is overlapped with return address on
> the stack. Locate the new field right before eip/rsp so
> code that accesses buffer fields relative to address of
> gtm_jmpbuf has its offsets unchanged.
>
> The libtool_VERSION is updated for x86 due to extending
> the gtm_jmpbuf structure.
>
> * libitm/config/x86/target.h: Add new field (ssp).
> * libitm/config/x86/sjlj.S: Change offsets.
> * libitm/configure.tgt: Update libtool_VERSION.
So if I understand correctly, given the desire to to have the eip/rip
field overlap with the return address on the stack offset changes are
inevitable if we add fields.
> esac
> +
> +# Update libtool_VERSION since the size of struct gtm_jmpbuf is
> +# changed for x86.
> +case "${host}" in
> +
> + # For x86, we use slots in the TCB head for most of our TLS.
> + # The setup of those slots in beginTransaction can afford to
> + # use the global-dynamic model.
> + i[456]86-*-* | x86_64-*-*)
> + libtool_VERSION=2:0:0
What's the plan for supporting existing code that may have linked
dynamically against libitm?
One approach is to force the distros to carry the old libitm DSO.
THe other would be to try and support both within the same DSO using
symbol versioning. That would seem to imply that we'd need to the
before/after code to build that single library that supported both.
Thoughts? Jakub, any interest in chiming in here?
jeff
> + ;;
> +esac
> -- 1.8.3.1
>
