On 2010-06-22, JMGross <[email protected]> wrote:

>>> If I understood the linker scripts correctly, the linker will put all
>>> .text and .text.* compiler segments into the linker text segment.
>
>> After the unreferenced .text.* sections are discarded, the remaining
>> ones will all be placed into the .text section in the output file.
>
> As I undestood you, the linker should do this for any (complete)
> object file anyway, independently of the gc-sections setting.

The discarding of unreferences sections is enabled by the
--gc-sections linker option.

> Yet it doesn't. Any object file is put into the binary, whether
> referenced or not.

Unless you specify the --gc-sections option linker option.

>>> So there are no empty segments to be discarded by -gc-sections.
>
>>I'm not sure what "empty segments" you're talking about.
>
> segments -> = sections. I think I got the 'empty' by browsing the ld
> option description. Or i dedutcted it from your expression of
> discarded unused content.

unused != empty

>> Are you _sure_ you passed the -gc-sections flag to the linker?
> no (see below)
>
>> First, both -ffunction-sections and -gc-sections flags are commented
>> out in your makefile.
>
> I tried with and without. The version I posted was the last test
> (without both).
>
>> Second, it's '--gc-sections' not '-gc-sections'
>
> I tried both :)

And both would have produced an error/warning using your posted
makefile, which should have prompted you to try figure out what you
were doing wrong rather than claiming the feature didn't work:

$ make
msp430-gcc -g -ffunction-sections --gc-sections -Wa,-ahl=main.lst -O2
-Wall -Werror -mmcu=msp430x149 -Wa,-ahld=main.lst -o main.elf main.c
cc1: unrecognized option -fgc-sections'
make: *** [main.elf] Error 1

$ make
msp430-gcc -g -ffunction-sections -gc-sections -Wa,-ahl=main.lst -O2
-Wall -Werror -mmcu=msp430x149 -Wa,-ahld=main.lst -o main.elf main.c
cc1: warning: c-sections': unknown or unsupported -g option
msp430-objcopy -O srec main.elf main.hex


>> Third, if you uncomment them and add the second hyphen, you're still
>> not passing --gc-sections flag to the linker, you're passing it to
>> the compiler (which should have resulted in a error message).
>
>> If you want to pass the --gc-sections flag to the linker via the gcc
>> command line, you need to use either "-W,--gc-sections" or "-Xlinker
>> --gc-sections"
>
> That's the point. (or nearly, according to the GC manual, it is -Wl,x
> (which works)

Right.  Sorry about the typo.

> I read the ld documentation and missted the fact that the compiler
> gets the options first, even if added to LDFLAGS.

The ld documentation has no way of knowing what program you're passing
LDFLAGS to in your Makefile.

> Nevertheless, I don't understand why foo() is added to the binary by
> the linker default, while it is not referenced and in its own object
> file.

Because you didn't pass the --gc-sections flag to the linker to tell
it to discard unreferenced sections.

> With the use of -Wl, I come to this conclusion:
>
> 1) without --gc-sections, the linker keeps ALL code passed to it in
>    an object file, no matter whether anything in an object file is
>    referenced or nothing at all.

Yes. Thats why I said you have to use both the -ffunction-sections and
--gc-sections options.

> 2) with use of --gc-sections, the linker will ignore any object files
>    content, if nothing in this object file is referenced from outside

Yes.

> 3) using -ffunction-sections AND --gc-sections, the compiler will put any
> function in its own .text.* (sub)section and the linker will discard any of
> them which is not referenced, even if in the same object file as other,
> referenced code.

Yes.

> Since 1) is the default, binary files may be unnecessary large by
> default.

Yes.

> Thanks for your clarifications. It makes life a bit easier for me (I
> can skip some #ifdefs now in the modules), now that I know (I think) 
> how it really works.

-- 
Grant Edwards               grant.b.edwards        Yow! I don't understand
                                  at               the HUMOUR of the THREE
                              gmail.com            STOOGES!!


Reply via email to