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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.04.16 at 17:27, <konrad.wilk@xxxxxxxxxx> wrote:
> 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

Yeah, that's surely too old (assuming it also doesn't have those
fixes backported) - iirc said changes didn't even make it into 2.26.

Jan

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