Re: [Xen-devel] [PATCH 10/11] move various bits into .init.* sections

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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