Re: [PATCH v8.1 14/27] xsplice, symbols: Implement symbol name resolution on address.

From: "Jan Beulich" <JBeulich@suse.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: keir@xen.org, Ross Lagerwall <ross.lagerwall@citrix.com>,
	andrew.cooper3@citrix.com, mpohlack@amazon.com,
	sasha.levin@oracle.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8.1 14/27] xsplice, symbols: Implement symbol name resolution on address.
Date: Fri, 22 Apr 2016 05:18:16 -0600	[thread overview]
Message-ID: <571A249802000078000E4B64@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160422110834.GF16225@localhost.localdomain>

>>> On 22.04.16 at 13:08, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 22, 2016 at 04:50:34AM -0600, Jan Beulich wrote:
>> >>> On 22.04.16 at 12:28, <konrad.wilk@oracle.com> wrote:
>> > On Fri, Apr 22, 2016 at 04:08:10AM -0600, Jan Beulich wrote:
>> >> >>> On 22.04.16 at 10:45, <ross.lagerwall@citrix.com> wrote:
>> >> > Rather than ignoring STT_NOTYPE, an alternative would be to ignore 
>> >> > symbols starting with ".L".
>> >> 
>> >> That's an option, but as said before, the rules for which symbols to
>> >> enter into the symbol table should be consistent for core and modules.
>> > 
>> > And they seem to - see above on the .o file.
>> 
>> Above .o file was a core one, and doesn't tell anyway whether in the
>> runtime symbol table the local symbols would be properly prefixed by
>> file name. Or did I misunderstand you?
> 
> I had 'built_in.o' or 'prelink.o' as the final one in mind - in which the
> .LCx are present. But I think you are thinking about 'xen-syms' output.
> 
> Looking at the Makefile runes we hit this:
> 127 $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> 128         $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
> 129             $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> 
> And that ends up causing the .xen-syms.0 file to drop all the .LC0.

That's odd: I don't know of us telling the linker to do so, and imo
it shouldn't do this by default. But yes, linkers often do strange
things...

> However we can't do that. We _have_ to produce an relocatable object
> and not do the final linking (so we append -r to the linker invocation).

Of course.

> I tried for fun to use strip:
> xen/xen/arch/x86/test> strip --strip-symbol=".LC0" xen_replace_world.xsplice
> strip: not stripping symbol `.LC0' because it is named in a relocation

Which it is rightfully saying.

So with the linker stripping .LC* (and why knows what else), you
stripping them when building the runtime symbol table would be
fine with me, provided we can somehow identify in the linker why
this stripping happens, and which precise set of symbols get
stripped (which you should then match in our code).

Jan

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