>>> On 13.06.17 at 23:13, <andrew.coop...@citrix.com> wrote: > On 13/06/17 21:51, Andrew Cooper wrote: >> A symndx of STN_UNDEF is special, and means a symbol value of 0. >> >> There is no real symbol data for it, so avoid tripping over a NULL pointer >> with "elf->sym[symndx].sym->st_value". >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >> --- >> CC: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> >> CC: Ross Lagerwall <ross.lagerw...@citrix.com> >> CC: Jan Beulich <jbeul...@suse.com> >> CC: Stefano Stabellini <sstabell...@kernel.org> >> CC: Julien Grall <julien.gr...@arm.com> >> >> Functionally tested on x86, but both arm variants look to suffer from the > same >> issue. Compile tested on all architectures. >> >> TODO: Figure out how my livepatch has a STN_UNDEF relocation... > > On second thoughts, maybe STN_UNDEF symbols should be a hard failure.
Perhaps, but I still don't see where it was coming from in the first place. > (XEN) livepatch: live: Applying 1 functions > (XEN) ----[ Xen-4.10-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 3 > (XEN) RIP: e008:[<0000000000000000>] 0000000000000000 > > In this case, the hook function hasn't been wired up correctly, which > causes apply_payload() to fall over a NULL data->load_funcs[i](); > > As for why the STN_UNDEF symbol, it comes from an assembly hook function > missing a .type attribute. Still, Xen shouldn't crash when it > encounters one. I don't understand - a missing .type would lead to STT_NOTYPE in the symbol table, but not a relocation targeting STN_UNDEF. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
