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

Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address



>>> On 16.09.16 at 22:43, <konrad.wilk@xxxxxxxxxx> wrote:
> On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote:
>> Currently ELF end of image address is calculated using first line from
>> "nm -nr xen/xen-syms" output. However, today usually it contains random
>> symbol address not related to end of image in any way. So, it looks
> 
> Weird. The -n says:
> 
> "  -n
>        -v
>        --numeric-sort
>            Sort symbols numerically by their addresses, rather than 
> alphabetically by their names.
> "
> 
> And you are right. It is ignoring it:
> 
> [konrad@char xen]$ nm -nr xen/xen-syms| sort | head -1
> ffff82d080000000 T __image_base__
> [konrad@char xen]$ nm -nr xen/xen-syms | head -1
> ffff82d08033d000 B efi

So what is it ignoring, you think? The -n? Surely not. Are you perhaps
overlooking that -r means "reverse" (and hence that piping through
"sort" inverts all the sorting done by nm)?

> [konrad@char xen]$ nm -nr xen/xen-syms| sort | tail -5
> ffff82d08033cb00 B _end
> ffff82d08033cb00 B __per_cpu_data_end
> ffff82d08033d000 B __2M_rwdata_end
> ffff82d08033d000 B efi
>                  U _GLOBAL_OFFSET_TABLE_
> 
>> that for years that stuff have been working just by lucky coincidence.
>> Hence, it have to be changed to something more reliable. So, let's take
>> ELF end of image address by reading _end symbol address from nm output.

So before taking this patch I'd really like to see proof that what gets
done currently does actually go wrong in at least one case. So far I
can't see things working as "just by lucky coincidence". In particular
I can't see why __2M_rwdata_end (aliased to efi) does not relate to
the intended image end. Once we switch back to using large pages
even when not using xen.efi I'd even question whether preferring
_end over __2M_rwdata_end is actually correct.

The only real (but reasonably slim) risk we have right now is that an
absolute symbol might appear with a value larger than
__2M_rwdata_end. nm would certainly benefit from an option
allowing to filter out absolute symbols (just like one can filter out
undefined ones).

Jan


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

 


Rackspace

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