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

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

On Fri, Apr 22, 2016 at 04:50:34AM -0600, Jan Beulich wrote:
> >>> On 22.04.16 at 12:28, <konrad.wilk@xxxxxxxxxx> wrote:
> > On Fri, Apr 22, 2016 at 04:08:10AM -0600, Jan Beulich wrote:
> >> >>> On 22.04.16 at 10:45, <ross.lagerwall@xxxxxxxxxx> wrote:
> >> > On 04/22/2016 08:51 AM, Jan Beulich wrote:
> >> >>>>> On 22.04.16 at 09:17, <ross.lagerwall@xxxxxxxxxx> wrote:
> >> >>> On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote: snip
> >> >>>>>
> >> >>>>>> +static bool_t is_payload_symbol(const struct xsplice_elf
> >> >>>>>> *elf, +                                const struct
> >> >>>>>> xsplice_elf_sym *sym) +{ +    if ( sym->sym->st_shndx ==
> >> >>>>>> SHN_UNDEF || +         sym->sym->st_shndx >=
> >> >>>>>> elf->hdr->e_shnum ) +        return 0; + +    return
> >> >>>>>> (elf->sec[sym->sym->st_shndx].sec->sh_flags & SHF_ALLOC) && +
> >> >>>>>> (ELF64_ST_TYPE(sym->sym->st_info) == STT_OBJECT || +
> >> >>>>>> ELF64_ST_TYPE(sym->sym->st_info) == STT_FUNC);
> >> >>>>>
> >> >>>>> I don't recall having seen a reply to the question on not
> >> >>>>> allowing
> >> >>> STT_NOTYPE here.
> >> >>>>
> >> >>>> Ross, could you elaborate a bit please on this?
> >> >>>
> >> >>>
> >> >>> The payload will typically have many entries like:
> >> >>>
> >> >>> 9: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    5 .LC1 10:
> >> >>> 0000000000000006     0 NOTYPE  LOCAL  DEFAULT    5 .LC2 11:
> >> >>> 000000000000000d     0 NOTYPE  LOCAL  DEFAULT    5 .LC3 12:
> >> >>> 0000000000000028     0 NOTYPE  LOCAL  DEFAULT    4 .LC4 13:
> >> >>> 0000000000000058     0 NOTYPE  LOCAL  DEFAULT    4 .LC5
> >> >>>
> >> >>> used when referencing strings (due to the use of -fPIC). While it
> >> >>> is not a problem for them to go into the symbol table, if more than
> >> >>> one payload is loaded, there will be duplicate conflicting symbols.
> >> >>> So, to prevent these symbols from going into the symbol table, I
> >> >>> disallowed STT_NOTYPE. Perhaps not the best solution but...
> >> >>
> >> >> First of all symbols starting with .L aren't meant to and up in the
> >> >> symbol table at all (i.e. even that of any intermediate .o file). So
> >> >> there's likely (but not necessarily) something wrong with the tool
> >> >> chain used (i.e. normally such symbols wouldn't be needed for e.g.
> >> >> relocations, as those should get converted to section relative
> >> >> ones).
> >> > 
> >> > This is not particular to the xsplice build process. Any version of 
> >> > GCC+binutils that I've tested with will generate .LC
> >> > symbols for strings into the .o file. Clang generates similar .L.str* 
> >> > symbols, in addition to other useless ones like 'NOTYPE  LOCAL  DEFAULT
> >> > ABS X86_FEATURE_FFXSR'...
> >> 
> >> I can confirm the symbols getting generated in the .s file, ...
> >> 
> >> > Maybe it uses these .LC symbols rather than section relative ones
> >> > because they point to a mergeable string section, and merging string
> >> > sections would be harder with section relative references?
> >> 
> >> ... but I can't confirm them making it into the .o file, not to speak
> >> of being used for relocations. I've tried gcc 4.3.4 as well as 5.3.0
> >> (with and without -fPIC).
> > 
> > /home/konrad/xen/xen/arch/x86
> > [konrad@build-external x86]$ readelf --symbols microcode.o  | grep \.LC
> >     50: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT   12 .LC0
> >     51: 00000000000000e8     0 NOTYPE  LOCAL  DEFAULT   13 .LC5
> >     52: 0000000000000110     0 NOTYPE  LOCAL  DEFAULT   13 .LC6
> > 
> > ?
> > (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)
> 
> Ah, this happens only with optimization, and I had tried only
> without. Looks to indeed be connected to these strings getting
> put into mergeable string sections, instead of just plain .rodata.
> 
> >> >> Yet _if_ such symbols make it into the symbol table of a .o, then
> >> >> there is no reason for them to not also make it into the runtime
> >> >> symbol table. Of course similar ones from different modules then
> >> >> shouldn't conflict with one another, and as these are local symbols
> >> >> perhaps the reason for them conflicting is that in the process of
> >> >> creating the runtime symbol table entries you neglect to prefix them
> >> >> with their source or object file names, as is done by
> >> >> xen/tools/symbols.c for the core symbol table? Quite obviously the
> >> >> symbol name generation should match between core and modules...
> >> >>
> >> > 
> >> > The build tool does prefix the required functions and objects with their
> >> > source/object file names. The problem is that these are generated
> >> > symbols, so even if you had e.g. keyhandler.c#.LC0, keyhandler.c#.LC1,
> >> > in the symbol table, they might be completed unrelated if you change the
> >> > source even slightly. Having these entries in the symbol table would not
> >> > make any sense.
> >> 
> >> Why not? They could still serve as anchor for subsequent patches.
> > 
> >> 
> >> > 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.

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).

If we do not:
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400144
xen_hello_world.o:(.xsplice.funcs+0x10): undefined reference to 
`xen_extra_version'
ld: xen_hello_world.xsplice: hidden symbol `xen_extra_version' isn't defined
make[3]: *** [xen_hello_world.xsplice] Error 1

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

But it has some hard rules about it.

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