Le Sun, 04 Dec 2011 18:08:30 -0500,
Boris Gjenero <boris.gjen...@gmail.com> a écrit :
> On 04/12/11 02:11 PM, Rafaël Carré wrote:
> > For function removal I had this testcase:
> >
> > % cat Makefile
> > CFLAGS += -O3 -Wl,--gc-sections
> >
> > OBJS=a.o b.o
> >
> > all: a.out
> > objdump -d -j .rodata $<
> > # You should only see DCBA == 44 43 42 41
> > # 41 42 43 44 is not used and should be removed
> >
> > a.out: $(OBJS)
> > $(CC) $(CFLAGS) $(OBJS) -o $@
> > % cat a.c
> > void f(void) { puts("DCBA"); }
> > int main() {f();}
> > % cat b.c
> > __attribute__((weak)) void f(void)
> > {
> > puts("ABCD");
> > }
> > %
>
> Your test case removes "ABCD" because there is nothing else in the same
> section in b.o. If there was something else (for example due to another
> function in b.c that's like f() but actually used by main()), then
> "ABCD" remains.
>
> I don't know how to remove "ABCD" via --gc-sections. If I use
> -ffunction-sections -fdata-sections -Wl,--gc-sections, it's still there.
> Strings go to .rodata.str1.1 in Linux and .rodata.str1.4 on the 5G iPod.
> They don't get split up. Does anyone know how to split them up?
Thanks for the explanation.
> If I use -flto (link-time optimization), then "ABCD" is indeed gone.
> With -flto, you don't need any other switches to remove "ABCD". I've
> already been able to produce a working Archos Recorder V2 binary with
> link-time optimization, saving over 7k. However, I'm not really
> interested in trying to convince other developers that it should be
> used. Switching toolchains can lead to problems, -flto could make
> debugging much harder, and there's a *big* increase in link time.
flto at least failed to work when mixing thumb and arm code (i think
the last version i tried was gcc 4.6.1)
In the long run it would be nice to use it though, if properly tested
(especially wrt codecs speed).
> > I can see some linker scripts have something like that already:
> > KEEP(*(.vectors));// otherwise there are no references to it and the linker
> > strip it
>
> Yes. For example, the firmware/target/sh/archos/app.lds has it, and so
> -Wl,--gc-sections can be used without problems on Archos hwcodec targets.
Should we mark all sections as KEEP in all scripts ?
> > Btw the reason for the lcd_blit_yuv() commit was to avoid some #ifdef
> > hell (to remove the default C function from the sources when there is
> > an optimized version)
>
> I wonder if you could use a #define in lcd-target.h. For example there
> are generic copy_read_sectors() and copy_write_sectors() functions in
> firmware/drivers/ata.c. A target can supply its own functions and
> prevent the generic functions from being compiled by defining
> ATA_OPTIMIZED_READING and/or ATA_OPTIMIZED_WRITING in its own ata-target.h.
Yes it would work but gc-sections and ffunction-sections would be
better of course
--
Rafaël Carré
