On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
On 12.10.16 at 15:23, <konrad.w...@oracle.com> wrote:
And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler version?
Uh, I hope one does not create a livepatch patch with another compiler
Let me put on the TODO to make livepatch-build-tools check gcc against
compile.h so that one does not try this.
What's wrong with mixing compiler versions in general?
Besides scaring me?
The one issue we had encountered was with compilers generating random named
symbols for the switch tables. Those end up being called "CSWTCH.XYZ"
where the XYZ depends on the position of the moon along with how many
goats you have sacrificied to the altar of GCC gods.
Older compilers don't neccessarily do it, newer ones do, and every time
you build an livepatch the naming is different. Frustrating.
It maybe that newer versions of GCC are more predictable about this
Maybe Martin can share some of his experience? CC-ing him.
There are a couple of naming conventions for internal symbols and also
static symbols where you basically have to pray that gcc implementation
does not change. Interestingly, icc has some conventions that make
those symbol names a bit more stable.
The tricky thing is matchmaking between the existing build and the new
build to construct the binary diff and to match up symbols for which you
want to provide replacement code.
We use a reproducible build environment to construct hotpatches for an
existing build in the absolutely same environment (gcc version, lib
versions, gas version, binutils etc.). This sidesteps most of the problems.
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
Xen-devel mailing list