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

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

Jan

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