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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Apr 22, 2016 at 12:13:02PM +0100, Ross Lagerwall wrote:
> On 04/22/2016 11:08 AM, Jan Beulich wrote:
> >>>>On 22.04.16 at 10:45, <ross.lagerwall@citrix.com> wrote:
> >>On 04/22/2016 08:51 AM, Jan Beulich wrote:
> >>>>>>On 22.04.16 at 09:17, <ross.lagerwall@citrix.com> 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).
> 
> I've looked into this a little further. The only .LC* symbols left in the .o
> file are the ones which are used in bug_frame relas. These symbols do not
> make it into the core symbol table because the relas are dropped when the
> xen binary is linked just before tools/symbols is run. Obviously we can't
> drop the rela sections for xsplice because it needs to be relocatable.


In my case I seem to have one of the test-cases have one the .text
section.
 That is:

File: arch/x86/test/xen_bye_world.xsplice

Relocation section '.rela.text' at offset 0x11a8 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000007  001300000002 R_X86_64_PC32     0000000000000000 .LC0 - 4

Which .. is related to the string:

Disassembly of section .text:

0000000000000000 <xen_bye_world>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # b <xen_bye_world+0xb>
   b:   c9                      leaveq 
   c:   c3                      retq   

Which we obviously do need.

> 
> >
> >>>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.
> 
> They're not useful because they're autogenerated and the numbering may
> change from build to build. So two patch modules may have conflicting
> symbols just because they happen to use the same .LCx symbol.
> 
> >
> >>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.
> >
> 
> Yes. And, as best I can tell, .L symbols are not in the core table so this
> would then make it consistent for modules.
> 
> -- 
> Ross Lagerwall

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