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

[Martin Pohlack <mpohlack@xxxxxxxxxx>]

On 12.10.2016 18:21, Konrad Rzeszutek Wilk wrote:
> 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@xxxxxxxxxx> 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.
If you change a switch statement, the containing function's binary 
representation will change (+ inlining effects).  This means you will 
have to ship a new version of this function with the hotpatch.  I have 
seen gcc put jump tables for switch statements into dedicated .rodata* 
sections, at least with -ffunction-sections and -fdata-sections.  You 
need to treat those as belonging to the corresponding function and also 
ship them with the hotpatch.  If you restrict the match-making to 
function-level symbols and retain references between such a function and 
its rodata section, you should be fine.
> 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..
You sidestep some issues by making source-code patches as line-neutral 
as possible and introducing new symbols and definitions close to usage 
instead of in header files for hotpatches.  This reduces cascading 
effects for such renames.  Some luck, tweaking, and inlining of 
definitions is sometimes required.
Martin

> 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.
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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