----- Ursprüngliche Nachricht -----
Von: Grant Edwards
Gesendet am: 17 Jun 2010 21:01:31
On 2010-06-17, JMGross <[email protected]> wrote:
> [I don't suppose you could wrap lines in your posts?]
I'll try. :) Normally, the receivers mail program should do if necessary.
(You don't use plain old unix mail, don't you?)
Personally, I don't like the way I get answers wrapped back.
It reminds me of a poem ratehr than a conversation. It interrupts the
flow of reading and leaves lots of unused empty white space on the
right side of the screen while it keeps me scrolling.
>> Not with the gc-sections feature. But I'm pretty sure it happened
>> with object files and not just libraries. (And I'm sure that no
>> libraries were linked before the object files, but maybe dependent
>> libraries in the wrong order)
> I've never heard of that issue occuring with object files, and based
> on my understanding of how the linker works, I don't see how it could
> happen.
None of my current MSP or ATMega projects actually uses any
library except for the stdlib. No own or foreing ones. And never did.
Since I remember having this kind of problems somewhere in the
past, it thought it must have been with the object files.
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.
> 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.
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?
> You said that "compile may not do any optimization that crosses the
> boundary between functions." Now you're saying it's only certain
> _types_ of cross-function optimization that can't be done. That may
> be true, though I can't think of any.
If an optimization crosses the boundary of a section, it makes the use of
separate sections useless, as both are always needed.
Only that they could be split into two different target (flash) segments,
if the optimization allows them moving that far apart.
>> If foo() is kept and bar() is not, what about the shared code?
>The compiler could put the shared code in a third section and call it
>from both foo() and bar().
Of course that's a possible workaround.
>> 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. Even to have the pragma happening at the start of a
compilation unit (where it shouldn't make any difference whether the
compiler is started with a commandline option or whether it is the
first thing it sees) would be a big step ahead.
Else I'd vote for a pre-precompiler which takes the source, scans it
or pragmas and then adds/adjusts the compiler options according
to the pragmas found.
Just an idea because I had a case where optimization was breaking
the code and I had to compile this without optimization. And I had
to write an unnecessary complex addition to the default makefile
so the rest of the project would compile optimized.
The worst part of it was that this makefile anomaly MUST be added
to every project using this code. If you forgot it, the code was crashing.
With the option inside the code, things would be much easier, even if
not working selectively on parts of the compilation unit.
Old Borland C++ 3.1 allowed optimizations different for every function
and sometimes it was really needed. It's a shame that they didn't find
a way to do it for GCC too.
> 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)
>>> IIRC, the linker will convert "long" branches into short/relative
>>> jumps at link time. At least it does that for all the other targets
>>> I use...
>> interesting. Still two wasted bytes (I don't think the linker will
>> move the following code and adjust any other jumps if necessary),
>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.
>> I'm just curious. Altering the assembly instructions is nothing a
>> linker should do imho.
> Then don't enable that option. For Gnu binutils it's called
> "--relax".
okay, so it's a non-default option. And an optional one too.
>> A fixed distance to the destination is the base of relative
>> addressing. And with separate segments there is no such fixed
>> position.
> Again, stuff like that can be fixed up at link time.
If the linker goes through the object file, analyzes every instruction
(if it is an instruction)... well, why do we have an assembler stage? :)
>> 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.
And that's what I wanted to express with my original post.
And I'm sorry if I do not express clear enough what I want to say, but
I'm not a native speaker and I don't use English every day.
This mailing list and the TI E2E forum are the only locations where
I use this language. Sometimes I simply do not hit the nail on the head.
