Message ID | 1474667259-27290-3-git-send-email-daniel.kiper@oracle.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>> 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
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
>>> 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 --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:
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(-)