dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Removing unused code via --gc-sections

Re: Removing unused code via --gc-sections

From: Boris Gjenero <>
Date: Sat, 17 Dec 2011 17:22:46 -0500

On 17/12/11 03:34 PM, Rafaël Carré wrote:
> Le Sat, 17 Dec 2011 13:26:02 -0500,
> Boris Gjenero<> a écrit :
>> It seems there's interest in automatically removing unused code via
>> --gc-sections. Theoretically, the requirements are easy:
>> --gc-sections requires KEEP() in linker scripts around things that need
>> to be kept but are not directly referenced. This only seems to affect
>> vectors, because they're only accessed by the CPU.
>> -ffunction-sections requires wildcards for .text, because it puts
>> functions in sections like ".text.functionname".
>> -fdata-sections similarly requires wildcards for .data, .rodata and
>> .bss. I don't see a benefit from -fdata-sections due to very little
>> removed data and added alignment padding. However, I think adding what's
>> required to allow it to work is a good idea because it's simple.
> I think jhMikeS already did that part in r31337 (wow, how come we
> missed that revision?)

In r31337 and r31338, wildcards were only added to some files. It seems
those were files which had to have wildcards added because assembler
code was put into specific sections. Those commits didn't address, and they also didn't add the same wildcards to other files.

I created a list showing where wildcards could be added, based on what
wildcards exist and what files contain the same sections without
That only examines firmware/ and *.lds in firmware/target.

Except for the change, the other stuff isn't needed until some
things for those targets are actually put into sections requiring the
wildcards. I don't think a glue_7 wildcard will ever be needed. I could
create a patch adding all those at once. As long as linkers aren't
buggy, it shouldn't cause problems, and it would avoid red when things
are moved into their own section.

>> Here's a patch which does all that:
>> . I'm not
>> certain that it's wise to touch linker scripts that aren't used for
>> regular target and bootloader builds, but KEEP() shouldn't cause any
>> harm. I only added wildcards to firmware/, because only that is
>> required to make this work with normal builds.
> Looks straightforward to me, I think you should just commit it

I will, tonight.

>> I think the linker scripts could use some cleanup and merging. I didn't
>> get around to that, and I don't think making these changes will make
>> future cleanup and merging harder.
> Yeah I think they are separate changes but indeed a linker template
> would be cool and avoid copy/pasted stuff

Before the split, firmware/ was a mess that needed some splitting:

I don't think they should be merged fully like that, because I can't
imagine how the result could end looking good. However, some tidy
merging is possible on a per-CPU basis. For example, some of the
PortalPlayer scripts are identical and others have trivial differences.
Right now a merge is possible using #include, though a cleaner solution
would be to move PortalPlayer targets into one subdirectory of


Received on 2011-12-17

Page was last modified "Jan 10 2012" The Rockbox Crew