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

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

Jan


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