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 13:13, <ross.lagerwall@xxxxxxxxxx> wrote:
> On 04/22/2016 11:08 AM, 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).
> 
> 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.

Not according to what I see - there are certainly also .text
relocations referencing .LC*.

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

As per my earlier reply to Konrad, there must be more to this. I.e.
"normal" local symbols won't get dropped together with relocations
referencing them getting resolved.

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

That's not of interest.

> So two patch modules may have conflicting 
> symbols just because they happen to use the same .LCx symbol.

Not if they're, as mentioned before, get properly prefixed with the
respective file name.

But as said in reply to Konrad, I'm fine with them getting dropped
as long as our rule matches ld's (which btw may be arch dependent).

Jan

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