Re: [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Oct 12, 2016 at 04:17:57PM +0200, Martin Pohlack wrote:
> 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.wilk@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
> > > > version!
> > > > 
> > > > 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
> > naming.
> > 
> > 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.

I think the matchmaking process does not solve per say some tricky CSWTCH issues.

If a patch mucks with a switch statement (e.g. add a new case) we are pretty much
guaranteed to get in trouble. And really a change in any control structure may cause
gcc to take different code path, causing it to renumber CSWTCH. Or worst, renumber
it to the one that the hypervisor is using for some other switch statements.
I think the size of the symbol vs the one in the hypervisor is different
so one can check for this. Bad things happen if it is the same size, but bcmp
can come in handy there.

Are there any ways to make GCC be predictable or some patches
to make GCC be less random. Perhaps instead of XYZ it would use the function name..

P.S.
GCC scares me because the code comes in these big patches with not much explanation
on how it suppose to work. It probably is a piece of cake for folks who
have been marinating in compilers but for a newbie like me it is hardcore
black magic.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel