[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.