Re: Hotpatch construction and __LINE__

[Ross Lagerwall <ross.lagerwall@citrix.com>]

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