On 2010-06-18, JMGross <[email protected]> wrote:
> I dug out some older project files and if I understand their old
> makefile correctly, all object files were put into a library (.a) and
> then this was fed into the linker. So maybe this was the reason for
> the missing code if the project object files inside the library
> weren't in the right order.
That will indeed cause problems. For pretty much all of the linkers
I've used, libraries were only processed once at the point in the file
list where they were encountered. If an object file later in the list
needs something from a library that has already been processed, that
symbol will go unresolved.
>> If you do come across a case of -ffunction-sections and -gc-sections
>> not working, please post it. It should work, and I know for a fact
>> that it used to.
>
> Following example:
>
> Any project (does not matter which).
> Compiled with -ffunction-sections and linked with -gc-sections.
> Now add a dummy function
> void foo(void){};
>
> After compilation, the function foo is in a segment called .text.foo.
> So -ffunction-sections work.
> After linking, the function is in the linked binary. Binaries are identical,
> no matter whether -gc-sections was used or not.
As I've said, doing that works fine for me.
By "post an example" I meant provide source files and a makefile the
exhibit the problem so that we can try to fix it.
> Onother example. Once again any project. One object file was added to
> the project, containing the above function. Again the binaries are
> identical, no matter whether -gc-sections was used or not. foo() was
> always part of the binary.
>
> Is it possible that if not ld itself then the linker scripts have
> been altered in a way that breaks -gc-sections?
That's possible. If you can post an example that fails for you and
works for us, then we can start trying to track down the source of the
problem.
>>> I'd really like to put this kind of options (including optimization
>>> settings) into the appropriate source file only (by a pragma) instead
>>> of having them active for the whole project (unless one wants to make
>>> rather complex makefiles)
>
>>yes, that would be nice, but it would be very difficult due to some
>>fundamental architecture decisions that were made in both gcc and
>>binutils a long time ago.
>
> Not really.
OK, then submit a patch.
Based on what I've seen from my work on gcc and binutils, it looked
pretty difficult to me. Perhaps my understanding of gcc/binutils
internals isn't as good as yours.
>> The last fix to gcc for -ffunction-sections -fdata-sections support
>> went in at the end of May 2008, so I would expect the 12/2008 build of
>> gcc to work. I'm not sure what "ld 060404" means. ld should have
>> version number like 2.19.3. What I can say is that it worked for me
>> the last time I tried it, and others have reported it working more
>> recently.
>
> D:\>msp430-ld -v
> GNU ld version 060404 20060404
> D:\>
>
> Hmmm, now that you ask, I checked the file date and it was May 2006.
> Looks like I called the wrong one. :(
>
> The ld version that's called by msp430-gcc is
> GNU ld (GNU binutils) 2.18
> (I checked the makefile output)
I think that should be recent enough.
>>Yes, if the linker supports changing address modes, then it does
>>move the following code.
>
> Then it needs to also adjust all symbolic mode accesses,
> even local ones which are not subject to relocation.
> Quite some work. And requires a lot special knowledge about the
> target system structure.
Yes it does. That's why it's supported on a per-target basis and not
all targets have had support for that sort of thing added.
> If the linker goes through the object file, analyzes every
> instruction (if it is an instruction)... well, why do we have an
> assembler stage? :)
Various reasons -- not the least among them is history: when you
first write a compiler, there is often an existing assembler and
linker that you can use.
>>> Well, I'm better safe than sorry and I guess someone else did too.
>>> Why else is this whole -ffunction-sections thing an option and
>>> disabled by default?
>
>> Because it's a somewhat new feature and it's not the way people are
>> used to having things work. When a new feature gets added, it's
>> usually disabled by default in order to preserve as much
>> backwards-compatibilty as possible.
>
> Hmmm, backwards compatibility considerations are only neccessary if
> something may have unexpected side-effects to the unaware.
The main side-effect is the way sections are named. It's possible
there are side-effects to the way code is optimized, but I've never
seen that.
--
Grant Edwards grant.b.edwards Yow! What's the MATTER
at Sid? ... Is your BEVERAGE
gmail.com unsatisfactory?
