Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

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

Re: Removing unused code via --gc-sections

From: Boris Gjenero <boris.gjenero_at_gmail.com>
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<boris.gjenero_at_gmail.com> 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
rom.lds, 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
wildcards: http://www.rockbox.org/tracker/task/12378?getfile=24522
That only examines firmware/rom.lds and *.lds in firmware/target.

Except for the rom.lds 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:
>> http://www.rockbox.org/tracker/task/12378?getfile=24520 . 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/rom.lds, 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/app.lds was a mess that needed some splitting:
http://svn.rockbox.org/viewvc.cgi/trunk/firmware/app.lds?revision=16623&view=markup&pathrev=16650

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
firmware/target.

Regards,

Boris
Received on 2011-12-17


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