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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.04.16 at 08:41, <ross.lagerwall@xxxxxxxxxx> wrote:
> On 04/22/2016 10:10 PM, Konrad Rzeszutek Wilk wrote:
>>> 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.
>>
>> Correct. These .LCx symbols only cover .rodata.* sections. Any other
>> local symbols:
>>
>> [konrad@x230 x86]$ readelf --symbols prelink.o |grep bad_hypercall
>>   8946: 0000000000145549     0 NOTYPE  LOCAL  DEFAULT    1 
> compat_bad_hypercall
>>   8967: 0000000000145c79     0 NOTYPE  LOCAL  DEFAULT    1 bad_hypercall
>>
>> don't get dropped and do show up in the binary (nm --defined finds them).
>>
>> While .LC matches the type:
>>   9147: 00000000000008c0     0 NOTYPE  LOCAL  DEFAULT   33 .LC5
>>
>> They are in four other sections:
>> konrad@x230 x86]$ readelf --symbols prelink.o |grep LC | awk '{print
>> $7}' | sort | uniq
>> 22
>> 23
>> 33
>> 34
>>
>> [22] .rodata.str1.1    PROGBITS         0000000000000000  0019d500
>>        000000000000a088  0000000000000001 AMS       0     0     1
>>   [23] .rodata.str1.8    PROGBITS         0000000000000000  001a7588
>>        0000000000020a31  0000000000000001 AMS       0     0     8
>>   [33] .init.rodata.str1 PROGBITS         0000000000000000  001d5a78
>>        0000000000000a1e  0000000000000001 AMS       0     0     1
>>   [34] .init.rodata.str1 PROGBITS         0000000000000000  001d6498
>>        0000000000002331  0000000000000001 AMS       0     0     8
>>
> 
> With some helpful investigation by Konrad, I've found this snippet in 
> binutils:
> 
>    /* See if we are discarding symbols with this name.  */
>    if ((flinfo->info->strip == strip_some
>         && (bfd_hash_lookup (flinfo->info->keep_hash, name, FALSE, FALSE)
>             == NULL))
>        || (((flinfo->info->discard == discard_sec_merge
>       && (isec->flags & SEC_MERGE)
>       && !bfd_link_relocatable (flinfo->info))
>         || flinfo->info->discard == discard_l)
>         && bfd_is_local_label_name (input_bfd, name)))
>      continue;
> 
> The default value for info->discard is discard_sec_merge, so:
> Local labels referring to a mergeable section are discarded when the 
> output is not relocatable.
> A local label is defined as:
> 1) Starts with .X (for i386 unixware compilers)
> 2) Starts with .L
> 3) Starts with .. (for SRV4 compilers)
> 4) Starts with _.L_ (for older buggy GCC)
> 5) Matches L0^A.*
> 6) Matches L[0-9]+{^A|^B}[0-9]* (for assembler generated local labels)
> 
> So to match what is used by the default hypervisor build, I think we 
> should change the check to discard when the symbol matches (2), (5), or 
> (6) above and refers to a mergeable section. The above rules are defined 
> in _bfd_elf_is_local_label_name and elf_i386_is_local_label_name.

Yes. (Note that we don't really care about
elf_i386_is_local_label_name(), as we don't have a 32-bit
hypervisor anymore.)

Jan


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