[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names
On 20.11.2019 18:13, Andrew Cooper wrote: > On 20/11/2019 16:40, Jürgen Groß wrote: >> On 20.11.19 17:30, Jan Beulich wrote: >>> On 08.11.2019 12:18, Jan Beulich wrote: >>>> The .file assembler directives generated by the compiler do not include >>>> any path components (gcc) or just the ones specified on the command >>>> line >>>> (clang, at least version 5), and hence multiple identically named >>>> source >>>> files (in different directories) may produce identically named static >>>> symbols (in their kallsyms representation). The binary diffing >>>> algorithm >>>> used by xen-livepatch, however, depends on having unique symbols. >>>> >>>> Make the ENFORCE_UNIQUE_SYMBOLS Kconfig option control the (build) >>>> behavior, and if enabled use objcopy to prepend the (relative to the >>>> xen/ subdirectory) path to the compiler invoked STT_FILE symbols. Note >>>> that this build option is made no longer depend on LIVEPATCH, but >>>> merely >>>> defaults to its setting now. >>>> >>>> Conditionalize explicit .file directive insertion in C files where it >>>> exists just to disambiguate names in a less generic manner; note that >>>> at the same time the redundant emission of STT_FILE symbols gets >>>> suppressed for clang. Assembler files as well as multiply compiled C >>>> ones using __OBJECT_FILE__ are left alone for the time being. >>>> >>>> Since we now expect there not to be any duplicates anymore, also don't >>>> force the selection of the option to 'n' anymore in allrandom.config. >>>> Similarly COVERAGE no longer suppresses duplicate symbol warnings if >>>> enforcement is in effect, which in turn allows >>>> SUPPRESS_DUPLICATE_SYMBOL_WARNINGS to simply depend on >>>> !ENFORCE_UNIQUE_SYMBOLS. >>>> >>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >>> >>> I've got acks from Konrad and Wei, but still need an x86 and a release >>> one here. Andrew? Or alternatively - Jürgen, would you rather not see >>> this go in anymore? >> >> In case the needed x86 Ack is coming in before RC3 I'm fine to give my >> Release-ack, but I'm hesitant to take it later. > > Has anyone actually tried building a livepatch with this change in place? I've never tried building any live patch, so I also didn't test this angle of this change. But I did verify the results of what the change here does. I'm also a little puzzled about this response because I did the change upon your request. > I ask, because there is 0 testing of livepatches, and already one major > regression in 4.13 which forces XenServer to revert back to older build > tools. That's a build tools regression, isn't it? I.e. not really related to 4.13? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |