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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan

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