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

2016-09-22 Thread Jan Beulich
>>> On 22.09.16 at 13:45, wrote: > However, I am still not sure why do not you want change currently > existing solution used to calculate end of image address. I showed > that it is easy to break. So, why we must live with it? I didn't say it needs to remain that way.

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

2016-09-22 Thread Daniel Kiper
On Wed, Sep 21, 2016 at 03:37:52AM -0600, Jan Beulich wrote: > >>> On 20.09.16 at 20:00, wrote: > > OK, I did some more tests and found out that after patch "efi: build > > xen.gz with EFI code" we have following xen ELF file: > > > > Program Headers: > > Type

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

2016-09-21 Thread Jan Beulich
>>> On 20.09.16 at 20:00, wrote: > OK, I did some more tests and found out that after patch "efi: build > xen.gz with EFI code" we have following xen ELF file: > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD

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

2016-09-20 Thread Daniel Kiper
On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote: > >>> On 19.09.16 at 15:56, wrote: > > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: [...] > >> So before taking this patch I'd really like to see proof that what gets > >> done currently does

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

2016-09-20 Thread Jan Beulich
>>> On 20.09.16 at 13:43, wrote: > On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote: >> >>> On 19.09.16 at 15:56, wrote: >> > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: >> >> >>> On 16.09.16 at 22:43,

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

2016-09-20 Thread Daniel Kiper
On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote: > >>> On 19.09.16 at 15:56, wrote: > > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: > >> >>> On 16.09.16 at 22:43, wrote: > >> > On Mon, Sep 12, 2016 at 10:18:16PM +0200,

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

2016-09-19 Thread Jan Beulich
>>> On 19.09.16 at 15:56, wrote: > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: >> >>> On 16.09.16 at 22:43, wrote: >> > On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote: >> >> Currently ELF end of image address is

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

2016-09-19 Thread Daniel Kiper
On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: > >>> On 16.09.16 at 22:43, 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.

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

2016-09-19 Thread Daniel Kiper
On Fri, Sep 16, 2016 at 04:43:21PM -0400, Konrad Rzeszutek Wilk 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

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

2016-09-19 Thread Jan Beulich
>>> On 16.09.16 at 22:43, 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

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

2016-09-16 Thread Konrad Rzeszutek Wilk
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