Re: [Mspgcc-users] Unused functions occupying unnecessary memory
Von: Grant Edwards Gesendet am: 22 Jun 2010 16:16:20 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 right. Well, when all content has been discarded because being unused, it is empty. :) 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: 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. I just tried agian with intentionally requesting an error message, yet there was none. Then I tried to call make from the windows 'DOS' console. Still no error message. Is it possible that it is pushed into an output streamthat is swallowed by the windows environment? Unlinkely, I know, as other warnings/errors come through That's the point. (or nearly, according to the GC manual, it is -Wl,x (which works) Right. Sorry about the typo. No problem, now that I was pointed into the right direction. 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. Now that I remember that ld is called through gcc, it's obvious. Most of the makefile setup was inherited from my predecessor and I guess he got most of it from the mspgcc templates. 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. let me rearrange the statement: I don't understand why the -gc-sections flag is needed to activate a functionality I consider the default behaviour of a linker. I would understand that you'll need to tell the linker that you want to _keep_ unreferenced information, but not that it will by default keep everything (at least for object files and even completely unreferenced object files) while it does discard unused parts from a library. 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. When I took over the projects, I had no way to ask him as he left the company. Since 1) is the default, binary files may be unnecessary large by default. Yes. And that's what I don't understand: why is the special case (keep it even if not referenced and therefore unreachable) is the default and the default case (keep only what's used) requires extra treatment. Anyway, now that I know that it is so, I can live with it. So while I'm sorry alarming you unnecessarily, I'm quite happy that I did, as I gained some valuable insights from this discussion. And maybe others did too. After all this is a compiler users mailing list and not a compiler programmers list. :) JMGross
Re: [Mspgcc-users] Unused functions occupying unnecessary memory
One reason why keep it even if unreferenced may be the default even when optimizations are enabled is that these tools (binutils, gcc) are primarily used in environments that have far more capabilities, and couldn't care less if a few extra kilobytes are present in the image. If you work in Linux with dynamic libraries, which is the common case, it's easy to use dlopen to resolve symbols at runtime that are not referenced at link time, and invoke unreachable code that way. The simplest perspective is user provided it, so leave it alone. The user's supposed to know best; I don't want the software to be overly helpful unless I explicitly give it permission. Peter On Wed, Jun 23, 2010 at 10:07 AM, JMGross msp...@grossibaer.de wrote: Since 1) is the default, binary files may be unnecessary large by default. Yes. And that's what I don't understand: why is the special case (keep it even if not referenced and therefore unreachable) is the default and the default case (keep only what's used) requires extra treatment. Anyway, now that I know that it is so, I can live with it. So while I'm sorry alarming you unnecessarily, I'm quite happy that I did, as I gained some valuable insights from this discussion. And maybe others did too. After all this is a compiler users mailing list and not a compiler programmers list. :) JMGross -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] undefined reference error while building gdb
You can disregard this email I sent out yesterday. I never figured out what was wrong but a fact finally penetrated my thick skull and that fact is that I don't need to build the tool, I just need to use the tool. I can just download that. In case it's not obvious, I'm a little out of my depth here. But I'm learning by leaps and bounds and I'll figure everything out eventually. Thanks anyways. Brian On Tue, Jun 22, 2010 at 4:17 PM, Brian Nolte brianno...@gmail.com wrote: I'm trying to build (or 'make') gdb for mspgcc and I'm getting a number of undefined references: `_tgetent',`_tgetnum',`_tgetstr',`_tgetflag',`_tputs',`_tgoto'. The instructions I'm following are here: http://mspgcc.sourceforge.net/manual/x1746.html Brian Here's the complete output, sorry if it makes the email kind of long: /bin/sh: command substitution: line 0: syntax error near unexpected token `then' /bin/sh: command substitution: line 0: `if test -r ../libtermcap/libtermcap.a; t hen echo ../libtermcap/libtermcap.a; else echo -ltermcap; fi' libgdb.a(utils.o): In function `init_page_info': /home/bn2008/gdb-5.1.1/gdb/utils.c:1531: undefined reference to `_tgetent' /home/bn2008/gdb-5.1.1/gdb/utils.c:1537: undefined reference to `_tgetnum' /home/bn2008/gdb-5.1.1/gdb/utils.c:1547: undefined reference to `_tgetnum' ../readline/libreadline.a(terminal.o): In function `_rl_get_screen_size': /home/bn2008/gdb-5.1.1/readline/terminal.c:199: undefined reference to `_tgetnum ' /home/bn2008/gdb-5.1.1/readline/terminal.c:215: undefined reference to `_tgetnum ' ../readline/libreadline.a(terminal.o): In function `_rl_init_terminal_io': /home/bn2008/gdb-5.1.1/readline/terminal.c:360: undefined reference to `_tgetent ' /home/bn2008/gdb-5.1.1/readline/terminal.c:309: undefined reference to `_tgetstr ' /home/bn2008/gdb-5.1.1/readline/terminal.c:419: undefined reference to `_tgetfla g' /home/bn2008/gdb-5.1.1/readline/terminal.c:431: undefined reference to `_tgetfla g' /home/bn2008/gdb-5.1.1/readline/terminal.c:431: undefined reference to `_tgetfla g' /home/bn2008/gdb-5.1.1/readline/terminal.c:419: undefined reference to `_tgetfla g' ../readline/libreadline.a(terminal.o): In function `_rl_backspace': /home/bn2008/gdb-5.1.1/readline/terminal.c:528: undefined reference to `_tputs' ../readline/libreadline.a(terminal.o): In function `ding': /home/bn2008/gdb-5.1.1/readline/terminal.c:566: undefined reference to `_tputs' ../readline/libreadline.a(terminal.o): In function `_rl_enable_meta_key': /home/bn2008/gdb-5.1.1/readline/terminal.c:592: undefined reference to `_tputs' ../readline/libreadline.a(terminal.o): In function `_rl_control_keypad': /home/bn2008/gdb-5.1.1/readline/terminal.c:604: undefined reference to `_tputs' ../readline/libreadline.a(display.o): In function `cr': /home/bn2008/gdb-5.1.1/readline/display.c:1600: undefined reference to `_tputs' ../readline/libreadline.a(display.o):/home/bn2008/gdb-5.1.1/readline/display.c:1 225: more undefined references to `_tputs' follow ../readline/libreadline.a(display.o): In function `update_line': /home/bn2008/gdb-5.1.1/readline/display.c:1502: undefined reference to `_tgoto' /home/bn2008/gdb-5.1.1/readline/display.c:1503: undefined reference to `_tputs' /home/bn2008/gdb-5.1.1/readline/display.c:1512: undefined reference to `_tputs' /home/bn2008/gdb-5.1.1/readline/display.c:1528: undefined reference to `_tputs' /home/bn2008/gdb-5.1.1/readline/display.c:1545: undefined reference to `_tgoto' /home/bn2008/gdb-5.1.1/readline/display.c:1546: undefined reference to `_tputs' ../readline/libreadline.a(display.o): In function `rl_redisplay': /home/bn2008/gdb-5.1.1/readline/display.c:695: undefined reference to `_tputs' ../readline/libreadline.a(display.o): In function `_rl_redisplay_after_sigwinch' : /home/bn2008/gdb-5.1.1/readline/display.c:1650: undefined reference to `_tputs' /home/bn2008/gdb-5.1.1/readline/display.c:1662: undefined reference to `_tputs' collect2: ld returned 1 exit status make[1]: *** [gdb.exe] Error 1 make[1]: Leaving directory `/home/bn2008/gdb-5.1.1/gdb' make: *** [all-gdb] Error 2
