This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86: Use pad in pthread_unwind_buf to preserve shadow stack register
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>, "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Apr 2018 20:02:52 +0000
- Subject: Re: [PATCH] x86: Use pad in pthread_unwind_buf to preserve shadow stack register
- References: <CAMe9rOpj6nYdP33emmepZ+KWFG2JDVNsHn1bve3oo5WQyFmduA@mail.gmail.com> <61a5b452-e59e-dfef-4530-a94a60480961@redhat.com> <CAMe9rOr68P6Z=rX=xeFG1PbQE1fZ14iN3NmZEpChjP6QmUfS8g@mail.gmail.com>
On Fri, 6 Apr 2018, H.J. Lu wrote:
> https://github.com/hjl-tools/glibc/commit/9bf6aefa8fb45f8df140d42ce9cf890bb24076e1
>
> It should be binary backward compatible. I will investigate if there is a way
Increasing the size of a public type is always dangerous, because you can
end up with one part of a program expecting the new, larger size but
another part only allocating the old, smaller size.
It might in some cases be compatible to the extent that existing linked
programs and shared libraries work with new glibc, if new glibc will never
try to write into the unallocated part of such objects allocated by an
existing linked program or shared library. However, any such change would
need a careful analysis of how the type gets written to, and to what
extent external libraries have interfaces that depend on the size of the
type, and would need a NEWS entry explaining the change and discussing the
compatibility issues with it.
--
Joseph S. Myers
joseph@codesourcery.com