Re: [Xen-devel] [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Apr 08, 2016 at 09:21:37AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 03:32, <konrad@xxxxxxxxxx> wrote:
> > On Thu, Apr 07, 2016 at 09:46:49AM -0600, Jan Beulich wrote:
> >> >>> On 07.04.16 at 05:14, <konrad.wilk@xxxxxxxxxx> wrote:
> >> > On Fri, Apr 01, 2016 at 09:11:40AM -0600, Jan Beulich wrote:
> >> >> >>> On 24.03.16 at 21:00, <konrad.wilk@xxxxxxxxxx> wrote:
> >> >> > --- a/xen/arch/x86/Makefile
> >> >> > +++ b/xen/arch/x86/Makefile
> >> >> > @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds 
> >> >> > $(BASEDIR)/common/symbols-dummy.o
> >> >> >       $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> >> >> >           $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> >> >> >       $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
> >> >> > -             | $(BASEDIR)/tools/symbols --sysv --sort 
> >> >> > >$(@D)/.$(@F).0.S
> >> >> > +             | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
> >> >> > +             >$(@D)/.$(@F).0.S
> >> >> >       $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> >> >> >       $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> >> >> >           $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> >> >> >       $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
> >> >> > -             | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup 
> >> >> > >$(@D)/.$(@F).1.S
> >> >> > +             | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort 
> >> >> > --warn-dup \
> >> >> > +             >$(@D)/.$(@F).1.S
> >> >> 
> >> >> This addition should be dependent on CONFIG_XSPLICE, not the
> >> >> least because I expect it to bloat the symbol table quite a bit. And
> >> >> then - how come this is needed here, but not in the xen.efi rule?
> >> > 
> >> > I added it to xen.efi rule and got:
> >> > 
> >> > home/konrad/xen/xen/.xen.efi.0s.S: Assembler messages:
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f80000543 
> >> > truncated to 0x80000543
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f800008b2 
> >> > truncated to 0x800008b2
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f800008b4 
> >> > truncated to 0x800008b4
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f800008b9 
> >> > truncated to 0x800008b9
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000103f 
> >> > truncated to 0x8000103f
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001043 
> >> > truncated to 0x80001043
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001047 
> >> > truncated to 0x80001047
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:6746: Warning: value 0x100650000 
> >> > truncated to 0x650000
> >> > 
> >> > and so on.. Not sure why. The xen.efi file boots thought?
> >> 
> >> It's the kallsyms symbol table that suffers, so the image booting
> >> fine is not really surprising. But we'd need to understand what
> >> specific data objects these warnings originate from - perhaps
> >> linker generated symbols not sitting inside sections?
> > 
> > From the .xen.efi.0s.S:
> > .globl symbols_offsets
> >     ALGN
> > symbols_offsets:
> > #endif
> >     PTR     0x544 - SYMBOLS_ORIGIN
> >     PTR     0xa01 - SYMBOLS_ORIGIN
> >     PTR     0xa03 - SYMBOLS_ORIGIN
> >     PTR     0xa08 - SYMBOLS_ORIGIN
> >     PTR     0x118e - SYMBOLS_ORIGIN
> >     PTR     0x1192 - SYMBOLS_ORIGIN
> >     PTR     0x1196 - SYMBOLS_ORIGIN
> >     PTR     0xffff82d080100000 - SYMBOLS_ORIGIN
> >     PTR     0xffff82d080100000 - SYMBOLS_ORIGIN
> > 
> > which corresponds to:
> > multiboot1_header_start|0000000000000544|   ?  |                  | |     |
> > multiboot1_header_start|0000000000000a01|   ?  |                  | |     |
> > multiboot1_header_start|0000000000000a03|   ?  |                  | |     |
> > multiboot1_header_start|0000000000000a08|   ?  |                  | |     |
> > multiboot1_header_start|000000000000118e|   ?  |                  | |     |
> > multiboot1_header_start|0000000000001192|   ?  |                  | |     |
> > multiboot1_header_start|0000000000001196|   ?  |                  | |     |
> > 
> > which is also found:
> > multiboot1_header_start|ffff82d080100008|   t  |                  | |     | 
> 
> That looks like a binutils issue, associating the wrong name with
> certain symbols. Depending on what binutils version you have in
> use, this may be well be one of those I've fixed already.

[konrad@x230 ~]$ rpm -qa | grep binutils
binutils-2.25-9.fc22.x86_64
mingw64-binutils-2.25-1.fc22.x86_64
binutils-devel-2.25-9.fc22.x86_64
mingw-binutils-generic-2.25-1.fc22.x86_64

> 
> Jan
> 

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