>>> On 21.10.15 at 10:43, <ian.campb...@citrix.com> wrote: > On Tue, 2015-10-20 at 04:38 -0600, Jan Beulich wrote: >> This requires adjustments to the tool generating the symbol table and >> its as well as nm's invocation. >> >> Note: Not warning about duplicate symbols in the EFI case for now, as >> a binutils bug causes misnamed file name entries to appear in EFI >> binaries' symbol tables when the file name is longer than 18 chars. >> (Not doing so also avoids other duplicates getting printed twice.) >> >> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> --- >> No changing ARM for now, as xSplice isn't targeted at it just yet. > > The improved information from e.g. stack traces (which I'm supposing this > also enables) seems valuable on ARM too. Is this something you plan to add > or shall we ARM folks add it to our todo?
I can certainly implement it, but I can't - other than for x86 - verify (other than by looking at the binary) that it has the intended effect. (Of course all that hoping that I won't find more binutils issues in the course of doing so.) > I suspect the answer is no, but do you think there is much scope for making > some of these complex linker runes common instead of arch specific? I had considered this a while ago, but deemed it not worth it due to the xen.efi rule necessarily being arch-specific (at least it would be quite a bit harder to abstract this). But I guess we could move it to xen/Rules.mk > From what I can tell the actual arch change here is s/-n/-pa/ on the NM > invocation (numeric sort => no sort + include debugger symbols) and then > add --sysv --sort and optionally --want-dup to the tools/symbols > invocation. Is it really as simple as that? It is, luckily. > Given we don't do a special EFI build/link I think on ARM we do want --warn > -dup if at all possible. Ultimately this is mostly useful for xSplice; when just considering stack traces, a couple of duplicates don't really do much harm. But of course using the same options for both architectures would simplify the making common of the rule. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
