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

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

> 
> Jan

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