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

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

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

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