[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

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

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?

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.

Rather than ignoring STT_NOTYPE, an alternative would be to ignore symbols starting with ".L".

Ross Lagerwall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.