Von: Grant Edwards Gesendet am: 23 Jun 2010 18:01:14
>> I never got one. In theory, my frontend should capture stdout and >> stderr. And normally I see any output from compiler and/or linker. So >> I never thought that I was missing the -Wl prefix. > That's bizarre. Indeed. I just tested it again from commandline, enabling the commandline echo, so I can see what is called. Here's the output: c:/Programme/msp430/mspgcc_0812/bin/msp430-gcc -mmcu=msp430x5436 -Wl,--gc-sections -nonsense --nonsense -gc-sections --gc-sections obj/Linktest.o obj/dummy.o -o lib/Linktest.elf No output whatsoever from ld, except for the elf file. If there are linking errors, I get them, of course. Looks like gcc is not complaining about unknown options when called for the linker stage. It seems to just ignore all except those directed to the linker. If I add a nonsense option to the CPFLAGS, GCC will complain. >> I don't understand why the -gc-sections flag is needed to activate a >> functionality I consider the default behaviour of a linker. > I've been doing embedded development for 25+ years and I don't ever > remember seeing a linker where that was the default behavior. Well, I do it only for 5 years now (if you don't count the C64 as an embedded system even if todays MSPs are way more capable) I used quite a few for normal application development, however. On some systems, I KNOW that the linker did not just keep everything, and from an engineers view it is just logical. On most others, I just didn't care at all. (I seldom write superfluous code at all). Even on MSP, I usually only include object files into the project which are in use. The only exception is the current play-and-port project for the 5438, where I included all already ported sources from previous projects, even if not currently used. >> Maybe that is why my predecessor put all object files into a library >> and linked it, so unreferenced object files didn't get linked, while >> introducing that maybe even (later) referenced code wasn't linked. >Yes, that's why libraries were invented: because linkers didn't >discard unused object files. I always thought this was invented because it is easier to add one library to a project than hundreds of object files. And dynamically linking to a library is easier too. My mistake. > The default case for gnu binutils "ld" and every other linker I've > ever used is to keep all the object files you tell it to link > regardless of whether they are referenced or not. For those who do not spend their time with working on ld or studying bookstores of documentation first before they can compile and link a simple 'hello world' (so 99% of all users), this information, while being useful and important, is practically invisible. Only if you know where to look (and that you have to look) you'll eventually find it. No wonder that todays software is so big and bloated. I just wonder how big the percentage of unused, unreachable code in typical programs is. On PCs, this might be a don't care, but on embedded systems, I consider it of much interest for a large percentage of users. Well, now that everything is (more or less) clear (except of the question why there is no warning for unknown options), we should close this thread, as it starts to stray off-topic. JMGross
