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

Re: [Xen-devel] Hotpatch construction and __LINE__



On 08/05/2015 09:55 AM, Martin Pohlack wrote:
Hi,

Another high-level point to think about is how we want to handle inlined
__LINE__ references.  This problem is related to hotpatch construction
and potentially has influence on the design of the hotpatching
infrastructure in Xen.

Let me try to explain the problem:

We have file1.c with functions f1 and f2 (in that order).  f2 contains a
BUG() (or WARN()) macro and at that point embeds the source line number
into the generated code for f2.

Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
lines to f1 and as a consequence shifts out f2 by two lines.  The newly
constructed file1.o will now contain differences in both binary
functions f1 (because we actually changed it with the applied patch) and
f2 (because the contained BUG macro embeds the new line number).

Without additional information, an algorithm comparing file1.o before
and after hotpatch application will determine both functions to be
changed and will have to include both into the binary hotpatch.

Options:

1. Transform source code patches for hotpatches to be line-neutral for
    each chunk.  This can be done in almost all cases with either
    reformatting of the source code or by introducing artificial
    preprocessor "#line n" directives to adjust for the introduced
    differences.

    This approach is low-tech and simple.  Potentially generated
    backtraces and existing debug information refers to the original
    build and does not reflect hotpatching state except for actually
    hotpatched functions but should be mostly correct.

2. Ignoring the problem and living with artificially large hotpatches
    that unnecessarily patch many functions.

    This approach might lead to some very large hotpatches depending on
    content of specific source file.  It may also trigger pulling in
    functions into the hotpatch that cannot reasonable be hotpatched due
    to limitations of a hotpatching framework (init-sections, parts of
    the hotpatching framework itself, ...) and may thereby prevent us
    from patching a specific problem.

    The decision between 1. and 2. can be made on a patch--by-patch
    basis.

3. Introducing an indirection table for storing line numbers and
    treating that specially for binary diffing.  I believe Linux follows
    this approach, but the details escape me ATM.

    We might either use this indirection table for runtime use and patch
    that with each hotpatch (similarly to exception tables) or we might
    purely use it when building hotpatches to ignore functions that only
    differ at exactly the location where a line-number is embedded.


For BUG, ASSERT, and WARN, the line number is stored in the bug frame table and as currently implemented, the build tool ignores changes to the bug frame table if there's no corresponding functional change. Which mostly fixes this issue.

--
Ross Lagerwall

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


 


Rackspace

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