diff mbox

[v7,02/14] x86: properly calculate xen ELF end of image address

Message ID 1474667259-27290-3-git-send-email-daniel.kiper@oracle.com (mailing list archive)
State New, archived
Headers show

Commit Message

Daniel Kiper Sept. 23, 2016, 9:47 p.m. UTC
Currently xen ELF end of image address is calculated using first line from
"nm -nr xen/xen-syms" output. However, sometimes it may contain random
symbol address not related to the end of image in any way. It can happen
if a symbol is introduced with address larger than __end_of_image__ symbol
address. Such situation encountered when I linked xen ELF binary with
xen/arch/x86/efi/relocs-dummy.S. Then first line from "nm -nr xen/xen-syms"
contained "ffff82d0c0000000 A ALT_START" and xen ELF image memory size
was silently set to 1023 MiB. This issue happened because there is no
check which symbol address is used to calculate end of image address. So,
let's fix it and take ELF end of image address by reading __end_of_image__
symbol address from nm output. This way xen ELF image build process is
not prone to changes in order of nm output.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v7 - suggestions/fixes:
   - use sed instead of awk
     (suggested by Jan Beulich),
   - improve commit message
     (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Jan Beulich Sept. 26, 2016, 10:45 a.m. UTC | #1
>>> On 23.09.16 at 23:47, <daniel.kiper@oracle.com> wrote:
> Currently xen ELF end of image address is calculated using first line from
> "nm -nr xen/xen-syms" output. However, sometimes it may contain random
> symbol address not related to the end of image in any way.

There's nothing random here, or at least you fail to demonstrate that
there is (or might be). As said before - please don't describe an issue
you think needs fixing in a tendentious way.

> It can happen
> if a symbol is introduced with address larger than __end_of_image__ symbol
> address. Such situation encountered when I linked xen ELF binary with
> xen/arch/x86/efi/relocs-dummy.S. Then first line from "nm -nr xen/xen-syms"
> contained "ffff82d0c0000000 A ALT_START" and xen ELF image memory size
> was silently set to 1023 MiB.

What you really mean to say here is that this change is a prereq for
a later one.

> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -91,7 +91,7 @@ endif
>  
>  $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
>  	./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x100000 \
> -	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
> +		`$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . __end_of_image__$$/0x\1/p'`

I think it was Konrad who did already point out the bogus tab here.
I'm not against you adding some indentation, but then please do so
using spaces, such that the command line argument here aligns with
the first one on the previous line.

Jan
Daniel Kiper Sept. 26, 2016, 12:06 p.m. UTC | #2
On Mon, Sep 26, 2016 at 04:45:25AM -0600, Jan Beulich wrote:
> >>> On 23.09.16 at 23:47, <daniel.kiper@oracle.com> wrote:
> > Currently xen ELF end of image address is calculated using first line from
> > "nm -nr xen/xen-syms" output. However, sometimes it may contain random
> > symbol address not related to the end of image in any way.
>
> There's nothing random here, or at least you fail to demonstrate that
> there is (or might be). As said before - please don't describe an issue
> you think needs fixing in a tendentious way.

OK, maybe I should say that something which is not valid end of image address, e.g.:
"However, sometimes it may contain symbol address not related to the end
of image in any way." Is it OK for you?

> > It can happen
> > if a symbol is introduced with address larger than __end_of_image__ symbol
> > address. Such situation encountered when I linked xen ELF binary with
> > xen/arch/x86/efi/relocs-dummy.S. Then first line from "nm -nr xen/xen-syms"
> > contained "ffff82d0c0000000 A ALT_START" and xen ELF image memory size
> > was silently set to 1023 MiB.
>
> What you really mean to say here is that this change is a prereq for
> a later one.

Does it really matters here? This fix is quite generic, however, if you
wish I can add relevant sentence which says so.

Daniel
Jan Beulich Sept. 26, 2016, 12:34 p.m. UTC | #3
>>> On 26.09.16 at 14:06, <daniel.kiper@oracle.com> wrote:
> On Mon, Sep 26, 2016 at 04:45:25AM -0600, Jan Beulich wrote:
>> >>> On 23.09.16 at 23:47, <daniel.kiper@oracle.com> wrote:
>> > Currently xen ELF end of image address is calculated using first line from
>> > "nm -nr xen/xen-syms" output. However, sometimes it may contain random
>> > symbol address not related to the end of image in any way.
>>
>> There's nothing random here, or at least you fail to demonstrate that
>> there is (or might be). As said before - please don't describe an issue
>> you think needs fixing in a tendentious way.
> 
> OK, maybe I should say that something which is not valid end of image 
> address, e.g.:
> "However, sometimes it may contain symbol address not related to the end
> of image in any way." Is it OK for you?

Not really - "sometimes" still suggests that there is an active problem
even before this patch in some configurations or setups.

>> > It can happen
>> > if a symbol is introduced with address larger than __end_of_image__ symbol
>> > address. Such situation encountered when I linked xen ELF binary with
>> > xen/arch/x86/efi/relocs-dummy.S. Then first line from "nm -nr xen/xen-syms"
>> > contained "ffff82d0c0000000 A ALT_START" and xen ELF image memory size
>> > was silently set to 1023 MiB.
>>
>> What you really mean to say here is that this change is a prereq for
>> a later one.
> 
> Does it really matters here? This fix is quite generic, however, if you
> wish I can add relevant sentence which says so.

You should write the description in a way that it makes sense to anyone
reading it even without being aware of the details of later patches of
yours. Please always remember that patch series don't necessarily get
committed in one go - there may be weeks or even months between
this one going in and the other one following.

Jan
diff mbox

Patch

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d3875c5..c3a8920 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -91,7 +91,7 @@  endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
 	./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x100000 \
-	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+		`$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . __end_of_image__$$/0x\1/p'`
 
 .PHONY: tests
 tests: