Re: generate one module from multiple object files (was: Re: [PATCH 2/2] usb: gadget: convert all users to the new udc)

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3177 bytes --]

On Tue, Jun 14, 2011 at 01:06:16PM -0400, Alan Stern wrote:
> On Tue, 14 Jun 2011, Felipe Balbi wrote:
> 
> > > --- a/drivers/usb/gadget/Makefile
> > > +++ b/drivers/usb/gadget/Makefile
> > > @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300)    += fusb300_udc.o
> > >  # USB gadget drivers
> > >  #
> > >  g_zero-y                       := zero.o
> > > +g_zero-y                       += composite.o
> > > +g_zero-y                       += usbstring.o
> > > +g_zero-y                       += config.o
> > > +g_zero-y                       += epautoconf.o
> > > +g_zero-y                       += f_sourcesink.o
> > > +g_zero-y                       += f_loopback.o
> > 
> > yes, you can do that. But the problem is the runtime memory footprint
> > that we will have with that. At least that was the reason why Greg had
> > asked Dave to change it to how it is done now.
> 
> What exactly is the runtime memory footprint problem?  I thought the
> whole reason for #include'ing .c files was that back then, the kbuild
> system wasn't able to do this.

not at all. Kbuild has always been able to generate one module from
several objects. But then we need to remove "static" from many
functions to achieve that.

> > Do we support gcc --combine already ?
> 
> As far as I know, the only advantage of gcc -combine is that it allows
> the optimizer to work on more than one file at a time.  Would that
> really make any significant difference for these particular source
> files?

AFAICT, gcc --combine will really combine the files as if they were one,
pretty much the same as including the entire C source.

Just look at the rationale from the commit log itself:

commit 4e9ba518ec19c6c961bf6074ec05ae1a927230bc
Author: David Brownell <dbrownell@users.sourceforge.net>
Date:   Mon Aug 18 17:41:02 2008 -0700

    usb gadget: link fixes for serial gadget
    
    Change how the serial gadget driver builds:  don't use
    separate compilation, since it works poorly when key parts
    are library code (with init sections etc).  Instead be as
    close as we can to "gcc --combine ...".
    
    Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

part of it is also in any gadget driver:

/*
 * Kbuild is not very cooperative with respect to linking separately
 * compiled library objects into one module.  So for now we won't use
 * separate compilation ... ensuring init/exit sections work to shrink
 * the runtime footprint, and giving us at least some parts of what
 * a "gcc --combine ... part1.c part2.c part3.c ... " build would.
 */

you can find all such commits by:

$ git log --author="David Brownell" --grep="link fixes" -- drivers/usb/gadget/

And here are the original discussions:

http://marc.info/?l=linux-usb&m=121868805717787&w=2
http://marc.info/?l=linux-usb&m=121875765411492&w=2

In summary:

We don't want to have library code into their own drivers because, well,
you can only have one gadget driver at a time anyway. And we don't want
separate compilation due to having stuff out of init sections.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]