At 14:09 +0000 on 09 Mar (1299679764), Jan Beulich wrote:
> >>> On 09.03.11 at 14:30, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
> > At 12:30 +0000 on 09 Mar (1299673837), Jan Beulich wrote:
> >> --- 2011年03月09日.orig/xen/arch/x86/Makefile
> >> +++ 2011年03月09日/xen/arch/x86/Makefile
> >> @@ -16,10 +16,10 @@ obj-y += copy_page.o
> >> obj-y += compat.o
> >> obj-y += debug.o
> >> obj-y += delay.o
> >> -obj-y += dmi_scan.o
> >> +obj-bin-y += dmi_scan.init.o
> >> obj-y += domctl.o
> >> obj-y += domain.o
> >> -obj-y += domain_build.o
> >> +obj-bin-y += domain_build.init.o
> >> obj-y += e820.o
> >> obj-y += extable.o
> >> obj-y += flushtlb.o
> > 
> > I don't understand this - have you some reason for needing those objects
> > to be built as binaries? Also I don't see a rule that makes %.init.o
> > from %.c but I may just have missed some Makefile-fu. 
>
> The (new) rule constructs %.init.o from %.o, prefixing .init to
> various (data) sections. I have no need for these to be binary
> per se, but I do need them to be manageable by objcopy, and
> as this concerns only objects that have *only* init code (just
> like libelf, where I looked up how you did your change), I don't
> think they'd really benefit from LTO.
Righto. Thanks for the explanation.
Tim.
-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel